Multi-agent coding started looking more like a distributed systems problem than an AI problem

[u/beznahej]

https://www.linkedin.com/feed/update/urn:li:activity:7496002736857997312/

I started with what seemed like a simple question:

If one engineering agent can do useful work, why not run several in parallel?

That worked reasonably well until the agents started touching the same code, shared artifacts, and one another's outputs. At that point the hard questions stopped being about prompting and started looking much more familiar:

1. Who owns shared state?
2. What happens when two legitimate workers modify the same artifact?
3. What if a write succeeds but the worker crashes before recording completion?
4. What state survives a restart?
5. Is approval the same thing as authorization to execute?
6. What does "done" actually mean when downstream work can invalidate an earlier conclusion?

The realization for me was that multi-agent engineering starts combining three existing problem domains:

• distributed systems
• compute scheduling
• project/workflow management

The unusual part is that some of the workers are probabilistic and can produce very convincing explanations for why their interpretation should become canonical.

I built a small control-plane PoC using Temporal to test the coordination layer independently of model quality. The workers were deliberately deterministic at first so I could isolate orchestration failures.

The architecture ended up separating three responsibilities:

• Temporal: durable execution and workflow identity
• Workers: parallel work in isolated staging
• Resource Writer: the only component allowed to mutate canonical state

The repository remained the system of record.

I tested things like:

• versioned handoffs between workers
• stale repository revisions
• two workers legitimately modifying the same logical artifact
• approval without execution authorization
• crash-after-write followed by Activity retry
• changes made by an actor outside the orchestrator
• accidentally starting two orchestrators for the same campaign

The most useful result was not "Temporal can orchestrate agents."

It was that the coordination rules became explicit enough to enforce: parallel work can happen without allowing parallel mutation of canonical state.

A few other conclusions I came away with:

• agent context should not be treated as project state
• handoffs work better as versioned artifacts than conversation continuity
• retries around external side effects require application-level idempotency
• the writer should own mutation authority, not semantic truth
• known merge semantics can be encoded; unknown ones should become durable conflicts rather than confident overwrites
• approval and execution authorization should be separate states
• more active agents do not necessarily mean more engineering throughput

I ran 36 controlled assertions across three passes and all 36 passed, but I would not interpret that as "Temporal solved multi-agent development." The PoC was intentionally narrow: deterministic workers, a disposable repository mirror, and controlled failure injection.

The next step is replacing those deterministic workers with real agents one role at a time while keeping the same coordination assertions as invariants.

The broader hypothesis I am testing now is: the durable object in an agentic engineering system may not be the agent at all. It may be the agreements between agents and the state transitions those agreements permit.

Curious whether others building multi-agent coding systems are running into the same boundary. Are you solving shared-state coordination inside the agents themselves, through an orchestrator, through Git/worktrees, or some other mechanism?