Hand-offs through artifacts
No agent calls another. Each writes a durable artifact — a work item, a branch, a pull request, a build result — and that written artifact is what starts the next agent. The hand-off is a document a person can read, which is what makes the pipeline inspectable and reversible.
A relay race hands the baton over directly. This works more like a hospital ward: each person writes in the notes and leaves them at the foot of the bed, and the next person reads them. If somebody goes off shift mid-task, the notes are still there.
The first design decision in a factory is not which model to use. It is whether an agent is allowed to talk to another agent. Say yes and you get a system whose behaviour lives in transcripts nobody keeps; say no and every hand-off becomes a document, which is slower to build and the only version that can be audited, resumed or undone.
An agent does not call another agent#
The rule is narrow and load-bearing: an agent finishes by writing something durable, and the writing is what starts whatever comes next. A planner writes a work item. A builder writes a branch and opens a pull request. A reviewer writes comments and a verdict. A pipeline writes a build result. Each of those is a record that exists independently of the run that produced it.
Notice what the figure does not contain. There is no arrow from one agent to another. The horizontal distance between the builder and the reviewer is crossed only down at the artifact layer, because that is the only place the crossing can be seen. An arrow between the two boxes would be a channel with no reader.
Three things fall out of that, and they are the reasons to accept the cost. A person who was not there can reconstruct what happened, because the reconstruction is just reading the artifacts in order. Any step can be re-run, because its input still exists. And anything an agent did can be undone the same way a colleague’s work would be — revert the commit, close the pull request, reopen the item.
What the orchestrator is actually for#
Nothing runs a model inside a ticket tracker. Something has to notice that an artifact changed and start the right agent, and that something is a service you host. A pull request opens; the forge sends a signed message to a URL you own; the service checks the signature, ignores the duplicate it will inevitably receive, decides whether this event is worth acting on, and starts a fresh container with narrowly scoped, short-lived credentials injected at run time.
This is not a contradiction of the rule above. The event that fires is the artifact changing — a pull request opening is not a separate message about a pull request opening, it is that pull request existing. The orchestrator is how a written artifact becomes a running process, and the test of whether it has quietly become a side-channel is simple: could you reconstruct the whole run from the artifacts alone? If yes, it is plumbing.
The stronger version of this design goes one step further and stops the model performing most external writes at all. Rather than handing an agent a broadly capable tool and hoping the instructions constrain it, the model produces a structured proposal — an action name, a target, a payload — which is validated against a schema, checked against a policy for that workflow, and only then executed by ordinary code. A malformed proposal fails validation instead of reaching the tracker. This is how a rule like never overwrite what the requester typed stops being a convention and becomes an action the agent’s own credentials cannot perform.
Where the state really lives#
The tempting shortcut is to run the whole workflow out of the ticket tracker: claim work by setting an assignee, mark progress with labels, recover by looking at which items are stuck. It reads well and it works for a while, and it fails the first time two runs claim the same item within the same second, because labels and assignees have no transactional semantics to offer you.
The split that holds is four-way. The tracker holds business intent and the status a person reads. The forge holds review state. The orchestrator’s own store holds workflow state — which run owns what, under a lease that expires, on which attempt, against which version of the instructions. And a ledger holds run history: the item, the model, the harness version, the tool calls, the commits, the cost. The tracker can show a projection of the workflow state, and should. It must not be where the locking lives.
Two consequences arrive immediately and both are worth planning for. A run that dies after claiming work has to be recoverable, which means leases rather than flags. And because a retried step will sometimes repeat an action that already succeeded, every write an agent performs has to be safe to repeat — the same discipline that makes a repeated request a routine case rather than a second one, applied to comments, branches and work items. Neither of these is an AI problem. They are the ordinary distributed-systems problems that a factory inherits by being a distributed system, and they are the parts you cannot ask a model to be careful about.
Which is also why none of this needs to be built before the first agent runs. A first workflow can be a pipeline step, an isolated runner, one agent command, a structured result stored as an artifact, and a person reading it. The durable queue, the leases and the ledger earn their place when work starts waiting days for a human answer and surviving restarts — not before. What does need to exist from the first run is the instruction set the agents share, because that is the thing every one of them reads.
IF YOU REMEMBER ONE THING
If two agents can reach each other without leaving a document behind, you have built a system whose behaviour cannot be reviewed. The document is not overhead — it is the product of the step.
Questions people also ask
4 QUESTIONSWhy not just let one agent call the next directly?
Because the call leaves no record anyone can read. A direct hand-off exists only inside the run that made it, so nobody can inspect what was passed, nobody can replay it, and nothing survives the process dying. Writing a work item or a pull request costs a few seconds and produces an artifact that a reviewer, an auditor and a retry can all read afterwards.
Doesn't the orchestrator become the hidden channel you were avoiding?
Only if it carries meaning. The orchestrator observes that an artifact changed and starts the right agent in a clean environment — it is the mechanism by which a written artifact wakes something, not a second path the work can travel down. The test is whether you could reconstruct what happened from the artifacts alone. If you can, the orchestrator is plumbing.
Should the ticket tracker hold the workflow state?
No. It should hold intent and human-visible status, which is what people read it for. Atomic claiming, lock leases and crash recovery need transactional semantics a tracker does not offer, so they belong in the orchestrator's own store, with the tracker showing a projection of that state. Building distributed locking on labels and assignees works until two runs collide.
What stops two agents claiming the same work?
An atomic claim in the orchestrator's own store, and a lease with an expiry so that work claimed by a run that then died becomes available again. Both are ordinary distributed-systems problems rather than AI problems, which is the point: the parts of a factory that must not be wrong are the parts where no model is involved.