Efforts to put autonomous agents to work in organizations have largely proceeded by building new coordination machinery: an orchestration graph, a planner, a bespoke protocol by which agents divide labor among themselves. We argue that this is unnecessary, and that the machinery already exists. Every organization runs its work as a state machine — items moving through states under entry and exit criteria, with an assignee, attached artifacts, and a history — and has done so since long before software. The proposal of this paper is narrow and, we think, consequential: leave that process untouched, and admit agents as executors of a subset of its transitions, addressed through the same assignment primitive that addresses humans. We give the conditions of admission as a five-part worker contract, derive from them the properties an existing process confers for free — legibility, governance, audit, graceful degradation, incremental adoption — and present a deployment taxonomy of personal, team, and production agents, distinguished by who holds the agent's instance. The arrangement's most useful consequence is social rather than technical: a person who knows nothing about artificial intelligence delegates work to an agent in the only vocabulary they already have — the one their organization already uses to delegate work to people.
Before any of this concerned software, organizations had already solved the problem of coordinating labor among many hands. The solution they converged on is so familiar that it is easy to stop seeing: work is broken into items; each item occupies a state; states are connected by transitions with criteria for entry and exit; each item has an owner for as long as it sits in a given state; artifacts accumulate against it; and the sequence of everything that happened to it is retained. A purchase order awaiting approval, a support ticket in triage, a manuscript out for review, an insurance claim under adjustment, a defect awaiting verification — these are the same object.
The formalism is old. Petri gave the mathematics of concurrent state transition in 1962 [1], and the workflow literature that followed made the correspondence explicit: a business process is a net, its work items are tokens, and its transitions fire when their preconditions are met [2]. What that literature also established is that the process is not incidental to the organization — it is a description of the organization. Conway's observation that a system's structure mirrors the communication structure of the group that produced it [3] is the same point seen from the other side: the process is where an organization has written down, in enforceable form, how it believes its work should be done.
Two properties of this arrangement matter for what follows. The first is that the process is substrate-independent in its logic and substrate-dependent only in its expression. States may be columns on a board, folders in a queue, stages in a pipeline, or statuses in a database record; assignment may be a field, a label, a component, or the physical location of a paper file. The logic is the same in each case, which is why the same person can move between two organizations using different tools and be productive in a week.
The second is that every executor of a transition is, historically, a human being. This is so deeply assumed that it is rarely stated. It is also the only assumption this paper proposes to change.
We have written previously on why an agent worth deploying should be one that persists — that has a continuous existence rather than being reconstituted per request [4] — and on the architecture of such an agent: a hub-and-spoke composition around an orchestrating agent, and an object model that separates the capabilities a system ships from the identity an agent accrues [5]. The present paper takes that architecture as given and asks what happens when it is deployed not for one owner but into an organization. It claims five things, and states them here so that they can be taken up, criticized, and reused.
What we do not claim is the substrate. Workflow formalism, coordination artifacts, and competing-consumer queues are all prior and are cited as lineage. The claim is the composition, and the taxonomy in particular.
The prevailing approach to multi-agent work is to build a second coordination system. One defines a graph of agents, the messages they exchange, the conditions under which one hands off to another, and the supervisor that decides when the whole thing is finished. This is a considerable amount of machinery, and it has a cost that is easy to underestimate: it is a coordination structure that no human in the organization can read, that duplicates decisions the organization has already made, and that must be kept in agreement with the process it runs alongside. When the two disagree — and they will — the organization has two accounts of how its work is done.
The alternative is to notice that a coordination structure is already present, already agreed, and already governed, and to put the agents inside it. The proposal in full:
Leave the process unchanged. Admit agents as executors of a subset of its transitions, addressed through the same assignment mechanism that addresses human executors.
What makes this more than a convenience is that the work item is already doing the coordinating. Star and Griesemer named the general phenomenon: a boundary object is an artifact plastic enough to satisfy the local needs of several parties while remaining recognizably the same thing to all of them [8]. A work item is exactly this. To the person who raised it, it is a request; to the one implementing it, a specification; to the reviewer, a claim to be checked; to management, a unit of throughput. Each reads it differently, and the shared identity across those readings is what allows them to cooperate without a common vocabulary. Hutchins made the complementary observation about state: coordinated work of any complexity keeps its state in the artifacts rather than in the heads of the participants, which is what allows participants to be replaced without the work collapsing [9].
Our claim is that this boundary extends to non-human executors, and that nothing in the definition resists it. An agent reads the item as a task specification and writes back an artifact of the type the seat requires. That the reader is not a person changes the parties to the cooperation, not the object they cooperate through. This is a very old idea about tools wearing new clothing: Licklider's symbiosis was a partnership in which the machine took the formulable part of a joint task and the human retained the judgment [6], and Engelbart's augmentation framework was explicit that the unit to be improved is the whole system of humans, artifacts, and procedures — not the human, and not the machine [7]. What is new is only that the machine's share can now include transitions that previously required judgment, and that it can be addressed through the ordinary mechanism rather than a special one.
It is worth marking the boundary of the claim, since it is narrower than it may sound. What the process supplies is coordination and governance: what work exists, who holds it, what must be produced, who reviews it, and what the record says afterwards. It supplies nothing whatever about how a worker does the work. An agent still needs an execution environment, model access, tools, credentials, retry and rate-limit behaviour, and someone to notice when it is unhealthy — a runtime, in short, and a substantial one. This is not a concession: human workers also require laptops, accounts, and a help desk, and no one takes that as evidence that the process was insufficient. The claim is not that agents need no engineering. It is that the engineering they need is a worker runtime, built beneath a coordination layer that already exists, rather than a second coordination layer built beside the one that does.
An agent cannot simply be pointed at a process. Admission requires five things, and we state them as a contract because they are jointly sufficient: an agent that satisfies all five can occupy a seat, and one that fails any of them cannot be trusted with work that humans depend on. The contract is deliberately small.
The agent selects work by a predicate over process state — for
instance, items in the verification state carrying the designator
agent/verification. Whether the predicate is evaluated by polling or
in response to an event is an implementation detail with no bearing on the
design. What matters is that the subscription is data rather than code: a
predicate can be widened, narrowed, or revoked without redeploying anything, and
this turns out to be load-bearing (§6).
The role designator is the second half of the mechanism, and the
half that faces the human. It is a marker on the work item saying: this
transition is to be executed by a non-human worker occupying role R. Its
concrete syntax is whatever the substrate already offers — a label, a
component, a custom field, a dedicated assignee account — and the design is
indifferent to which. We write designators here in a namespaced,
function-derived form (agent/implementation,
agent/verification, agent/release), naming the function
in the process rather than a job title, but this is a convention and not a
requirement.
The consequence is the point of the whole exercise. Delegating work to an agent is setting a field on a work item. There is no prompt to compose, no chat to open, no tool to learn, no model to select. A person who has never thought about artificial intelligence and does not intend to start delegates correctly on their first attempt, because they are doing the thing they already do. The work item is the intent expression, written in the organization's own language, and it was already being written.
An agent must take exclusive hold of an item before working it, or two workers will do the same job and disagree about the result. Organizations solved this long ago: assignment is mutual exclusion, and the assignee field is the lock. The agent claims by assigning the item to itself, and thereby also answers the human question — who has this? — in the ordinary place. The pattern is the competing-consumers arrangement familiar from message-driven systems [10], with the difference that here the queue is one the organization already reads.
Stated that plainly the rule is too simple, and the place it breaks is worth being precise about, because it is the one point where the substrate does not supply what a worker needs. An assignment field records who holds an item; it does not, on its own, guarantee that only one worker ever comes to hold it, nor does it release when a holder stops existing. Two workers reading an item at the same moment can both conclude it is free. A worker that dies mid-task leaves the item assigned to itself indefinitely — which is exactly the case condition 5 below claims is recoverable, and it is only recoverable if the claim can expire. A claim therefore needs three things the field alone does not have: it must be taken atomically, so that a losing writer learns it lost; it must be held as a lease that a working holder renews; and it must become reclaimable when the lease is not renewed. None of this is novel — it is the ordinary discipline of any queue with more than one consumer [10] — but it is real engineering, and the substrate provides it only in the degenerate case where workers do not fail. Human processes paper over the same gap socially, by noticing that someone has been out for a week. Agents fail faster and less visibly, so what was a social convention has to become a mechanism.
A worker requires its own environment: its own file system, its own execution context, and credentials of its own. The credentials are the subtle part, and we state the rule sharply because much follows from it: an agent is credentialed to the seat, not to a person. It receives the permissions the role requires and no others, which means its reach is bounded by a description the organization has already written, and can be audited against that description. An agent occupying a verification seat can do what verification requires; it cannot approve a release because that is a different seat.
The agent must emit what a human in that seat would have emitted: a change set, a test report, a provisioned environment, a written summary, a decision with its reasoning. Same artifact type, same location, same reviewers. This is what makes the agent's output reviewable by people who know nothing about how it was produced, and it is also the honest definition of the seat — a role in a process is characterized by what it must produce, and any worker that produces it has performed the role.
Finally the agent advances the item, or returns it to a state held by humans. The second half is not a failure mode but a first-class outcome: an agent that cannot complete a transition parks the item where a person will see it, with what it learned attached. A worker that can only succeed is a worker that will eventually succeed falsely.
The harder case is not the worker that stops but the one that does not know it should have. An executor may complete a transition, report success, and be wrong — producing an artifact that is plausible, well-formed, and defective. No condition in this contract prevents that, and none can, because the same is true of human executors and is the reason processes have reviewers at all. What the arrangement does provide is that the defect is caught the way defects were always caught here: by the artifact contract of condition 4, which obliges the worker to file its output in the form, place, and level of detail that the seat's reviewers already examine. A confident failure that arrives as a normal artifact is legible to a reviewer who knows nothing about how it was produced. Two design consequences follow, and they are decisions about seats rather than about agents. Which transitions are opened to agents is chosen by what their failure costs, not by what an agent can plausibly attempt. And where the cost of an undetected error is high, an agent's transition should move an item into a state a human holds rather than past one — not as an exception mechanism, but as the ordinary shape of that seat.
One consequence deserves stating because it is free and would otherwise cost real engineering. Since the item's state is the checkpoint, a worker that dies mid-task loses only its private progress; the item is still where it was, and a replacement resumes from the process rather than from a private journal. Crash recovery is inherited from the substrate.
The five conditions above are requirements on the agent. The reason to prefer an existing process to a purpose-built orchestration layer is what the substrate gives back, and it is more than convenience.
Legibility. Anyone in the organization can see what the agents are doing, because looking at the work is how they already see what anyone is doing. There is no separate console, no trace viewer, no second place to check. This matters most at the moment it is needed most: when something has gone wrong and the person investigating is not the person who set the agents up.
Governance. Review gates, approvals, segregation of duties, and the rule that certain transitions require a named human are already encoded in the process, and an agent admitted to the process inherits them by construction rather than by prompt. This is worth dwelling on, because it inverts the usual arrangement. In a bespoke agent system, the guardrails are instructions given to the agent — that is, they live inside the component whose reliability is in question. Here they live in the substrate, outside the agent, where they were already being enforced against workers whose reliability was also never guaranteed.
Audit. The history is native. Who held the item, what was produced, what was decided and when — recorded in the same ledger, in the same format, for human and agent workers alike, and retained by whatever policy the organization already applies.
Graceful degradation. When an agent fails, an item sits in a column with an assignee that is not doing anything. This is a condition organizations detect and correct constantly; the remedy — reassign it to a person — requires no knowledge of what the agent was. The failure mode of the system is the status quo ante, which is a rare and valuable property in automation and follows directly from having changed nothing but the executor pool.
Incremental adoption. The unit of adoption is one seat. An organization opens a single transition to a single agent, watches the artifacts for as long as it wishes, and either widens or reverts. There is no migration, no parallel run, no threshold of commitment below which the arrangement does not function. Reversal costs one field.
The common root is that these are properties of the process, refined over decades because human workers also fail, also need supervision, and also must be replaceable. Automation efforts routinely discard this and rebuild thinner versions of all five. The argument of this paper is that the rebuilding was never necessary.
Agents deployed this way are not all of a kind, and the distinction that matters is not capability or model or autonomy. It is the one drawn in [5] between what an agent is given and what it becomes: the class is what the system ships, always current and never forked; the instance is what accrues at runtime — identity, memory, learned practice — and is never overwritten. Every deployment shares the class. They differ in who holds the instance, and that single question produces three tiers.
| Tier | Instance held by | Continuity | Position in the work |
|---|---|---|---|
| personal | one owner | full, private | where intent is formed |
| team | the organization | shared; work state lives in the process | where transitions are executed |
| production | no one — capability without identity | none, by design | the architecture as a component of a product |
A personal agent is the arrangement described in [5]: one owner, one continuous instance, running on hardware that owner controls, accumulating memory and preferences over a long relationship. Its position in an organization's work is upstream. It is where a person thinks, and therefore where work is formed before it enters the process at all (§7).
A team agent runs continuously on shared infrastructure and occupies seats. Nobody installs it; it is simply present, as a colleague is present. Its instance belongs to the organization rather than to any individual, and this is the tier the worker contract was written for.
A production agent is the case that most tests whether the architecture is really separable from the identity. Here the same substrate is embedded as a component of a product — a service that answers a bounded question about a domain object, reached through an ordinary programmatic interface. There is typically no general prompting surface exposed to the end user and no continuity at all: each invocation is complete in itself. What the architecture supplies is the loop, the tool access, and the provider abstraction; what it deliberately withholds is the instance. That an agent architecture built around continuity also serves well when continuity is stripped out is not obvious, and we think it is evidence that the class/instance separation is drawn in the right place.
It is tempting to say that for a team agent the process is the memory — that because work state lives in the substrate, such an agent needs no private store. This is too strong, and the error is instructive. Two kinds of durable state are in play:
The test that separates them is replacement. If the substrate held everything, replacing a team agent would be an installation and a configuration file. It is not, as the next section shows. What must be carried across is practice, and the observation generalizes uncomfortably well: an organization's process is portable across workers by construction, but its practice is not, and is lost when a worker leaves unless it is deliberately transferred. This has always been true of people. It is one of the few problems agents inherit rather than introduce.
The tiers are not three parallel deployments. They compose, and the composition is the useful part: the personal tier is the administrative interface to the team tier. An owner does not provision, migrate, or re-scope a team worker by hand. They ask their own agent — the one that has continuity with them, knows their infrastructure, and holds their credentials — and it performs the administration.
Described in the abstract, decommissioning a worker on one host in favor of a worker on another involves: establishing access to the target; preparing an execution environment; installing the harness; confirming the new instance is live and reachable; transferring instance state from the outgoing worker; and verifying that the new worker's subscriptions resolve against the process. Each of these is an ordinary capability of the architecture in [5]. None of it requires machinery invented for the purpose.
Three consequences are worth drawing out.
Migration is a conversation, not a copy. The class/instance rule is what makes worker replacement tractable, and it prescribes two different treatments. The class — the harness and the capabilities it ships — is installed fresh on the new host, so the replacement arrives current rather than inheriting whatever the outgoing worker happened to be running. The instance — identity, memory, accrued practice — is what transfers. And it transfers over the peer-messaging primitive of [5]: the outgoing and incoming workers address one another directly, agent to agent — independent processes communicating by message, in the spirit of the actor model [11] — and the practice moves by the same mechanism any two agents use to say anything. Handover between workers is the ordinary form of the operation, exactly as it is between people. We regard this as the strongest available demonstration that the object model of [5] is doing work rather than describing it.
Subscriptions are data, not deployment. Giving an existing worker responsibility for an additional class of transition is a change to a predicate. It requires no redeployment, no code change, and no new worker — which is why §3 insists that a subscription is a predicate over process state rather than a hard-coded handler. In practice the re-scoping is expressed as an instruction to the administering agent, and the organization's process acquires a new kind of executor in the time it takes to say so.
Fleet operations are ordinary agent work. Provisioning, health-checking, migrating, and retiring workers are themselves tasks that agents perform. The population administers itself under human direction. The interesting part is not that this is possible but that it needs no mechanism the architecture did not already have.
An agent that can provision agents and widen their subscriptions is, stated plainly, a privilege-escalation surface: the reach of the entire fleet becomes editable in natural language. Any reader will form this objection immediately, and it deserves its answer in the same place rather than a later section. The architecture already implies the right controls; what follows is making them explicit.
Administration is a privilege of the personal tier, exercised by an identified owner, and it inherits that owner's authority and no more than it. The role-scoped credentials of §3 supply the bound: because a worker is credentialed to a seat, no agent — including an administering one — can grant a seat it does not itself hold. And widening a subscription is a governance act on the same footing as granting a person access to a stage of the process; it should be visible in the substrate, and reviewable there, like any other change to who may execute a transition. The general principle is the one that governs the whole design: the process, not the agent, is where authority is recorded.
Everything above concerns transitions inside the process. The more consequential opportunity may lie before the first state.
The dominant failure of automated execution is not incompetent execution. It is competent execution of an underdetermined request. Work items written by people who are not close to the system being changed omit exactly the constraints the executor most needs — not through carelessness, but because the author cannot know which of their assumptions are contested. A human executor repairs this quietly by asking someone, and the repair is invisible because it happens in conversation and is never written down.
Suchman's argument bears directly here: a plan is best understood not as a specification that determines action but as a resource for situated action, which the actor interprets against circumstances the plan's author could not see [12]. A work item is a plan in exactly this sense, and the human capacity to repair underdetermination on the spot is a large part of what makes processes work at all. An agent executor has less of that capacity and, more dangerously, less awareness of lacking it.
The remedy is available and sits naturally in the personal tier. Before an item enters the process, a person's own agent takes their request — expressed however they think of it — and checks it against what the organization knows: the state of the system to be changed, the documented decisions bearing on it, the constraints the last similar item ran into. It returns a well-formed item: scope, constraints, acceptance criteria, references. The person still decides what they want. What they are relieved of is knowing how to say it in the form the process requires.
The result is an organization in which agents participate at both ends of the machine — helping form work as personal agents, executing transitions as team agents — while the process between the two ends is exactly the process that was there before.
§7 assumes something not yet established: that there is a place an agent can consult to learn what the organization knows. We describe it here as a design requirement rather than as a deployed component, and mark the distinction plainly.
The framing we find most useful is by analogy. A shared knowledge space is to an agent population what memory is to a single agent. Each function of an organization — engineering, sales, marketing, operations, leadership — publishes into one addressable place what it wants the others to know: not documentation of itself for its own use, but the standing context it wishes its colleagues had. Agents read from it in order to act with organizational context instead of local context only. Like the process substrate, it should be substrate-agnostic by design: a wiki, a repository, an object store. A design that depends on which has failed the same generality test this paper applies everywhere else.
One property distinguishes such a space from a wiki, and we think it is the interesting one. The artifacts it holds need not be prose. An agent can publish a small interactive tool — a calculator that encodes how a team actually computes something, a viewer over a dataset, a checker for a rule that is otherwise tribal — and another agent, or a person, can use it. Knowledge that runs is a different object from knowledge that describes: it cannot rot silently into disagreement with practice, because its output is checkable. A shared space in which the units are executable is a plausible answer to the oldest failure of institutional knowledge, which is that writing it down does not keep it true.
It is also the part of this design with the largest attack surface, and we would rather name that than let it be discovered. A space that agents both write to and read from is a channel by which one agent's output becomes another's input, and two properties are required before it is safe to build. The first is that executable artifacts run inside the reader's isolation, never widening it: by the rule of §3, a worker holds the credentials of its seat, so an artifact it retrieves from a shared space must execute with no more authority than the seat already has, whatever the artifact was written to do. Publication into a shared space is not a grant of privilege, and a design in which it becomes one has reconstructed the escalation path §6 exists to close. The second is provenance: what an agent reads from such a space is data, and it must be evaluated as a claim from an identified publisher rather than obeyed as an instruction. This is the same discipline a careful person applies to a wiki page of unknown authorship, and it is harder to hold to for an agent, which is exactly why it belongs in the design rather than in a later operational note.
We are describing this because the architecture points at it, not because we have run it. It belongs in the same category as the research directions of [4]: a stated next step, offered for others to take up.
An argument of this shape carries a specific risk. Every illustration so far could be read as a software-engineering pattern that has been overgeneralized into a claim about organizations. The claim is general, so it should be shown to be. The five-part contract instantiates against processes with no software in them at all.
Consider a support and incident queue. Subscription: items in triage bearing a designator for automated first assessment. Claim: the queue's existing ownership field. Isolation: read access to systems bearing on the customer's issue and to no others. Artifact: the same first-response note and severity classification a human triager would file. Transition: to the responsible team, or to a human triager when the classification is not confident. The process is untouched; the escalation policy that governed it still governs it.
Consider a qualification stage in a sales pipeline. Subscription: opportunities entering qualification with the designator set. Claim: pipeline ownership. Isolation: access to the customer record and public sources, not to pricing authority. Artifact: the qualification summary against the criteria the organization already uses. Transition: advance, or return for a person's judgment. Note what is not claimed — the seat that commits to a price is a different seat, and the isolation rule is what keeps it so.
Consider a document review and approval chain. Subscription: documents in review carrying the designator. Claim: the review assignment. Isolation: the document and the standards it is reviewed against. Artifact: the review comments in the form reviewers file them. Transition: to approval, or back to the author. The signature that constitutes approval remains a human act, because the process already said it must be.
In each case the contract maps without modification, and in each case the governance the organization already had is what bounds the agent. This is the generality claim made concrete: what varies between processes is the vocabulary of states and artifacts, which the agent reads from the process; what does not vary is the shape of admission.
The most common way to introduce autonomous agents into an organization is to build a system beside the organization and hope the two can be reconciled. We are proposing the opposite: that the organization's own process — its state machine over work items, refined over years, understood by everyone, and already carrying the governance the organization believes in — is the correct coordination substrate for agents, and that the work of integration is mostly the work of admitting a new kind of executor to a structure that was already designed to survive the replacement of its workers.
What this buys is not primarily throughput. It is that the arrangement stays legible to the people inside it. The work is where it always was; the history reads as it always did; a failure looks like an item that has stopped moving; and the person delegating needs no new concepts, because setting a field on a work item is what they were doing yesterday. An organization can begin with one seat and stop whenever it likes.
We have described the agents as workers throughout, and the choice is not rhetorical. A worker is defined by a process rather than the reverse: it is admitted to a seat, credentialed to that seat, held to the artifacts that seat produces, and replaceable without the work being lost. Those constraints were not invented for agents. They are what organizations already know about coordinating labor that is fallible, partial, and impermanent — which is the only kind there has ever been.