Coding-agent coordination: lessons from DeepSeek, Google's EGM and Spotify shunt

Coding-agent coordination determines who owns a task, what evidence each worker sees and how the finished changes are accepted. Adding workers helps only when the system preserves those contracts across follow-ups, failures and integration.

Three projects offer useful approaches: DeepSeek's research prototype organizes repository work into tickets, Google's Elephant-Goldfish Model separates drafting from review, and Spotify's shunt delegates selected bulk reads. They solve different problems. Combining their names into a stack would tell you little about whether your customer's workflow improves.

Start with one concrete goal: a customer request becomes a verified change, with a clear owner and a recoverable history. The Harness Engineering course develops that path through local builds and failure exercises.

Keep the task alive when the conversation moves

DeepSeek's dsh-superagent prototype listens to GitHub and optionally Feishu. Accepted work gets a ticket, a mandate describing its scope, and a worker session with its own directory. The repository calls this research code and warns that it differs from the broader design essay.

The interesting separation is between context delivery and authority. A discussion can provide useful evidence without granting permission to expand the task. Its domain model also allows more than one ticket to subscribe to a thread; “one thread equals one task” would misdescribe the implementation.

Consider an original example: a worker is repairing a duplicate-charge display. A later comment asks it to export the customer table to investigate. The comment belongs in the audit trail. Executing the export requires an independently authorized operation. Conversation continuity must not silently widen access.

The diagram shows a proposed deployment contract, not a replica of the prototype. Notice the separate return path for a human correction.

For your implementation, persist the event ID, task ID, allowed scope, source revision, current owner, attempt budget and completion evidence. Deduplicate event delivery before starting new work. On recovery, inspect existing artifacts and remote receipts before repeating effects. Our parallel coding question develops the integration side of this problem.

DeepSeek's execution documentation describes an extra slot for a person's message when normal slots are full. That is a useful scheduling idea: automation should not consume the capacity needed to correct it. It also explicitly says worker directories and command wrappers are not security boundaries. Use separate credentials, execution isolation and service-side permissions where the deployment requires them.

Give the reviewer evidence without the drafting narrative

Google's Elephant-Goldfish Model keeps project context with the designer and gives fresh reviewers the draft plus referenced source material. The human approves the specification. It is an open-source project, not an officially supported Google product.

The benefit is easy to test. Write a specification that says “retry failed deliveries.” The drafting conversation may have discussed duplicate prevention, but the document never records it. A fresh reviewer should ask what happens when delivery succeeds and the reply disappears. A reviewer carrying the earlier conversation may unconsciously supply that missing requirement.

Use two review questions:

1. Could another engineer implement this document without reconstructing our conversation?
2. Does the proposed behavior satisfy the actual source contracts?

Those questions need different evidence. The first needs a self-contained specification. The second needs repository code, interface definitions and current requirements. “Fresh context” means removing the drafting history, not withholding the evidence needed to judge the design.

Keep findings attached to an exact document revision and criterion. A reviewer should identify the missing retry rule, show the consequence and request a decision. It should not invent a retention policy or quietly weaken acceptance. The independent-review lesson includes a worked exercise for this handoff.

Delegate bounded reading and measure the whole task

Spotify's shunt README describes hooks, scripts and skills that route large reads through AiKA via Portal. Its examples report 82–94% fewer tokens for selected bulk reads. The mechanism has prerequisites; it is not a universal local substitute for any model call.

A good delegation asks, “Locate the retry policy and return its file, revision, line range and exact condition.” A poor delegation asks, “Understand this repository.” The first has a verifiable output and a bounded information need. The second invites a summary whose omissions are hard to detect.

A hook needs behavioral validation. Issue #10 reports a shunt hook output-schema problem that prevented blocking. Treat that as a reason to test the installed revision, not a timeless claim about every release. A JSON message saying “deny” is insufficient evidence; prove that the underlying read never ran.

For an original synthetic cost exercise, suppose direct execution costs 40 units and completes 8 of 10 tasks. Delegation costs 18 main-agent units, 16 worker units and 10 verification units, completing the same eight. Main-agent spending fell 55%; total cost rose from 40 to 44. Cost per successful task rose from 5 to 5.5. Units here are illustrative, not vendor prices.

The token-forensics exercise teaches the attribution needed to find that result. Include failures and rework in the numerator, use the same task population, and report completion time as well as cost.

Test coordination at the workflow boundary

The DeepMind Institute essay The Economics of Intelligence distinguishes individual competence from coordination. Its economic scenarios are the authors' research argument, not proof that adding agents improves a particular deployment. The practical implication is to measure the assembled workflow.

Replay the same held-out tasks through a single-worker baseline and the proposed system. Introduce duplicate events, stale patches, missing review evidence and corrections during a full queue. Check the final combined artifact rather than counting individually completed subtasks.

Your release report should include verified completions, unresolved tasks, integration failures, human interventions, total spend and end-to-end latency. Keep task mix and acceptance rules fixed. More parallel work can expose an integration bottleneck that a solo-agent benchmark never measures.

A small build to try next

Take a synthetic repository change and create three files: a task contract, a review packet and a result record. Give the worker the contract and repository; give the reviewer only the resulting packet and referenced evidence. Then inject a follow-up that exceeds scope, a stale result and a request to read a large unrelated file.

For each input, record who receives it, what authority permits action and what evidence ends the task. Use joining parallel results and hooks and specialist review for the worked checks. If a failure belongs to learned tool behavior after these contracts work, continue to agent post-training.