The word "agent" has stopped being usable. It bundles systems that pose completely different problems and pretends they are one thing, and that single word is now hiding the only distinction that decides how you build. There are four classes underneath it, and separating them is not taxonomy for its own sake. The class a system belongs to decides whether your existing stack is enough or whether it is about to fail you, and most teams cannot tell which situation they are in, because they are using one word for all four.
The four are assistant, orchestrator, operator, and economic actor. They are not four levels of intelligence, and they are not a maturity ladder. A team can ship a brilliant assistant and a crude economic actor in the same quarter. What separates the classes is not how well the system thinks. It is the authority it holds and the boundary that authority has to cross. Get the class right and the rest of the design follows. Get it wrong and you either over-build controls nobody needs or, far worse, deploy an assistant-grade control plane underneath something that is quietly moving money.
Core claim
- "Agent" is not one system. It bundles four classes — assistant, orchestrator, operator, economic actor — and the classifier is authority, not intelligence.
- The same model can sit in any of the four. What changes is the authority the system holds and the boundary that authority has to cross.
- Mandate intensity scales by class. An assistant needs almost none of the mandate's fields; an economic actor needs all of them, and needs them portable.
- The conventional enterprise stack is genuinely sufficient for assistants and orchestrators, strained for operators, and structurally broken for economic actors.
- The dominant strategic error is category inflation in both directions: dressing an assistant as an economic actor, and dismissing the economic-actor class as hype.
The classifier is authority, not capability
The instinct is to rank agents by what they can do. That instinct is wrong for this purpose, because capability and class are nearly independent. A frontier model wired to read-only tools and hand its output to a human is an assistant, no matter how sophisticated its reasoning. A small, dull model holding a standing key that can move funds between organizations is an economic actor, no matter how unimpressive its cognition. The model is the engine. The class is the question of what the engine is allowed to do and on whose behalf, and across which boundary that permission has to survive.
This is why "our agent is very capable" tells you almost nothing about how hard it is to operate safely. Operational difficulty is set by the authority, not the intelligence. Two systems running the identical model can belong to different classes and need different control planes, different failure analysis, and different answers to who is accountable when it goes wrong. Splitting the classes is how you stop the impressiveness of the model from standing in for the seriousness of the authority. Those are different axes, and only one of them breaks your stack.
The four classes
Read each one by the authority it holds, not the demo it gives.
Assistant. Produces output a human consumes and acts on. It drafts, suggests, recommends, and the authority never leaves the human, because nothing it produces becomes an effect until a person commits it. A coding copilot proposing a diff, a research assistant returning a memo: the system can be extraordinary and still hold no authority of its own. This is most of what ships under the word "agent" today, and it is a genuinely useful class that barely needs a mandate, because the human's presence is still the authority. The control problem here is quality, not delegated power.
Orchestrator. Coordinates tools and sub-agents toward a goal inside one trust domain. It holds real delegated authority, because it commits effects without a human on every step, but the authority is bounded, human-owned, and local: it runs on the organization's own systems, against its own data, under its own policy. A remediation agent that reroutes traffic around a failing service, a pipeline that triages and files routine tickets, a back-office agent that reconciles against the company's own ledger. Real effects, committed autonomously, all inside the walls. This is the class where the conventional stack earns its keep, and the orchestrator needs only the part of a mandate that can be assembled from primitives that already exist.
Operator. Holds standing authority over time, rather than the task-scoped authority of an orchestrator. That single shift, from "do this task" to "keep this running," is what makes it a separate class and not just a smarter orchestrator. It acts continuously on real systems with real side effects, at the edge of its home domain and against known counterparties: a system that manages infrastructure, reconciles accounts, or maintains a position. It is still not an economic actor, because its durable authority lives inside a domain it largely controls and does not yet commit value an outside party has to honor. But the persistence is where the conventional stack starts to strain: revocation that was clean for a short task gets awkward against a standing process that has already propagated state, accountability blurs across a long history, and current behavior comes to rest on grants nobody has re-examined since they were issued, against an environment that has drifted underneath them. Nothing has broken yet, but the seams are load-bearing.
Economic actor. Commits value across organizational boundaries on a standing mandate. This is the class everyone gestures at when they say "autonomous agents" and the one almost nobody is actually running where money is involved. An agent that pays suppliers, settles a trade, or rebalances funds across institutions on a standing authorization is in this class the moment it commits value the other side has to honor. The authority here crosses domains, persists without supervision, and is denominated directly in money and liability. It is not enough for the system to be trusted inside one company's walls; its authority has to be legible and enforceable to counterparties who do not share its trust assumptions. This is the class that needs the entire portable mandate, every field, carried intact across every boundary it touches. It is also the class where nothing clean exists today.
The classes shade into each other; a sophisticated orchestrator with external reach starts to look like an operator, and an operator that begins committing cross-organizational value is becoming an economic actor. The cuts are a tool for locating where you are, not a law of nature. But the gradient is real, and it runs along exactly one axis: how much authority the system holds and how far that authority has to travel from the human who granted it.
Mandate intensity scales by class
The earlier piece in this cycle described a mandate as six fields that have to travel bound together: principal, scope, expiry, revocation, accountability, and spend semantics. The classes need very different amounts of that object, and you can read the requirement straight off the class.
An assistant needs almost none of it. The principal is the human sitting right there, the scope is "draft something for me to look at," and nothing settles without a person pressing the button. A full mandate object here is wasted engineering.
An orchestrator needs a local subset: a principal it can carry through a delegation chain, a scope narrow enough to bound what it commits, an expiry, and a revocation path, all inside one domain and all assemblable from existing tools. It does not yet need portable accountability or a settlement envelope, because it neither crosses organizational lines nor moves value on its own authority.
An operator needs that same subset, hardened for persistence. Its revocation has to reach a standing process, not just expire a token; its accountability has to survive a long history, not a single trace. Same fields, durability stress.
An economic actor needs the whole object, portable. Every field has to survive a trip across an organizational boundary, including the two the lower classes can mostly ignore: an accountability record a counterparty can rely on, and a spend envelope enforceable where value actually moves. This is not a bigger orchestrator problem, it is a different one, because the boundary the authority crosses is owned by no single party. That is the precise point where the conventional stack stops being enough.
Where the enterprise stack actually stops
It is fashionable in some quarters to argue that agentic systems make conventional enterprise architecture obsolete. They do not, and the taxonomy shows exactly why. For three of the four classes, the existing stack is either sufficient or nearly so, and saying otherwise is either ignorance or a sales motion.
For assistants and orchestrators, the conventional stack is genuinely enough. Identity, policy, fine-grained authorization, workflow durability, approval gates, and observability are mature, deployable, and well understood. An enterprise running internal copilots and domain-local orchestrators does not need a new substrate, a new trust model, or anything exotic. It needs to assemble primitives it can already buy, and the main failure mode is not architectural inadequacy but teams not bothering to assemble them. This deserves to be said plainly: the point is not that everything must be rebuilt. Most of what ships as "agentic" today is well inside the boundary where ordinary engineering wins.
For operators, the stack strains without breaking. Standing authority and continuous operation expose the weak joints described earlier: revocation that does not cleanly reach an in-flight process, accountability that gets harder to establish the longer the operator runs, scope that has to be re-checked as the environment drifts underneath a long-lived grant. These are real problems, and they are mostly addressable with discipline: short-lived credentials refreshed against current policy, explicit cancellation paths, hard expiry on standing grants, and accountability records kept deliberately rather than reconstructed after the fact. The operator is the class where good teams start doing extra work and bad teams start accumulating quiet risk. The asymmetry is what makes the class treacherous: the cost of the discipline is visible and immediate, while the cost of skipping it stays invisible until a standing grant does something nobody scoped it for.
For economic actors, the stack breaks, and it breaks structurally rather than for lack of effort. The defining move of the class is that authority crosses an organizational boundary and gets denominated in money. The conventional stack was built to govern authority inside one administrative domain, and almost every one of its strengths is a within-domain strength. Authorization that another organization cannot read. Revocation that cannot reach effects in systems you do not operate. Traces that explain execution inside your walls but establish nothing a counterparty can rely on in a dispute. None of this is a deficiency of the tools. It is a mismatch between what the tools govern and what an economic actor requires, which is a mandate that stays intact and enforceable across a boundary no single party owns. That is the missing object, and the economic actor is the class that cannot function without it.
So the boundary the whole cycle has been circling turns out to be a specific line in the taxonomy, not a vague horizon. It sits between the operator and the economic actor, at the moment authority has to leave the domain that granted it and remain both legible and enforceable on the other side.
Category inflation runs both ways
The practical danger is not getting the philosophy of agency wrong. It is misclassifying a real system, and that error is expensive in both directions.
Inflate upward and you call an assistant an autonomous agent, or an orchestrator an economic actor, and you either frighten yourself into building controls the system does not need or, more commonly, you market a capability you have not actually shipped. Most "autonomous agent" launches are orchestrators with a confident tone. That is not a scandal, orchestrators are useful, but the inflation muddies every downstream conversation about risk, because now the word that is supposed to signal "this moves money across boundaries" has been spent on something that drafts emails.
Deflate, and you make the opposite mistake: you treat the economic-actor class as pure hype because everything you have personally seen is an assistant, and you conclude the whole category is a demo that will never touch production. That is also wrong. The class is real, it is forming, and the reason it is rare is precisely that the control object it requires does not exist yet, not that the demand is imaginary. Dismissing it means you will be unprepared for exactly the systems that carry the most risk when they do arrive.
There is a third version of the error that is worse than either, because it happens without a decision. A system ships as an orchestrator, correctly classified, with a control plane that fits. Then it grows. An integration reaches a partner's system, a standing key picks up a slightly broader scope, a workflow starts committing value that used to be staged for human review. No single change looks like a reclassification, and nobody re-runs the question, so the authority quietly crosses into a higher class while the control plane stays where it started. The system is now an economic actor governed like an orchestrator, and the gap between what it can do and what its controls assume is exactly the unmonitored space where the expensive failures live.
The costly version of the error is the operational one, and it is the same failure the mandate article identified from a different angle. Deploy an assistant-grade control plane underneath a system that has quietly become an economic actor and you have built the conditions for mis-scoped action under ambiguous authority, now with money attached. The system acts across a boundary on authority no one can cleanly establish, nothing errors, and the first time anyone notices the class was wrong is when the loss is already denominated. Classifying correctly is not an academic exercise. It is how you decide how much control plane a system actually warrants before it is the thing teaching you the answer.
What the economic actor needs next
Splitting the word "agent" does one useful thing above all: it tells you where to spend. Three of the four classes are well or adequately served by architecture that already exists, and the entire frontier of difficulty concentrates in the fourth. That is a more actionable map than "agents are hard," because it says plainly that the assistant and orchestrator you are shipping this quarter are an engineering problem with known tools, and the economic actor you are imagining is a different problem that the existing stack cannot reach.
It also reframes the next question. Once the boundary is located at the economic-actor class, the interesting work is no longer "what can agents do" but "what does this specific class require to operate safely across organizations." Some of that is the portable mandate this cycle has already named. But a mandate is a static object, and an economic actor is a living system that has to be governed over time: granted, monitored, constrained, audited, and wound down, across parties who do not share a trust domain. The control object is necessary and it is not sufficient on its own. What the class needs around it is an operational layer — governance, lifecycle, and auditability that hold up between organizations rather than inside one.
The takeaway of this article stands on its own: misclassify the system and you mis-size the control plane, and mis-sized control planes are where the expensive failures begin. The lower classes are not lesser, they are largely solved. The honest center of this conversation is the one class where they are not, and what that class needs around the mandate is the next article.