Shared Scratchpad

Signs and symptoms

A code migration uses three agents: one refactors, one writes tests, and one reviews. All three write to and read from the same conversation history (anonymized):

[refactorer] I will extract the discount logic into a pure function,
             using a rules dictionary instead of nested ifs...
[refactorer] Done. apply_discount now takes rules: dict.
[tester]     I will write the tests. Following the same approach,
             I will extract the fixtures into a rules dictionary...
[reviewer]   The tester changed the fixture structure for no reason.
[refactorer] I agree with the reviewer, I will adjust the tests too...

The tester started copying the refactorer’s style decisions. The refactorer started touching the tests because it read the reviewer’s criticism of them. Nobody knows anymore which agent owns which file.

The same shows up when the team creates a memory.md or a channel where every agent appends paragraphs. Each one rereads the others’ reasoning and treats that text as instruction. “Collaboration” becomes contamination.

Signs of a Shared Scratchpad:

• Several agents read from and write to the same history or notes file, in free text.
• One agent’s reasoning shapes another’s style or decisions.
• Agents start doing each other’s work.
• The shared context grows fast, with messages from everyone.
• There is no format and no owner for what each one writes.

flowchart TD
  A(["1. Agent A"]):::llm --> S[("2. Shared free-text history")]:::store
  B(["1. Agent B"]):::llm --> S
  C(["1. Agent C"]):::llm --> S
  S --> A
  S --> B
  S --> C

1. Each agent has a different role.
2. All of them write and read the same text, with no format and no owner.
3. One agent’s reasoning becomes implicit instructions for the others, and the roles blur.

Check +20 XP on first tryIn the migration trace, the tester decides to 'extract the fixtures into a rules dictionary' right after reading the refactorer's reasoning. What is the mechanism?

The tester's prompt is weak; independent-test few-shots would fix it

Free-text reasoning in the shared history became implicit instruction for the tester

You need a fourth agent, the Architect, to pick the style before the others speak

Reasons

• It is the default in several frameworks. Agents in a “group chat” share history by default. You spin up three roles, the framework hands you a single chat, and it looks like the team was born ready.
• It looks like collaboration. Seeing others’ work feels useful, as in a human team. On a human team, a person chooses what to read. The model reads everything in the context and weights all of it.
• There is no contract between agents. With no defined format, free text is the only medium. The refactorer “tells” what it did in prose; the tester “understands”. That is the neighboring smell Free-Text Handoff in the middle of a group.
• One file looks simple. A scratchpad.md that everyone appends to avoids designing an API. It works for an afternoon. In a week the file holds everyone’s reasoning and nobody can summarize who decided what.

Cost of ignoring

• Contaminated roles. Agents imitate or correct each other outside their scope. The reviewer stops finding bugs because it bought the author’s justification.
• Bloated context. Every agent reads everything from everyone, and cost grows with the product (agents × messages), not with each one’s work.
• Review without independence. The reviewer read the maker’s reasoning and tends to agree. In human code review you sometimes hide intent on purpose so the reviewer judges the diff. Here the diff arrives with an essay defending every line.
• Diffuse responsibility. When something goes wrong, nobody can tell whose decision it was. The three traces tell the same mixed story.

A bill for the single history

The numbers below are illustrative. Suppose three agents, each writes about 800 tokens per turn, and the task has four turns.

Design	What each agent reads per turn	Total read tokens (approx.)
Shared history	Everything the three have already written	grows by 800 × 3 each turn, paid three times
Isolated contexts, structured handoff	Only the instruction and a record (files, diff_stat)	almost constant per agent

On the shared scratchpad, the third turn already sends tens of thousands of tokens to each one. Isolated, the tester receives apply_discount(rules: dict) and the file list, a few tokens, and works in its own context.

Treatment

Refactoring	Choose it when
Extract Subagent	Each role needs its own context. Agents start receiving only the instruction and material they need. Targets: Subagent Delegation and Context Isolation.
Replace Free Text with Structured Output	The agents really do need to share information. Replace free text with records that have an owner and a format. Target: Structured Output.

In the migration, the refactorer returns something like schema Change { files: list[string], summary: string, public_api: string }. The tester receives only that, in a context empty of someone else’s reasoning, and writes tests. The reviewer receives the diff and the rubric, without the refactorer’s essay. The orchestrator is who reads the three records and decides the next step.

Do not confuse this with Decorative Multi-Agent. There the agents should not exist as separate roles. Here the split may be right, and what is wrong is the medium: a block of prose that everyone edits.

Check +20 XP on first tryYou need the refactorer to tell the tester what changed. Which design avoids a Shared Scratchpad without hiding the useful fact?

Leave both in the same chat, but ask in the prompt 'do not copy each other's style'

Write a memory.md that only the orchestrator summarizes now and then

The refactorer returns a record with files, summary, and public API; the tester receives only that record in its own context

Payoff

• Each agent does its own job, with its own context.
• Shared information in a defined format, with an owner.
• Truly independent review.
• Cost that does not grow with the square of the number of agents.

When to ignore

• Debate with a judge and criteria. When the point is for agents to read each other’s arguments, sharing is the point. Even then, the judge decides by written criteria, and the generator’s reasoning does not enter the judgment if you want independence.
• Two agents with a small interface. A short exchange of messages between two agents can work without structure. If the third message already mixes roles, add structure.
• A human in the middle. If a person reads the scratchpad and pastes into the next agent only the stretch that matters, the human is the filter. That does not scale, and it works in a prototype.

Is it this smell?

Check +20 XP on first tryThree subagents research in parallel and write claims to a board with named fields: claim, source, author. The orchestrator reads the board. The subagents do not read each other's board. Is this a Shared Scratchpad?

Yes, there is a shared board

No

Yes, because the orchestrator mixes the claims into one text

Check +20 XP on first tryA reviewer receives the code produced and also the full reasoning history of whoever wrote it. It approves almost everything. What is the problem?

Lack of independence: the reviewer is being persuaded by the maker's essay

The reviewer is a weak model and needs to be swapped

You need a second reviewer to review the first

Check +20 XP on first tryFive agents with job titles pass the same text along, each rewriting it a little, with no tools. Which is the main smell?

Shared Scratchpad

Decorative Multi-Agent

Free-Text Handoff, and a structured board will fix the five

Check +20 XP on first tryTwo agents: A returns Change with files and a summary, B receives only that object and writes tests in its own context. There is no shared chat. Is this a Shared Scratchpad?

Yes, they share information

Yes, because B depends on what A produced

No