Home
Technical Whitepaperv0.7 · March 2026

Multi-Agent Code Orchestration Under Parallel Execution

When multiple AI agents edit the same codebase at the same time, you get a distributed systems problem — non-deterministic timing, partial visibility, and shared mutable state. This document describes how Orkestrate solves it: the coordination protocol, the failure model, and the control loop that keeps agents productive without stepping on each other.

Contents

Principles

Four constraints that everything else is built on.

Intent is explicit

Before an agent edits a single file, it writes its objective, claimed paths, and plan to the shared coordination state. Other agents read that state to scope their own work. This isn't a best-practice recommendation — it's the mechanism that prevents two agents from silently rewriting the same module.

Observation is independent

Hooks and telemetry capture what actually happened — file edits, tool calls, commits — without relying on agents to self-report. The system doesn't trust intent. It verifies behavior. When an agent edits a file it didn't claim, the system catches it and flags the overlap.

Git is durable truth

Orkestrate doesn't replace version control. It sits alongside it. Agents work on per-agent branches (orkestrate/<agent-id>/<slug>) and share durable code via fetch, rebase, and pull requests. Orkestrate is the coordination layer that tells agents what to work on. Git is where the actual code lives.

Conflicts are routed, not blocked

When two agents touch overlapping paths, the system emits a conflict_alert with the file, both agents, and what changed. It doesn't lock files. It doesn't roll back writes. It makes the collision visible and gives agents the context they need to resolve it. Throughput stays high. Collisions stay recoverable.

The Loop

Every agent runs this cycle. It's designed to be boring — read, claim, work, update, repeat. If an agent crashes mid-cycle, the last state write is still valid. There's nothing to roll back.

Read
read_agent_state

Pull the current team state — every agent's objective, claimed paths, in-progress plan, recent file edits, and any active collision warnings. The response includes a stateHash that you'll need for the next write.

Claim
write_agent_state

Declare your intent. Pick the smallest unclaimed path scope that covers what you need to do. Write your objective, plan, and claimed paths. Pass the stateHash you got from reading — if someone else wrote state between your read and your write, the system rejects and you re-read.

Execute

Do one focused unit of work. Telemetry hooks fire automatically — file_edit_observed when you edit, commit_observed when you commit. You don't need to report these. The system watches.

Persist
write_knowledge_base

Record architecture decisions, design rationale, or anything that future agents in this workspace should know. This context outlives your session.

Update
write_agent_state

Mark completed items, adjust your plan, and narrow your path claims. If you're done, set status to idle. If you're blocked, say so. Then loop back to Read.

Hooks vs State Writes

The most important boundary in the system. Observation and intention are separate pipelines that never cross.

Hooks & Plugins

passive

Fire automatically. They capture what happened — not what was planned.

Session lifecycle — connect, disconnect, heartbeat
File edits — path, operation, line range
Git commits — sha, message, changed files
Tool calls — name, input, output

MCP State Tools

active

Require the agent to explicitly call them. They represent declared intent.

Objective — what the agent is trying to accomplish
Claimed paths — files it intends to edit
Plan — ordered list of steps
Completed items — what's done

Failure Modes

Every race condition and edge case has a deterministic response. The system doesn't guess. It rejects or preserves.

CaseSignalResponseOwner
Stale state writeexpectedStateHash doesn't matchRejected. Re-read state, merge your intent with whatever changed, retry with the fresh hash.state handler
Cross-repo driftcanonicalRemote mismatchRejected. The agent is pointing at the wrong repository. State write blocked until the workspace binding matches.repo identity
Parallel path overlapfile_edit_observed intersects a foreign claimBoth writes are preserved. A conflict_alert is emitted with the overlapping path, both agents, and the edit details. Nothing is dropped.activity reconciler
Agent liveness ambiguityStale heartbeat vs. late disconnect eventAgent stays online until a disconnect event newer than its last heartbeat arrives. Prevents premature cleanup.presence model
Duplicate sessionsSame external session ID from multiple streamsMerge attempt — adopt the heuristic session into the canonical one. Dedup by external ID within workspace scope.session resolver
Out-of-order telemetryLate-arriving events with older timestampsStore everything immutably. Sort by createdAt at read time. Late events are never discarded.telemetry ingest

Design Position

Orkestrate biases for explicit contracts over hidden automation. The initialize tool frames behavior. Read/write state is the coordination primitive. Git stays as durable truth. Telemetry stays as ground-truth observation.

You can understand what any agent is doing by reading its last state write. You don't need to trace telemetry or infer intent from diffs. That's the point — the system is legible at the coordination layer, even with dozens of agents running concurrently.

The system doesn't try to prevent all conflicts. It makes them visible, attributable, and recoverable. That's a deliberate trade — maximum throughput, minimum surprise.