AI Agent Exception Taxonomies Should Come Before Autonomous Workflows Scale

Agentic Business Design

1 September 2026 | By Ashley Marshall

The hard part of agentic AI is not the happy path. It is knowing exactly what should happen when the agent gets stuck, sees a conflict, lacks authority or starts to drift.

Autonomy fails first at the edge cases

Most agentic AI pilots are judged on the smooth path: can the system summarise a record, call a tool, update a CRM field, draft a reply or reconcile a simple request? That is useful, but it is not where operational risk usually appears. Risk appears when the agent meets an instruction that conflicts with policy, a customer record with missing fields, a permission that looks valid but feels excessive, a supplier portal that changes layout, or a request that sits just outside its approved scope. If the workflow has no shared language for those moments, every exception becomes improvisation.

The UK National Cyber Security Centre has been unusually direct on this point. In its agentic AI guidance, it says organisations should think about what could happen if an agent misunderstood its task, exceeded its intended scope or was manipulated, and that if they cannot understand, monitor or contain an agent's actions, it is not ready for deployment. That moves the design question away from whether the agent can complete tasks and towards whether the business can classify, route and recover from abnormal ones.

An exception taxonomy is the practical operating layer for that work. It names the types of exceptions the agent is allowed to encounter, records the evidence needed for each one, identifies who owns the next decision and defines when the agent must stop. Without it, human oversight is usually a Slack message, a vague approval prompt or a dashboard that someone checks after the fact. With it, the business can test the agent against realistic failure cases before the workflow is allowed to scale.

See the NCSC guidance on thinking carefully before adopting agentic AI.

The taxonomy needs business categories, not just error codes

Technical error codes are not enough for autonomous workflows because many agent exceptions are not technical failures. The model may produce a valid tool call but choose the wrong customer, make a commercially sensitive change, rely on stale retrieval evidence or continue after a policy conflict. A good taxonomy therefore starts with business risk categories rather than engineering symptoms. Useful categories include missing information, conflicting instruction, uncertain identity, insufficient authority, sensitive data exposure, financial threshold breach, customer impact, regulatory impact, tool failure, abnormal cost, abnormal speed, repeated retry and suspected manipulation.

Each category should answer three questions. First, what has happened in language an operations manager can understand? Second, what evidence must the agent package for the reviewer? Third, what is the permitted next action: retry, ask a human, route to a specialist, quarantine the case, revoke tool access or stop the workflow entirely? This is what makes the taxonomy more than a risk register. It becomes a routing table for work.

The NCSC's more recent cyber risk blog for agentic AI points to the same shape of control. It tells designers and operators to identify what could go wrong, set the right level of oversight, control the agent's environment through sandboxing, log and monitor activity, make activity attributable and maintain the ability to pull the plug. Those are not abstract principles. They can be turned into exception classes that appear in the product backlog, the test pack, the monitoring dashboards and the service desk runbook.

What this means in practice is simple: do not launch with one generic label called human review required. Launch with named labels that match the work. A finance agent might have invoice mismatch, new supplier bank details, VAT anomaly and approval limit breach. A support agent might have vulnerable customer, legal complaint, refund threshold and account takeover suspicion. The closer the taxonomy is to the real operating model, the less likely the team is to wave through risky work because the alert was too vague.

See the NCSC blog on managing the cyber risk of agentic AI.

Human review must have authority, evidence and timing

The common counterargument is that a taxonomy slows the agent down. If every edge case has to be named and routed, surely the business loses the speed benefit of automation. That argument sounds plausible until the first disputed decision, data incident or customer complaint. Speed is only valuable when the organisation can explain why the work was allowed to continue. A pause at the right point is not friction. It is a control that protects the workflow from becoming expensive rework later.

The ICO's March 2026 statement on automated decisions in recruitment is a useful warning beyond hiring. The regulator said automated decision making can improve efficiency and consistency, but only with proper safeguards, transparency, fairness and rights to recourse. It engaged with more than 30 employers, wrote to 16 organisations likely to be using automated decisions about candidates and referred back to almost 300 recommendations it had made to recruitment technology providers and developers in 2024. The lesson for agentic workflows is that human review needs to be real enough to change the outcome, not just visible enough to reassure a board pack.

An exception taxonomy should therefore define the reviewer's authority, evidence pack and response time. Authority means the reviewer can approve, reject, change, escalate or stop the agent's action. Evidence means they see the original instruction, data sources used, tool calls proposed or executed, policy checks, confidence indicators, costs and relevant previous exceptions. Timing means the business decides which exceptions need review before action, which can be reviewed after action, and which require immediate containment.

For UK firms, this matters wherever agents touch people, money, regulated decisions or personal data. It is especially important in recruitment, credit, insurance, complaints, healthcare administration, legal triage and customer account management. A generic approval button gives a reviewer responsibility without enough context. A taxonomy-backed evidence pack gives them a decision they can actually stand behind.

See the ICO update on automated decisions and safeguards.

Security exceptions need their own escalation path

Agentic AI adds a security dimension that ordinary workflow automation often does not have. The system may read untrusted web content, follow instructions from documents, use browser tools, call APIs, update records, remember state and coordinate with other agents. That means the taxonomy needs security exception classes that are separate from ordinary operational exceptions. A failed field validation is not the same as suspected prompt injection. A slow tool call is not the same as unexpected credential use.

The OWASP Top 10 for Agentic Applications makes the risk landscape concrete. It lists agent goal hijack, tool misuse and exploitation, identity and privilege abuse, agentic supply chain vulnerabilities, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation and rogue agents. Those categories should not sit in a security document that the product team never sees. They should influence the taxonomy that decides when the agent stops, logs extra evidence, isolates memory, disables a tool or escalates to security operations.

