Multi-Agent Consistency: Distributed Systems Challenges Return with Autonomous Agents

First Question: Why Split a Task into Multiple Agents?

The author interviews a candidate who describes a multi-agent system with Planner, Researcher, Executor, and Reviewer roles. When asked how to handle a user-service slowdown, the candidate cannot answer critical follow-ups: which code version, which log segment, whether the Researcher's conclusion is fact or judgment, and whether the Reviewer tests the same version after Executor changes.

The core danger: each agent operates correctly in its own world, but they lack alignment on three things—whether they handle the same task, rely on the same facts, and advance the same state. Reasoning can diverge; protocols cannot be vague.

Task decomposition must respect dependencies. Monitoring and research may run in parallel, but Executor cannot act without knowing the Researcher's basis. Static task splitting does not equal static orchestration; new evidence may require pausing, merging, or re-splitting tasks. Google Research shows centralized multi-agent architectures improve parallel financial analysis by 80.9% but degrade sequential PlanCraft tasks by 39–70%, proving task structure matters more than agent count. Anthropic's system uses breadth-first decomposition for independent search directions.

To avoid duplicate work, tasks need stable identities, conditional claiming, leases, and unique constraints—enforced by the database or state service, not just an if in the scheduler. The coordination overhead (communication, context copying, waiting, retries, aggregation) must be outweighed by parallelism gains.

Figure 1: Control plane, execution plane, and consistency boundaries

Second Question: What Does the First Agent Hand Off?

A Researcher saying "slow in database" is a clue, not a task. The Executor needs: time window, SQL statement, log version, current code/config versions, excluded directions, and acceptance criteria. Agents must pass executable work state, not chat history.

The handoff structure ( HANDOFF) includes:

Task
 ├─ Based on which version: snapshot / commit
 ├─ Confirmed evidence: evidence refs
 ├─ Still assuming: assumptions
 ├─ Allowed actions: capability / constraints
 ├─ Artifact location: artifact refs
 └─ Acceptance criteria: acceptance

Chat history is history; summaries are part of the current workset; code repos, test systems, deployment platforms, and business databases are authoritative fact sources. Summaries accelerate onboarding but cannot replace fact provenance.

Figure 2: Handoff objects, current workset, and authoritative fact sources

Task state must be persisted in an agent_task record answering: who, progress, base version, attempts, lease expiry.

agent_task
 ├─ global_task_id / sub_task_id
 ├─ agent_id
 ├─ input_snapshot
 ├─ status / version
 ├─ attempt / lease_until
 └─ result_ref

global_task_id

links the whole job; sub_task_id identifies specific work; attempt distinguishes retries; version rejects stale updates; lease_until defines claim expiry.

Messages may delay, duplicate, or reorder. An Executor's first run may appear timed out but actually completed remotely; the scheduler launches a second attempt. The second finishes first, then the late first message reverts status to failed. Using attempt, version, or time-conditioned updates lets the system detect stale messages.

If global and sub-task state share a database, update in one transaction. Across services, use event recording, Outbox (write events and local state in same transaction, async delivery), or compensation flows to realign. Outbox ensures the database change and message persistence are atomic.

Third Question: When Two Agents Disagree, Who Decides?

Divergent conclusions (e.g., database vs. connection pool) are valuable if evidence, assumptions, and time ranges are explicit. The problem arises when the system merges them as if they share the same reality: one based on commit-a, another on commit-b; one uses 14:00 logs, another 16:00 metrics; one sees pre-release config, another post-release.

Orchestrators must not just concatenate natural language. Results need structured, versioned contracts so each conclusion traces to input snapshot, source, evidence, and artifacts. Statuses like "candidate", "verified", "conflict", "rejected" let the aggregator decide what enters the final result.

Heterogeneous agents (metrics+evidence vs. natural language vs. conflated success/solved) require adapters to a unified result schema. The protocol ensures the system knows what a result is based on, what it proves, and what is missing.

Agent outputs should first be stored as sourced candidate claims, then validated (entity, relation, time, source) before entering a reusable fact layer. Shared memory records references and state but does not replace code repos, test systems, deployment platforms, or business databases.

