# Establishing completion in autonomous multi-agent systems > An empirical case study of evidence-bearing distributed termination: how autonomous engineering agents can establish that shared work is complete rather than merely report that their local task has finished. Paper: Technical paper — 04 Published: 2026-09-16 Canonical: https://harten.io/papers/establishing-completion-in-autonomous-multi-agent-systems/ Cover illustration: [View the title image](https://harten.io/media/papers/covers/v1/establishing-completion-in-autonomous-multi-agent-systems.jpg?v=f3f6d5592a6d). Illustrative cover artwork, not an application screenshot or a record of measured results. By Lavan Nallainathan · Harten Technologies ## Abstract As autonomous agents begin to work concurrently against shared systems, completion becomes a distributed-systems problem. An individual agent can know that its own work has stopped. That does not establish that the shared body of work is complete: another agent may still hold mutation authority, a proposal may remain unpublished, an integration may not have been observed, a runtime process may still be active, or the durable state may differ from the state an agent believes it produced. This paper reports a second empirical case study from Harten's multi-agent engineering environment. Two HART processes had been operating concurrently against a shared repository. At end of day, one process owned a bounded MaaS closeout as a secondary while another retained the primary role and responsibility for global closeout. The secondary reconciled its integrations and archives, published a factual handoff, released its session authority and ceased shared mutation. The primary independently verified the role ledger, reconciled the wider day state, disposed of temporary compute while preserving active services, and withheld a clean-shutdown claim until final durable-state read-back. The observation suggests a distinction that is easy to lose in agentic systems: **Local completion is a claim. Global completion is a state that must be established.** We describe the observed pattern as **evidence-bearing distributed termination**. It is not presented as a new distributed termination algorithm, nor as equivalent to consensus. Classical distributed termination detection is a mature field concerned with determining whether a distributed computation has ceased activity. The Harten observation applies related reasoning to autonomous software-engineering agents whose work also carries authority, evidence, review state and persistent external effects. ## 1. The problem with "done" Agent systems frequently expose completion as a message: a task returns, a worker reports success, a subagent hands an artefact to a supervisor, or a workflow reaches a terminal node. That is useful locally. It is insufficient globally. Suppose two autonomous engineering agents have worked against the same repository. One reports that its task is complete. Several things may still be true: - it may hold an active claim over shared state; - its reviewed proposal may not have been integrated; - another agent may not yet have observed its final state; - uncommitted or inherited work may remain; - a runtime resource created during execution may still be active; - a production workload may deliberately need to continue; - the remote repository may not contain the commit the agent believes it published. A local statement of completion therefore answers the wrong question. The useful question is not **"Has every agent said it is finished?"** It is **"Can the system establish a coherent terminal state from durable evidence?"** ## 2. This is an old distributed-systems problem in a new setting Distributed termination detection has been studied for decades. Classical work defines termination in terms such as all processes being passive and no messages remaining in transit. The difficulty is that no individual process has simple access to the complete global state. Research has consequently explored symmetric and asymmetric algorithms, message counting, credit recovery, waves, snapshots, failure detectors and other ways of establishing a global termination predicate.[1][2][3] The problem also appears directly in multi-agent research. Work on distributed termination detection for multi-agent protocols has treated termination as an explicit runtime property rather than an inference from individual agent behaviour.[4] More recent actor-system work similarly distinguishes local inactivity from global quiescence and develops decentralised mechanisms for establishing when actors can no longer become active.[5] Tool-using LLM agents introduce another related problem: when may an individual agent safely return COMPLETE? Recent work on evidence-carrying termination tests whether a terminal claim is supported by typed trace evidence and deterministic replay rather than merely accepted from an agent's own judgement.[6] Harten's observation sits between these traditions. The problem is not only whether processes are active. Autonomous engineering agents also create and consume **authority, review evidence, repository state, runtime resources and claims about correctness**. A useful termination protocol therefore has to reconcile more than process liveness. ## 3. Industry systems are scaling execution faster than shared completion semantics Current agent platforms are moving rapidly towards parallel execution. Codex supports multiple agents working concurrently and uses worktrees to isolate changes on the same repository. OpenAI describes the current challenge as directing, supervising and collaborating with agents at scale.[7] Its Agents API uses a main agent to coordinate parallel subagents and aggregate their results.[8] Anthropic describes a similar broad landscape: orchestrator-subagent architectures are useful, but long-lived peers without a clear hierarchy remain a harder coordination problem. Its recent multi-agent research explicitly notes that local agent behaviours can compound into unexpected global outcomes.[9] These systems are increasingly capable of making several agents productive at once. That makes termination semantics more important, not less. More concurrency creates more ways for local completion to diverge from global completion. The Harten divergence is not that agents run in parallel. It is that completion is treated as a **governed state transition backed by evidence**, rather than a conversational status emitted by whichever agent happens to finish last. ## 4. Observed end-of-day sequence The following sequence abstracts the observed primary/secondary closeout. It intentionally separates local reconciliation, authority release and global completion. ```mermaid sequenceDiagram participant S as Secondary HART participant L as Role / Session Ledger participant G as Git-Hart / Durable State participant P as Primary HART S->>S: Reconcile local work S->>G: Verify integrations + archive OIDs S->>P: Publish factual handoff P->>L: Verify primary / secondary roles L-->>P: Primary confirmed P->>P: Continue read-only global reconciliation S->>L: end-session L-->>S: state = released L-->>P: active_secondaries = [] L-->>P: primary_close_allowed = true Note over S: No further shared mutation P->>G: Reconcile complete day state P->>P: Resolve inherited / outstanding work P->>P: Verify runtime disposition P->>G: Publish final EOD state P->>G: Remote read-back exact final OID G-->>P: Durable state confirmed Note over P,G: Global completion established ``` **Figure 1 — Evidence-bearing distributed termination.** A secondary agent can finish and release its own authority without declaring the shared system complete. The primary becomes eligible to close only after the role ledger establishes that no secondary remains active, then independently reconciles global state and verifies the final durable identity. The sequence contains several important properties. First, role state was not inferred from conversation. The primary checked the ledger and established that the requested transfer was unnecessary because the correct primary and secondary roles were already held. Second, the secondary did not merely report "done". It reconciled the work it could legitimately own, verified integration and archive identities, distinguished inherited working files from its own changes, supplied runtime facts and receipts, then explicitly released its session. Third, the release changed the authority state. Only after the ledger reported no active secondaries and allowed primary closeout could the global close proceed. Fourth, the primary did not treat the secondary's release as proof of global completion. It continued its own reconciliation, including inherited work, billing state, temporary training compute, retained experimental artefacts and live MaaS services that were intentionally not to be shut down. Finally, clean termination remained conditional on exact final remote state read-back. ## 5. Three states that should not be collapsed The observation suggests three distinct predicates: **Agent complete** — an individual actor has finished the work inside its local authority boundary. **Task reconciled** — the actor's mutations, evidence, outstanding resources and handoff state have been accounted for and its authority can be released. **System complete** — all required actors and resources have reached an admissible terminal disposition, the shared evidence chain is coherent, and the durable system state has been independently observed. These are not synonyms. We can express the distinction informally as: **agent says done ≠ task reconciled ≠ system globally complete** The value of making these states explicit is that an agent can finish locally without being granted the semantic authority to close the system globally. ## 6. Authority release is part of termination Traditional termination detection asks whether distributed computation can still produce further activity. Autonomous engineering adds a related question: **who is still authorised to mutate shared state?** A secondary that has completed its implementation but still owns a live session is not fully quiescent from the perspective of the shared engineering system. It can still produce a consequential mutation. The observed closeout therefore required an explicit release transition. The session ledger moved the secondary into a released state, removed it from the active-secondary set and changed the primary's close permission. That makes authority observable rather than conversational. This matters because "I will not make any more changes" and "the system no longer recognises me as an active writer" are different guarantees. ## 7. Evidence must survive the agent that produced it The secondary's handoff included exact source integrations, archive verification, runtime identities, test results and receipt locations. The primary could therefore reconcile the day without depending on the secondary remaining alive or remembering its own narrative. This is consistent with a broader Harten design principle: evidence should survive the execution that produced it. For termination, that means the system needs enough durable information to answer at least four questions: 1. What did this actor own? 2. What durable state did it produce? 3. What remains active or unresolved? 4. Has its authority to produce further shared mutations ended? A completion message without those properties is useful status. It is not a termination certificate. ## 8. Runtime disposition is part of global completion Software agents increasingly act outside Git. They create cloud resources, start model-training jobs, trigger deployments, modify databases and launch long-running services. Repository cleanliness therefore cannot be the only completion predicate. In the observed closeout, the primary checked that the temporary training process had ended and that retained checkpoints and diagnostics existed before deallocating its VM. At the same time, it explicitly preserved the independent MaaS/WEEE services because they were supposed to continue running. Global completion did not mean **everything is stopped**. It meant **every relevant resource has reached its intended terminal disposition**. For one resource that disposition was deallocated. For another it was retained and running. For repository state it was published and remotely verified. This distinction becomes essential once agents operate real infrastructure. ## 9. Relationship to distributed termination detection The analogy to classical distributed termination is useful but should not be overstated. Classical algorithms often reason about passive processes and messages in transit, and many come with formal safety and liveness properties. HART's current protocol has not been formally proven. It is an empirical operating protocol observed in a software-engineering environment. The additional dimensions are also different. HART tracks authority roles, repository identities, review evidence, inherited working state and external runtime disposition. These are application-level semantics layered above process termination. The research opportunity is therefore not to rename an established distributed-systems problem. It is to ask what a termination predicate should contain when the distributed actors are autonomous engineering agents capable of making consequential changes and producing claims about those changes. A provisional predicate might require: **GlobalComplete = NoActiveSecondaryWriters ∧ AllOwnedWorkReconciled ∧ RequiredEvidencePublished ∧ RuntimeDispositionValid ∧ DurableStateReadBackVerified** That is deliberately a hypothesis, not a proof. ## 10. Failure modes The protocol becomes more interesting when it fails. What happens if a secondary crashes before releasing its session? What if the ledger says released but an external process continues running? What if two agents both believe they are primary? What if the final repository OID is correct but an external deployment is not? What if a handoff omits inherited dirty state? What if communication is delayed and an agent resumes mutation after the primary has begun closing? Classical termination research shows why these questions matter. Crash-recovery environments make safe termination detection substantially harder and can require explicit failure assumptions or failure detectors.[10] The Harten protocol therefore needs to be evaluated under deliberately induced faults rather than only successful closeouts. ## 11. Research agenda The next experiments should move from observation to controlled evaluation. We intend to test at least the following conditions: three or more concurrent peers; simultaneous attempts to acquire close authority; secondary crash before release; stale or duplicated release messages; external runtime activity after repository completion; unresolved review evidence; conflicting ownership claims; interrupted network communication; and incorrect final-state assertions. The relevant measures are not simply whether the agents eventually stop. They include unsafe completion rate, time to legitimate termination, unnecessary serialisation, recovery success, orphaned resources, unresolved evidence and human intervention required. A stronger protocol should eventually permit formalisation of its safety property: > If HART declares global completion, no actor retains authorised unresolved work capable of invalidating the declared terminal state, and every required durable-state predicate has been independently established. Whether that property can be achieved without excessive coordination cost is an empirical question. ## 12. Conclusion Multi-agent autonomy creates a deceptively simple problem at the end of work. Who gets to say that the work is finished? The answer cannot safely be "the last agent to speak". In the observed HART closeout, completion emerged through a sequence of local reconciliation, evidence publication, authority release, independent global reconciliation, runtime disposition and durable-state read-back. The secondary could finish without claiming global completion. The primary could acquire close authority without assuming the system was already clean. The final claim remained contingent on evidence outside either agent's narrative. That leads to the working principle this paper will test further: **Local completion is a claim. Global completion is a state that must be established.** For autonomous engineering systems, the ability to start more agents is becoming straightforward. Establishing when their collective work is genuinely complete may prove to be the harder systems problem. ## References [1] Francez, N. and Dijkstra, E. W./Scholten, C. S. foundational work on distributed termination detection, surveyed in: [A taxonomy of distributed termination detection algorithms](https://www.sciencedirect.com/science/article/abs/pii/S0164121298100341). [2] Rana, S. P. (1983). [A distributed solution of the distributed termination problem](https://www.sciencedirect.com/science/article/pii/0020019083900893). [3] Mattern, F. (1990). [Asynchronous distributed termination — parallel and symmetric solutions with echo algorithms](https://doi.org/10.1007/bf01840392). [4] Motshegwa, T. (2009). [Distributed Termination Detection For Multiagent Protocols](https://openaccess.city.ac.uk/id/eprint/19754/). [5] Plyukhin, D. and Agha, G. (2020). [Scalable Termination Detection for Distributed Actor Systems](https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.CONCUR.2020.11). [6] Liu, J. (2026). [When May an Agent Stop? Evidence-Carrying Termination for Tool-Using LLMs](https://arxiv.org/abs/2608.23623). [7] OpenAI (2026). [Introducing the Codex app](https://openai.com/index/introducing-the-codex-app/). [8] OpenAI (2026). [Introducing the Agents API](https://openai.com/index/introducing-the-agents-api/). [9] Anthropic (2026). [Patterns and problems in emerging multiagent systems](https://www.anthropic.com/research/multiagent-systems). [10] Mittal, N., Phaneesh, K. L. and Freiling, F. C. (2009). [Safe termination detection in an asynchronous distributed system when processes may crash and recover](https://www.sciencedirect.com/science/article/pii/S0304397508007603). --- This is a Harten technical working paper based on an observed engineering closeout on 15–16 September 2026. It reports behaviour from the current HART/Git-Hart system and proposes a research direction. It does not claim a formally verified distributed termination algorithm.