Many agents, one ledger, one order of events.
When several agents work the same records, something has to decide who goes first, what locks, and what happens when two of them reach different conclusions. That is orchestration, and it is the part most agent demos skip.
Deterministic ordering·Record-level locking·Conflict resolution
What keeps a dozen agents from fighting.
Every mechanism below is a database and distributed-systems problem rather than a model problem. That is precisely why it is the part that gets skipped.
Ordering
Same inputs, same result, every time.
Deterministic sequencing
Work is ordered by a declared rule rather than by which agent happened to wake first, so a run is reproducible.
Declared precedence
When two agents are eligible for the same record, a stated priority decides — not a race.
Dependency edges
An agent can be declared to run only after another has finished with a record, so chains are explicit.
Idempotent steps
Re-running a step that already applied does not apply it twice, which is what makes retry safe.
Locking
One writer at a time, on the record itself.
Record-level claim
An agent holds a record while it works. Nothing else writes underneath it, including a person.
Visible holds
A held record shows who holds it and since when, so a stuck job looks stuck rather than slow.
Lease expiry
A claim expires if the holder stops responding, so a crashed agent does not hold a document indefinitely.
Human override
A person can break a lock and take the record, with the break recorded on the trail.
Conflict
What happens when two agents disagree.
Declared resolution
A stated precedence decides, or the item routes to a person. There is no configuration in which it is resolved by timing.
Both positions kept
The losing conclusion is recorded alongside the winning one, because a pattern of disagreement is a signal about your rules.
Escalation on repeat
The same conflict recurring is raised as a rules problem rather than resolved silently a hundred times.
Chain-wide segregation
Segregation of duties is evaluated across the whole path, so three agents cannot compose an approval between them.
Backpressure
What happens when there is more work than capacity.
Bounded queues
Queues have limits. Work waits rather than piling into a half-finished state that somebody has to unpick.
Fair scheduling
One agent with a large backlog does not starve the others, which is how an urgent ticket ends up behind a bulk run.
Shedding with a record
Where work is deferred, it is deferred visibly with a reason, not dropped.
Rate limits per agent
A ceiling on actions per period, which doubles as the blast-radius control if a rule is wrong.
Transactions and replay
All of it, or none of it, and readable afterwards.
Atomic commit
Actions apply as one unit. A failure halfway leaves no partial posting and no half-moved stock.
Compensation
Where a step genuinely cannot be rolled back, its compensating action is declared in advance rather than improvised.
Full replay
Any run can be replayed against the same records to see exactly what happened, step by step.
Handover
A person can take a job off an agent mid-flight and finish it themselves, with the partial work preserved.
What happens when a document arrives.
Four phases, and the reason the third is separate from the second: nothing writes until the whole plan has been checked against the limits.
- 01
Claim
One agent claims the record. Others see it is held and move to the next item.
- 02
Plan
The steps are resolved against the agent's tools and limits before anything runs.
- 03
Commit
Actions apply as one unit. A failure halfway leaves no partial posting.
- 04
Release
The lock lifts, the trail is written, and downstream agents are notified.
The specification.
The properties an architect will want to see stated rather than implied.
- Ordering
- Deterministic, by declared precedence and dependency
- Isolation
- Record-level claim with lease expiry
- Atomicity
- Multi-step actions commit as one unit
- Retry
- Idempotent steps; safe to re-run
- Conflict
- Declared precedence, or human; never resolved by timing
- Queues
- Bounded, fair-scheduled, per-agent rate limits
- Observability
- Full replay against the same records
- Interruption
- Human break-lock and handover, both recorded
What orchestration does not solve.
It makes a multi-agent process safe and legible. It does not make it a good idea.
- It will not make a chain worth building
- Most work needs one agent, not four. A chain is worth it when the steps genuinely span functions, and not because it demonstrates well.
- It does not improve accuracy
- Sequencing three agents correctly does not make any of them right. Accuracy comes from grounding and from proposal mode.
- It cannot compose away a limit
- Three agents with small ceilings do not add up to one large ceiling. That is deliberate and cannot be configured off.
- It is not a message bus
- This coordinates work on your records. Moving data between external systems is integration, and it has its own page.
Next step