AI agent incident response is the process a New Zealand business follows when an AI agent sends, updates, publishes, recommends, classifies, or reports something wrong. The goal is to stop further harm, preserve evidence, correct the affected work, and decide whether the agent can restart.
For a small or mid-sized business, this can be a one-page operating rule: who can pause the workflow, what gets logged, who reviews the incident, and what must change before the agent runs again.
If you are still planning the workflow, define the response plan before build. The $1,000 AI Agent Assessment maps the workflow, approval gates, escalation points, logs, and rollback rules before an agent touches live work.
An AI agent incident is any unexpected or unsafe agent action that creates business risk, customer confusion, data exposure, inaccurate records, unsupported claims, or extra work for reviewers.
A major incident could be a customer email sent with the wrong promise, a website page published with an unsupported claim, or a CRM record changed in a way that affects a sales handoff. Smaller incidents matter too: bad classifications, missing sources, wrong summaries, failed tool calls, or review queues that hide risky items.
The point is to keep the business in control when the workflow behaves differently from the design.
AI agent escalation rules tell the agent when to stop before a risky action. Incident response starts when the stop rule fails, the agent behaves unexpectedly, or a person finds an error after the agent has already prepared or affected work.
Good escalation reduces unmanaged risk. Incident response handles the cases that still happen.
Use this checklist when an AI agent sends, updates, publishes, recommends, reports, or routes the wrong thing.
Stop the agent or automation path first. Do not keep testing inside the live workflow while the same mistake can repeat. If the agent has tool access, pause the trigger, remove write access, disable the scheduled run, or switch the workflow to draft-only mode.
Capture what happened before editing records or deleting outputs. Save the input, agent output, tool calls, source material used, timestamp, reviewer actions, affected records, and any customer-facing message. The AI Agent Audit Trail NZ guide explains the logs that should exist before workflows expand.
Name the person responsible for the incident decision. In a small business, this may be the owner or operator. In a larger team, it may be the sales manager, operations lead, data owner, finance owner, or website owner. The technical supplier can help investigate, but the business owner decides the commercial response.
Decide what needs correction now. That may include removing a draft, updating a CRM note, correcting a report, replacing a website section, notifying a staff member, or contacting a customer with a clear correction. Avoid over-correcting if the impact is limited, but do not hide a customer-facing error.
Look for the practical cause: wrong source, stale page, missing approval gate, broad permission, unclear prompt, bad input, failed integration, tool timeout, no owner review, or a reviewer who was overloaded. Most incidents are workflow design problems, not just model problems.
Do not restart because the immediate problem has been patched. Define the restart condition: source corrected, permission reduced, approval gate added, escalation rule rewritten, tests passed, and owner accepted the change. If you have not tested the fix, keep the workflow paused or draft-only.
These examples are starting prompts, not legal, privacy, HR, or financial advice. Use them to decide where your own stop and response rules belong.
A sales agent changes lead status, deal value, next action, or follow-up priority incorrectly. Pause write access, preserve the before-and-after CRM record, check the source used, correct the pipeline record, and decide whether future CRM updates must stay recommendation-only.
An inbox agent drafts or sends a reply that is too confident, uses the wrong tone, misses a complaint, or promises something outside the approved offer. Stop sending, keep the message thread, assign a person to review the customer impact, and tighten the rule for complaints, refunds, pricing, and sensitive data.
A content agent publishes or prepares copy with unsupported proof, stale pricing, wrong internal link, broken CTA, or a claim the business cannot stand behind. Remove or correct the content, preserve the previous version, check source pages, and require approval before publishing resumes.
A reporting agent summarises incomplete data, mislabels a trend, or recommends an action from a failed tool call. Pause the report distribution, mark the affected report as corrected, identify missing data, and add a rule that low-confidence or failed-source summaries escalate before decisions are made.
Incident response works best when the rules already exist. Waiting until the first mistake creates confusion and slows the correction.
Every live workflow needs a named stop authority. This person should be able to pause the trigger, remove permissions, change the workflow to draft-only, or ask the implementation partner to disable the run.
For each workflow, define the likely rollback path. Can a CRM change be reverted? Can a website page be restored? Can an email be corrected? Can a report be reissued? Can tool access be removed quickly?
Use AI Agent Acceptance Testing NZ to check not only whether the agent can perform the happy path, but whether the business knows what to do when the agent stops, fails, or produces the wrong output.
The AI Agent Assessment turns incident response into a practical workflow map before implementation expands. For one workflow, we identify:
That map helps the business decide whether the first build should be read-only, draft-only, approval-gated, or not built yet.
AI agent incident response is the process a business follows when an AI agent makes, prepares, sends, updates, publishes, routes, or recommends something wrong. It covers pausing the workflow, preserving evidence, correcting the affected work, finding the failure point, and deciding whether the agent can restart.
Pause the workflow first so the mistake cannot repeat. Then preserve the evidence, identify the affected records or messages, assign a business owner, contain the impact, and review the failure before restarting the agent.
The business should own incident response. A technical partner can investigate integrations, prompts, permissions, and logs, but the business owner or workflow owner should decide customer corrections, commercial impact, restart timing, and approval rules.
Only restart after the failure point has been corrected and tested. If the cause is unclear, keep the workflow paused, read-only, or draft-only until source material, permissions, approval gates, escalation rules, and logs are reviewed.
Do not wait for the first mistake to decide who can stop an agent. Define the pause, evidence, correction, owner, and restart rules before automation touches live work.