Reviewers must veto with cause and trigger re-investigation, route change, scope reduction, or human escalation. If review cannot alter subsequent state, it is a comment, not a system component. Google Antigravity's Teamwork loops candidate generation, stress testing, synthesis, and iteration; rejected paths and dissent influence the next synthesis round.

Fourth Question: Why Trust an Agent's "Done"?

"Code written" only proves file change, not problem solved. "Tests passed" requires knowing which commit, command, exit code, report location, Reviewer blockers, and post-test workspace changes. Completion is a state-machine state defined by acceptance criteria and evidenced by runtime artifacts.

Tool timeouts differ: read-timeout (retry) vs. write-timeout (message, deploy, DB change, refund). Write calls need idempotency keys; on timeout, query remote state, then branch: not executed → safe retry; executed → done; unknown → human/compensation. Unknown state ≠ failure.

Partial failure demands granular retry. If Researcher and Executor succeed but Reviewer fails, re-running the whole task repeats queries (waste) and may re-apply writes (dirty data). Failure state belongs at sub-task level with states: not started, running, completed, failed, unknown. Retry targets failed sub-tasks; unknown state queries remote; replay uses global_task_id, sub_task_id, and business action as idempotency key, enforced by DB unique constraint or downstream idempotency.

Figure 3: Whole-task retry vs. sub-task local retry

Scheduler restart must not re-dispatch all unfinished tasks. Task claiming uses leases and heartbeats: within lease, task belongs to current agent; after expiry, new claimant takes over after checking execution records to avoid dual operation.

Global task state machine plus sub-task eventual consistency compensation is a solid baseline. Not every scenario needs distributed transactions. Production metrics: task duplication rate, state conflict rate, compensation success rate, scheduler availability, unknown-state backlog. Archive historical tasks only after confirming no active leases, retries, or compensations; retention driven by business and audit needs.

Agent claims ≠ system proof. Versions, tool results, side effects, and acceptance evidence must reside in runtime records.

Placing Agents Back into Traditional Architecture

These problems map directly to classic distributed systems:

Task boundaries ↔ service boundaries

Handoff objects ↔ API contracts or domain events

Authoritative facts ↔ master data

State progression ↔ workflow

Timeout recovery ↔ idempotent commands and compensation transactions

Agents amplify the problems: same input ≠ same output; context mutates; tool calls cause real side effects. Models decide what to do next; runtime proves that it happened. The Harness provides correct workset, constrains actions, records actual results, and recovers tasks to a continuable state on failure.

The interview seeks not architecture buzzwords but a complete chain around user-service: why split, what to hand off, based on which version, how to resolve conflicts, where to recover from failure, what proves completion. Technology choices may differ; boundaries must not be empty.

References

Anthropic: How we built our multi-agent research system (https://www.anthropic.com/engineering/multi-agent-research-system)

Google Research: Towards a science of scaling agent systems: When and why agent systems work (https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/)

Google Antigravity: Teamwork: When AI Becomes a Research Partner (https://www.antigravity.google/blog/teamwork-when-ai-becomes-a-research-partner)

Google Research paper: Towards a Science of Scaling Agent Systems (https://arxiv.org/abs/2512.08296)

Nature Machine Intelligence: Capable language models can outgrow the benefits of collaboration (https://www.nature.com/articles/s42256-026-01268-y)

Cedric Chee on X: K2.5 Agent Swarm in Kimi Code CLI (https://x.com/cedric_chee/status/2016722086925053960)

Andrej Karpathy on X: Agentic engineering (https://x.com/karpathy/status/2019137879310836075)

Addy Osmani: Own the Outer Loop (https://addyosmani.com/blog/own-the-outer-loop/)

Simon Willison: More than just code review (https://simonwillison.net/2026/Aug/22/more-than-just-code-review/)

Mario Zechner: What I learned building an opinionated and minimal coding agent (https://mariozechner.at/posts/2025-11-30-pi-coding-agent/)