# Coordinating autonomous software agents under shared mutable state > An empirical case study of autonomous software-engineering agents coordinating shared mutable state through explicit invariants, state-dependent evidence and minimum necessary serialisation. Paper: Technical paper — 03 Published: 2026-09-15 Canonical: https://harten.io/papers/coordinating-autonomous-software-agents-under-shared-mutable-state/ Cover illustration: [View the title image](https://harten.io/media/papers/covers/v1/coordinating-autonomous-software-agents-under-shared-mutable-state.jpg?v=8cfd7b672765). Illustrative cover artwork, not an application screenshot or a record of measured results. By Lavan Nallainathan · Harten Technologies ## Abstract As software-engineering agents become capable of carrying substantial work independently, the coordination problem changes. The question is no longer only whether one agent can reason, use tools or execute a long-running task. It is how multiple independently reasoning agents can operate against the same evolving system without invalidating one another's work, evidence or authority. This paper reports an empirical case study from Harten in which concurrent HART agents worked against a shared repository through Codex. They declared ownership, continued non-conflicting work independently, coordinated around conflicting shared-state mutations, preserved unrelated working state, and used Git-Hart to bind review evidence to the state against which it had been produced. During the observed sequence, a reviewed change became stale because the repository advanced before integration. Integration stopped. The change was rebound to the new base, validation was reproduced and independent review was repeated. In parallel, another HART continued an isolated model diagnostic, yielding only shared-repository writes. We describe this pattern as **coordination by invariants**. The evidence is preliminary, but it motivates a testable proposition: useful multi-agent autonomy may require less central orchestration when ownership, conflicting mutations, evidence validity and shared-state transitions are explicit properties of the system. ## 1. The coordination problem Once one agent can carry a task for hours, it is natural to run several. But concurrency changes the problem. Two capable agents working on the same system may read the same state, mutate overlapping files, invalidate a review, change an assumption on which another task depends, or absorb one another's uncommitted work. More agents can therefore increase throughput while weakening the meaning of the evidence those agents produce. The scarce resource is no longer only model intelligence. It is **coherent state**. This resembles a distributed-systems problem. Ownership, stale reads, optimistic concurrency, state transitions and causal provenance exist because independently operating actors need to share a changing world without assuming it remains unchanged between observation and action. Software agents add another complication: they produce both mutations and claims about whether those mutations are correct. ## 2. Where the industry is moving The industry is already moving towards multi-agent execution, but there is no single coordination model. OpenAI describes Codex as supporting multiple agents in parallel with worktree isolation. Its Symphony specification goes further towards orchestration: project-management state becomes a control plane, tasks receive agents and humans review results.[1][2] Google Research evaluated 180 configurations across single-agent, independent, centralised, decentralised and hybrid architectures. Multi-agent coordination improved some parallelisable tasks but degraded sequential tasks; independent agents also showed substantial error amplification. Architecture is therefore part of the reliability problem, not simply a scaling choice.[3] Google's Antigravity work similarly uses an orchestrator to spawn specialised sub-agents for long-horizon software and ML engineering.[4] Anthropic's production research system uses a lead agent with parallel subagents.[5] More recently, Anthropic identified a harder frontier: agents can work together when another agent behaves like a tool with defined inputs and outputs, but struggle when they must treat one another as distinct, long-lived peers without a clear hierarchy.[6] A useful simplification is: **Isolation-first:** agent → isolated workspace → result → merge. **Orchestration-first:** supervisor → decomposition → workers → aggregation. **Peer coordination:** independent agents ↔ shared evolving system. Harten's current work is exploring the third case. The divergence is not using multiple agents. It is making coordination a property of explicit system invariants rather than requiring a supervisory model or human to schedule every transition. ## 3. Observed system The observed configuration had three relevant layers. **Codex** provided separate long-running tasks, tool execution and task-to-task communication. **HART** provided bounded objectives, explicit scope, persistent work state and rules governing when execution should continue or stop. **Git-Hart** provided proposal identity, validation evidence, independent review, exact-base relationships and controlled integration into shared repository state. The case involved two simultaneous workstreams. HART A was repairing MaaS baseline behaviour. HART B was preparing and diagnosing a bounded model-training experiment. Their useful work was largely independent; their repository mutations were not. ## 4. Observed coordination sequence The central observation is represented below as Mermaid so the coordination protocol remains machine-readable with the paper. ```mermaid sequenceDiagram participant A as HART A — MaaS participant G as Git-Hart / Shared State participant B as HART B — Training A->>G: Claim scoped MaaS change B->>G: Claim harten-training scope par Non-conflicting execution A->>A: Implement + validate B->>B: Freeze probes + score models end A->>B: Request integration window B-->>A: Acknowledge Note over B: Pause shared writes only B->>B: Continue read-only analysis A->>G: Submit C against state S0 G-->>A: Independent review Note over G: main advances S0 → S1 G-->>A: Integration rejected as stale A->>G: Rebind + reproduce validation A->>G: Submit C' against S1 G-->>A: Review approved A->>G: Integrate C' G-->>A: New state S2 A->>B: integration-clear(S2) B->>G: Resume shared mutation ``` **Figure 1 — Invariant-based coordination between autonomous peers under shared mutable state.** The agents remain active throughout. Coordination serialises only operations capable of interfering with shared state. Review evidence is bound to the state against which it was produced; when that state changes, the evidence chain must be re-established. The agents declared ownership. The training HART asked that its `harten-training/` work be preserved. The MaaS HART requested a bounded integration window rather than asking the other agent to stop. The training HART paused shared writes and continued read-only diagnostic work. When `main` advanced while the MaaS proposal was in review, Git-Hart treated the integration as stale. Approval was not silently transferred to the new state. The change was rebound, validation reproduced and another independent review obtained. After integration, HART A broadcast integration-clear and HART B resumed shared mutation. The human did not broker that exchange. ## 5. Minimum necessary serialisation The observed behaviour suggests a narrower rule than serialising the actors: **Do not serialise the agents. Serialise the conflicting state transition.** Reading evidence, preparing a proposal, running isolated tests or analysing saved results can continue while another agent owns a brief integration window. Coordination constrains authority at the point of interference rather than suspending agency globally. This is coordination through invariants. The system need not prescribe every implementation step. It must make the conditions under which independent action remains valid explicit. ## 6. Evidence has a state coordinate Suppose a reviewer evaluates change **C**, against system state **S**, using evidence **E**: **R(C, S, E) → verdict** Approval establishes something about that relationship. It does not establish that the same change is approved against every future state. If **S₀ → S₁**, it is unsafe to assume: **R(C, S₀, E₀) = approve ⇒ R(C, S₁, E₀) = approve** The observed Git-Hart behaviour rejected exactly that assumption. Once `main` changed, integration stopped. HART rebound the work, reproduced validation and obtained fresh review. This resembles optimistic concurrency control applied to **epistemic validity** as well as source state. A review is evidence about a specific candidate in a specific world. ## 7. Epistemic isolation The concurrent training diagnostic exposed another boundary. It compared two questions: whether each model preferred the wrong response structure at the first divergence, and whether, when supplied the correct action-field prefix for diagnosis, it preferred the correct action for the supplied state. The diagnostic declared in advance that prefix-assisted scores could locate the failure but **would not count as successful task completion**. Probe inputs were frozen. Scoring used forward passes only: no generation, backward pass or optimiser update. Model fingerprints were checked before scoring and weights checked afterwards. The aim was to change knowledge about the system without changing the system being measured. The result separated response-structure failure from decision-priority failure. For this paper, the important point is methodological: **diagnostic evidence and acceptance evidence remained distinct while another agent concurrently changed the shared software system.** Safe concurrency therefore requires more than file isolation. It requires isolation of authority, state and evidence. ## 8. Provisional coordination invariants The observations suggest eight provisional invariants: 1. **Ownership is explicit.** Peers can discover what an agent intends to change. 2. **Only conflicting operations are serialised.** Non-conflicting work continues. 3. **Working state is preserved.** Integration must not absorb or destroy unrelated work. 4. **Evidence is state-dependent.** Review remains connected to the state that produced it. 5. **Stale evidence cannot authorise integration.** Material state movement requires evidence to be re-established. 6. **Evidence classes remain distinct.** Diagnostic assistance, tests and acceptance answer different questions. 7. **State transitions are explicit.** Integration-clear tells peers when shared state has changed. 8. **Human authority sits above routine mechanics.** Genuine semantic or consequential decisions escalate; routine peer coordination does not require human brokerage. This does not eliminate orchestration. Hierarchical decomposition is useful for many problems. The narrower proposition is that **central orchestration need not be the only mechanism by which autonomous engineering processes remain coherent.** ## 9. The Harten divergence Current systems understandably emphasise model capability, parallel execution and better orchestration. Harten moves another systems concern into the foreground: once agents are independently capable enough to carry meaningful work, some coordination responsibility may be moved out of transient model reasoning and into durable relationships between authority, state and evidence. Distributed systems do not remain coherent because one sufficiently intelligent process remembers every concurrent event. They use protocols, identities, state transitions and consistency rules so local actors can operate without global omniscience. The analogous question for agentic engineering is therefore not only: **How intelligent should the orchestrator be?** It is: **Which coordination responsibilities can be moved out of transient model reasoning and into explicit system invariants?** ## 10. Limitations and research agenda These observations involve two concurrent HART processes, one repository, one execution substrate and a limited number of integration events. HART is under active development. This was not a controlled comparison against alternative architectures, and it does not establish that Codex is uniquely capable of this behaviour. The next tests are clear: increase peer count; deliberately create overlapping claims; kill an agent during an integration window; introduce stale or incorrect peer messages; measure coordination overhead and useful parallelism; compare against central orchestration; and extend coordination across repositories and external systems. The hypothesis should survive those tests before stronger claims are made. ## Conclusion The observed behaviour suggests a different way to frame multi-agent engineering. The goal is not maximum parallelism, nor the removal of orchestration. It is to let independently reasoning processes continue useful work while making the boundaries that protect shared state and evidence explicit. The working principle is simple: **Coordinate the contested state, not every thought or action.** If that principle continues to hold as peer count, contention and consequence increase, the coordination problem begins to look less like finding one model capable of supervising everything and more like engineering a distributed system in which capable agents can safely participate. --- ## References [1] OpenAI, "Introducing the Codex app", 2 February 2026. https://openai.com/index/introducing-the-codex-app/ [2] OpenAI, "An open-source spec for Codex orchestration: Symphony", 27 April 2026. https://openai.com/index/open-source-codex-orchestration-symphony/ [3] Google Research, "Towards a science of scaling agent systems: When and why agent systems work", 28 January 2026. https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/ [4] Google Research, "A New Era of Discovery: Google Research at I/O 2026", 2026. https://research.google/blog/a-new-era-of-innovation-google-research-at-io-2026/ [5] Anthropic, "How we built our multi-agent research system", 13 June 2025. https://www.anthropic.com/engineering/multi-agent-research-system [6] Anthropic, "Patterns and problems in emerging multiagent systems", 13 August 2026. https://www.anthropic.com/research/multiagent-systems This is an empirical working paper from Harten. The observed HART/Git-Hart behaviour is reported as a case study, not as a claim of general multi-agent reliability.