KPMG's TACO Framework Sorts Agents, Not Risk

KPMG has a framework for agentic AI, and the acronym is memorable enough that people repeat it before they understand it. TACO (opens in a new tab) stands for task, automation, collaboration, and orchestrator agents.

Four kinds of agent, sorted by how much of the work they do on their own. A task agent executes one defined step. An automation agent runs a workflow end to end. A collaboration agent works alongside a person who keeps the decision. An orchestrator agent coordinates other agents.

That is a useful set of names, and it is a good way to open a conversation with an executive who thinks "AI agent" means one thing.

The names describe how much intent an agent supplies. They do not describe how much damage it can do.

Confusing those two is the mistake I see most often, and it costs money in both directions.

What the four tiers actually sort

Read the tiers as a spectrum of interpretation.

A task agent is given a step and a format. There is not much to interpret, which is why the failure mode is boring: it does the step wrong, at volume, until somebody notices.

An automation agent is given a process. Now it interprets exceptions, chooses branches, and decides when to escalate. The failure mode changes: it completes a path a human would have stopped.

A collaboration agent is given a role in someone else's judgment. It drafts, recommends, or analyzes, and a person decides. The failure mode is subtle: the person starts approving without reading.

An orchestrator is given a goal and a set of tools, including other agents. It decides what work to delegate. The failure mode is the one that should keep a program manager awake: a plan nobody wrote, executed correctly.

The tiers are real, and the distinction between them is worth teaching. KPMG's contribution is the vocabulary, and the vocabulary is doing work that "agentic AI" was not doing, because it forces a speaker to say which of the four they mean.

Why the label is the wrong control

The label describes a deployment at a moment. It does not stay true.

An orchestrator runs task agents inside it, so a single run can contain three tiers. A collaboration agent that starts suggesting and ends up auto-approving has become an automation agent without anyone changing a slide. A task agent with write access to a production table has a blast radius that the word "task" does not communicate.

That is the trap. A governance board classifies a system as a Collaborator, applies human-in-the-loop review, and signs off. Six months later the review threshold has been lowered twice for throughput, and the same system is executing decisions with a human watching a dashboard.

Nothing in the framework was violated. The classification was just treated as a property of the product when it is a property of the configuration.

The second problem is coverage. A taxonomy sorts agents. It does not tell you what an agent did. If the review question is "was this action authorized," the answer is not in the tier. It is in the record of the action, which the framework does not require.

Attach oversight to the action

The control that survives all four tiers is the action class.

Classify by consequence rather than by agent type. A read is a read whether it comes from a task agent or an orchestrator. An outbound email is an outbound email. A spend, a permission change, and a production write are the same three risks regardless of which tier executed them.

Then set a gate per class, and make the gate code rather than a policy paragraph.

• Reads: no approval, but logged.
• Internal writes: review before commit.
• Outbound communications: blocking approval, per message, with the exact text attached.
• Money: a ceiling, then approval above it.
• Permission changes: two approvers, and a channel the agent cannot reach.

That structure is tier-agnostic, which is its virtue. When a Collaborator quietly becomes an Automator, the gates do not move. When an orchestrator spawns a sub-agent nobody designed, the sub-agent inherits the same action classes, because the class is a property of the effect and not of the caller.

The tier then has a narrower and more honest job. It tells you where to look first when you are reviewing a design, and it tells you how much of the reasoning you need to be able to reconstruct. An orchestrator needs a plan you can replay. A task agent needs an input and an output. That is a documentation requirement, not a governance regime.

What this costs in a regulated shop

In a federal or regulated context, the framework runs into two hard edges.

The first is accreditation. An authorizing official does not accredit a category. They accredit a system with a boundary, and the boundary has to be drawn around the systems that process the data. An orchestrator that reaches into four systems has a boundary that spans four systems, and the security assessment follows the boundary, not the label.

The second is evidence. Audit and oversight functions ask for artifacts. A framework that classifies agents produces a classification memo. A program that classifies actions produces a log, a gate record, and a replay. The second one answers the question; the first one describes the intention.

There is a procurement version of the same point. If a vendor tells you their product is an "orchestrator," ask which action classes it can execute, which gates it enforces, and what record it emits. The answer tells you more about the risk than the category ever will.

Use the vocabulary, build the record

None of this makes the framework wrong. It makes it a starting point, and starting points are worth having.

Use TACO to get four people in a room to mean the same thing when they say "agent." Then use the conversation to do the work the taxonomy cannot: name the actions, set the gates, and decide what a reviewer needs to see.

The category tells you what kind of system you bought. The record tells you what it did. Only one of those is defensible in a review.