What this means in practice is that every production agent should have a small set of high-severity security exception labels. Examples include suspected goal hijack, unexpected tool chain, privilege mismatch, unsafe code request, memory contamination, abnormal external instruction, repeated failed authentication and unexplained action burst. Each label needs a containment step. That may be revoke the session token, switch the agent to read-only mode, freeze the case, capture a trace, alert security and prevent further tool calls until a human has reviewed the incident.

The business benefit is not just risk reduction. It is confidence. If a team can show that security exceptions are recognised, logged and routed consistently, it becomes easier to approve carefully bounded autonomy. If the only answer is that the model usually behaves, the agent should stay in a pilot environment.

See the OWASP summary of agentic application risks.

Scale makes informal oversight collapse

Small pilots can survive on heroic oversight. A project lead watches the logs, a subject matter expert checks the first few outputs and a developer stays close to the workflow. That is not an operating model. Once the business has dozens of agents, hundreds of automations or thousands of daily tasks, informal supervision breaks. Exceptions are missed, alerts lose meaning, reviewers disagree and nobody can tell which agent behaviour is acceptable variance and which is a warning sign.

Gravitee's 2026 State of AI Agent Security report is worth reading with that scaling problem in mind. Its survey of 750 senior technology leaders across the UK and USA says enterprise AI agent estates doubled in four months, 48 percent of production AI agents were running unsecured and 54 percent of organisations had already had a security incident. It also says nearly 38 percent of organisations reported having more than 100 agents by April 2026. Even allowing for vendor framing, the direction is clear: agent estates can grow faster than control structures.

An exception taxonomy gives leaders a way to scale review without pretending every agent needs the same governance. Low-risk exceptions can be batched, sampled or routed to first-line operations. High-risk exceptions can require pre-action approval. Security exceptions can go to security operations. Regulated or customer-impacting exceptions can go to a named accountable owner. Finance exceptions can go to budget owners. The point is not to centralise every decision. The point is to make decisions legible across the estate.

This also changes the metrics. Instead of only reporting tasks completed, tokens spent or hours saved, teams should report exception rate by workflow, exception age, repeat exception type, override rate, stop rate, reviewer agreement and recurrence after remediation. Those measures show whether the agent is becoming more reliable or simply pushing ambiguous work onto humans in a less visible form.

See Gravitee's State of AI Agent Security Report 2026.

Build the taxonomy into the release gate

The right time to design the taxonomy is before the agent reaches production, not after the first incident. Start with the workflow map and mark every point where the agent reads data, reasons, calls a tool, changes a record, communicates externally, spends money or hands work to another system. For each point, ask what could be missing, conflicting, unauthorised, sensitive, manipulated, costly, time-critical or irreversible. Those answers become candidate exception classes.

Then turn the taxonomy into a release gate. Each exception class should have a clear owner, severity, evidence requirements, routing rule, service level, stop condition and test case. The test pack should include ordinary mistakes, adversarial prompts, stale knowledge, duplicate records, permission mismatches, customer vulnerability markers, supplier changes, failed APIs and ambiguous requests. The agent should prove that it can identify, label and route those cases before it gets wider autonomy. Where the agent cannot classify an exception reliably, the workflow should either narrow its scope or add a pre-action human checkpoint.

For many UK businesses, a practical first version can fit on one page. Use five columns: exception type, example trigger, agent action, human owner and evidence required. The point is not bureaucratic perfection. The point is to replace vague confidence with a repeatable operating pattern. Once live, review the taxonomy monthly for the first quarter. Add labels where reviewers keep using other, merge labels that cause confusion and retire labels that never appear.

The most useful mindset is this: autonomy is not the absence of human involvement. It is a designed relationship between machine action and human accountability. An exception taxonomy is one of the simplest ways to make that relationship visible. It tells the agent when to continue, when to ask, when to stop and what evidence to bring with it.

Frequently Asked Questions

What is an AI agent exception taxonomy?

It is a structured list of the abnormal situations an AI agent may encounter, with rules for labelling, evidence capture, escalation, stopping and recovery. It turns vague human oversight into a repeatable operating process.

How is this different from an error log?

An error log records what happened technically. An exception taxonomy explains what the business should do next. Many agent exceptions are valid technical actions that still create operational, security, customer or regulatory risk.

Which teams should own the taxonomy?

The workflow owner should own it, with input from operations, security, legal, data protection and finance where relevant. If the taxonomy sits only with engineering, it will miss the business decisions that make agentic AI risky.

Does every exception need human approval?

No. Low-risk exceptions can be retried, sampled or batched. High-risk exceptions, customer-impacting decisions, regulated decisions, security concerns and irreversible actions should usually require pre-action human review.

How detailed should the first version be?

Start small. A useful first version might have 10 to 20 exception types, each with a trigger, owner, evidence pack and next action. It should be detailed enough to test, but simple enough for reviewers to use consistently.

What evidence should an agent provide when escalating?

At minimum, include the user instruction, relevant data sources, retrieved evidence, proposed or completed tool calls, policy checks, confidence signals, cost information, timestamps and the reason the exception was triggered.

How often should the taxonomy be reviewed?

Review it monthly during the first quarter of production, then at each major workflow, model, tool or policy change. Repeat exceptions, reviewer confusion and high override rates are signs that the taxonomy needs adjustment.

Can this help with compliance?

Yes. It helps demonstrate that the business has considered oversight, recourse, bias, security, accountability and audit evidence. It does not replace legal advice, but it creates the operational evidence that compliance teams usually need.