# AI Agent Runbook Template

> Source: https://netray.co/tools/ai-agent-runbook-template
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

A runbook for the person on call when an ERP-connected AI agent misbehaves: how to check it, pause it and roll back.

## Category

ai-automation

## Audience

- IT manager
- ERP administrator
- Operations
- Support

## Tool

**Kind:** template

**Output:** document

**Fields:**

#### Agent name

**Key:** agent

**Type:** text

**Default:** Order Status Agent

#### Service owner (role)

**Key:** owner

**Type:** text

**Default:** ERP Platform Lead

#### On-call contact or channel

**Key:** oncall

**Type:** text

**Default:** #erp-ai-oncall, ext. 4410

#### Where it runs

**Key:** host

**Type:** text

**Default:** On-prem inference server GPU01, application server APP03

#### ERP service account

**Key:** service_acct

**Type:** text

**Default:** svc_ai_orders (read-only role)

#### Actions it can take in the ERP

**Key:** write_actions

**Type:** textarea

**Default:** None. Read-only queries. Drafts email text for planner to send manually.

#### How to pause it

**Key:** pause_method

**Type:** textarea

**Default:** Disable the agent in the admin console, then disable the service account in the ERP. Confirm no new queries appear in the ERP audit log.

#### Daily health checks

**Key:** health_checks

**Type:** textarea

**Default:** Inference endpoint responds within 5 seconds, nightly data refresh completed, error rate below agreed threshold, GPU memory not saturated.

#### Rollback procedure

**Key:** rollback

**Type:** textarea

**Default:** Redeploy the previous container image and prompt configuration from the release tag, then rerun the regression question set.

**Blocks:**

#### Runbook: {{agent}}

**Body:** Service owner: {{owner}}
On-call: {{oncall}}
Runs on: {{host}}
ERP service account: {{service_acct}}

#### What the agent can do

**Body:** {{write_actions}}

#### Daily health checks

**Body:** {{health_checks}}

#### Symptoms and first response

**Table:**

**Columns:**

- Symptom
- Likely cause
- First action
- Escalate to

**Rows:**

**0:** Slow or no answers

**1:** Inference server down or overloaded

**2:** Check endpoint and GPU memory, restart service

**3:** {{owner}}

**0:** Answers look wrong or old

**1:** Stale data refresh or retrieval fault

**2:** Check last refresh time, run regression questions

**3:** {{owner}}

**0:** User sees data they should not

**1:** Permission or retrieval filter fault

**2:** Pause the agent immediately, preserve logs

**3:** Information security

**0:** Unexpected ERP transaction

**1:** Tool permission or prompt fault

**2:** Pause the agent, review ERP audit log

**3:** Business owner and security

#### How to pause the agent

**Body:** {{pause_method}}

#### Rollback

**Body:** {{rollback}}

#### After an incident

**Body:** Record the timeline, notify the business owner, preserve logs, and complete an incident postmortem within five working days. Do not re-enable a paused agent until the owner and information security agree.

#### Approvals

**Signatures:**

- Service owner
- Business owner
- Information security

**Notes:** Test the pause procedure at least once before go-live and again after any architecture change. A kill switch nobody has tried is not a control.

## Content

**Intro:** When an AI agent starts giving wrong answers or acting oddly, the person on call needs a clear page to follow, not a design document. This runbook template covers who owns the agent, what it can touch, how to check its health, and exactly how to pause and roll it back.

**Sections:**

#### How to use this template

**Body:** Fill in one runbook per agent. List the infrastructure it runs on, the ERP service account it uses and every action it can take. Write the pause and rollback steps in plain commands or console clicks, then have someone who did not build the agent follow them in a test. Keep the exported PDF in your IT service management knowledge base and link it from the monitoring alert.

#### What to monitor

**Body:** Agents fail quietly more often than loudly. Beyond uptime, watch signals that show quality and safety are intact.

**Bullets:**

- Response time and error rate of the inference endpoint
- Data freshness for any extract or index the agent relies on
- Share of answers users flag as wrong
- Number and type of ERP actions taken by the service account
- GPU memory and queue depth where models run on your own hardware
- Unusual query patterns, such as bulk exports

#### Pause before you diagnose

**Body:** If an agent shows data to the wrong person or performs an unexpected transaction, pause first and diagnose second. Disabling the ERP service account is a reliable backstop because it works regardless of what the agent software does. Preserve prompts, tool calls and logs before restarting anything, because they are the evidence for the postmortem. For read-only agents with low-risk faults, the first action can be a restart or rollback.

#### Common mistakes

**Body:** Typical gaps include a service account with broader rights than the agent needs, a pause method that depends on the failing component, and no regression question set to confirm recovery. Also check that the on-call channel is actually monitored out of hours if the agent supports shift work or plant operations.

**Cta:** Netray can help design read-only-by-default agents with an ERP-side kill switch and audit trail, and can review your runbook against that design.

**Faq:**

#### Is a runbook needed for a read-only agent?

**Answer:** Yes, a shorter one. Read-only agents can still expose data, give wrong answers or consume resources. The runbook tells support staff how to check health, restart safely, and escalate a data exposure concern.

#### What is the safest kill switch?

**Answer:** Disabling the agent's ERP service account is the most dependable, because it removes access at the system of record. Pair it with an application-level switch so you can stop the agent without touching ERP security settings.

#### How often should we test the runbook?

**Answer:** Before go-live, after major changes to the agent or infrastructure, and at least once a year. Have someone other than the builder run the steps so gaps in the instructions become visible.

#### Who should be on call?

**Answer:** Usually the team that supports the ERP platform, with escalation to the agent builders and to information security. Name roles and channels in the runbook so it does not depend on one individual.

## Search terms

ai agent runbook template, llm operations runbook, ai operations playbook, agent kill switch procedure, ai system support documentation, mlops runbook template, erp agent monitoring checklist

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json