A Specification Is a Contract

This post compares two ways to put a group of agents to work.

Organize by role. Give each agent a job title, a shared store of business knowledge, and a way to ask the others for help. Marblism works this way. It sells seven AI employees to businesses, keeps a central knowledge store it calls the Brain, where each item can go to some or all employees, and its employees “reach out to other AI Employees” when a task needs another skill. Sensitive actions, such as sending email or posting publicly, wait for the owner’s approval.

Organize by contract. Write the spec first. Split the work along its dependencies. Give each worker a contract: what it receives, the shape of what it returns, the files it owns, the check it must pass. Verify before you integrate.

We build the second way. Our work is built off specifications and shared contracts, and backend and front end use them differently. Our method states two of its rules as contract before fan-out and done means verified. Here is what the public record says about working this way, including where it falls short.

Where control lives

Claude Code’s docs list five ways to work on several tasks at once. In four of them, Claude or a script coordinates the agents. This post looks at one difference: who decides what runs next. The fifth, agent view, is one screen for dispatching and watching background sessions (research preview).

• Subagents. Claude decides, turn by turn. A side task runs inside one session, in its own context window, and returns a summary.
• Agent teams. The lead agent decides, turn by turn. Teammates message each other and share a task list. Experimental.
• Workflows. The script decides. Intermediate results live in script variables, and one run can hold dozens to hundreds of agents.
• Projects. A coordinator starts a thread for each task. Each cloud thread is its own session and sandbox, and cloud threads share the project’s repositories, files, instructions and memory. Public beta.

Sources: Subagents, Agent teams, Workflows, Projects, read 2026-10-25.

Workflows are where part of the contract becomes machine-checked: the shape of what comes back. An agent() call can carry a JSON schema. The runtime validates the output, and if it still fails after five attempts, the call fails. Type ultracode in a prompt and Claude writes a workflow for that task.

The contract

Our public Orchestration Guide, drawn from 208 sessions and 469 agent dispatches in April 2026, says: “Interface contracts before implementation is the rule.” Each parallel dispatch starts by assigning “non-overlapping manifests per agent.” Nothing is finished on an agent’s word: “Agent ‘done’ is not done until independently verified.”

Anthropic’s research write-up says much the same about what each worker needs: “an objective, an output format, guidance on the tools and sources to use, and clear task boundaries.” Anthropic’s guide to multi-agent systems describes an experiment where planner, implementer, tester and reviewer agents “spent more tokens on coordination than on actual work.” That experiment split coding work by role, and the guide describes it in one sentence, so it says nothing direct about products like Marblism. The guide’s advice is to divide by context, and it names a clean interface as a good boundary: “With a well-defined API contract, frontend and backend work can proceed in parallel.” One pattern it says “consistently works well across domains” is a separate verification agent.

Backend runs on contracts. Front end runs on specs and memory.

In our backend work, shared specs and contracts organize the workers and decide how the work is distributed.

On front-end work, our specs and the shared workspace’s memory point workers to resources that inform the result, guided by the client’s intent.

Research is generated along with the work, and it also informs the result.

Claude Code projects have a shared layer of their own: memory every cloud thread reads when it starts, files every cloud thread can read, repositories every cloud thread clones. Anthropic’s research write-up recommends a similar move inside a single system: subagents that “store their work in external systems, then pass lightweight references back to the coordinator.”

What the record says against this

• Spend may explain the gains. In Anthropic’s research system, token usage alone explained most of the variance in performance on one benchmark, BrowseComp. With reasoning budgets held equal, single-agent systems “consistently match or outperform” multi-agent ones on multi-hop reasoning.
• Coding is the hard case. A Google Research, Google DeepMind and MIT study (revised April 2026) reports that SWE-bench Verified “shows slight degradation across all MAS architectures,” meaning every multi-agent setup it tested.
• Simpler often wins. In Anthropic’s comparisons across several enterprise deployments, a single agent with skills “frequently outperformed” both a one-prompt design and subagent designs on quality, “often at a lower cost and latency per task.”
• Parallel writes are the weak point. Cognition, which makes Devin, says multi-agent systems “work best today when writes stay single-threaded.”
• Contracts can serialize the work. In a 2026 single-author preprint, a pre-write admission gate sharply raised integration success but serialized nearly every execution, and the study did not establish a wall-clock speedup.
• A schema checks shape. It does not check whether the answer is right.

My answer, from my own work: well governed and researched dispatches take less time and produce meaningfully better results, at a higher consistency. I see this in coding and beyond, and it has to do with protocol: the system as a whole, a series of checks and hooks. Protocol solves problems like parallel writes, and it routes simpler tasks away from complex protocols.

Cost

Claude Code’s docs say a workflow “can use meaningfully more tokens than working through the same task in conversation,” runs up to 16 agents at once by default, and shows a “Large workflow” warning above 25 agents or 1.5 million projected tokens. In Anthropic’s testing, multi-agent implementations “typically use 3-10x more tokens than single-agent approaches for equivalent tasks.”

A specification is a contract

Write it first. Hand it to every worker. Check the result against it. The curriculum is in the Orchestration Guide.