The Shared Scratchpad: A Common Workspace for Collaborating Agents

Supervisor patterns keep each specialist's scratchpad isolated. Swarm patterns move the conversation from one agent to another. Both are appropriate when work is handed off cleanly from one agent to the next. Neither serves cases where multiple agents need to see each other's work in flight, contribute to a single evolving artifact, and build on each other's reasoning as it unfolds.

The shared scratchpad pattern addresses those cases. Instead of isolated per-agent state, all agents read from and write to a single workspace: a shared message log, a shared set of artifacts, and sometimes a shared to-do list. Every agent sees what every other agent is doing. Collaboration becomes direct rather than mediated by a coordinator. Anthropic's multi-agent design guide lists this as the fourth multi-agent pattern and notes that it offers maximum context sharing but comes with a cost: workers may get distracted by irrelevant information from other agents, and the pattern works best with small teams of two to four (Anthropic, 2024). This article covers the workspace, when the tradeoff pays off, and the failure modes that follow from full visibility.

What lives in the workspace

The shared state is usually a typed object with three kinds of fields. Messages accumulate as agents communicate. Artifacts hold durable outputs: a draft document, a piece of code, a diagram, a plan. A progress marker or task list tracks what has been done and what remains.

flowchart TD
subgraph Workspace["Shared state"]
direction TB
M[Messages: turn history]
A[Artifacts: code, docs, drafts]
P[Progress: tasks completed, pending]
end
AG1[Agent A] <--> M
AG2[Agent B] <--> M
AG3[Agent C] <--> M
AG1 <--> A
AG2 <--> A
AG3 <--> A
AG1 <--> P
AG2 <--> P
AG3 <--> P

Every agent is bidirectionally wired to every field. A writer agent updates the draft; a reviewer agent reads the draft and updates the progress tracker with issues found; a fact-checker agent reads the draft and updates the progress tracker with claims to verify. All three see the current state at every turn; none of them needs to ask another agent for context.

Two versions in code

The excerpt below sketches the pattern without a framework. A simple shared dict plays the role of the workspace; each agent is a function that reads and returns an updated state.

from openai import OpenAI
from pydantic import BaseModel

client = OpenAI()

class Workspace(BaseModel):
messages: list[dict] = []
draft: str = ""
issues: list[str] = []
done: bool = False

def writer(ws: Workspace) -> Workspace:
prompt = f"Current draft:\n{ws.draft}\n\nIssues flagged:\n{ws.issues}"
r = client.responses.create(
model="gpt-4o-mini",
instructions="Improve the draft based on issues. Return updated draft only.",
input=prompt)
return ws.model_copy(update={"draft": r.output_text, "issues": []})

def reviewer(ws: Workspace) -> Workspace:
r = client.responses.create(
model="gpt-4o-mini",
instructions="Review the draft. Return a bulleted list of issues, or 'OK'.",
input=ws.draft)
issues = [l.lstrip("- ") for l in r.output_text.splitlines() if l.strip()]
return ws.model_copy(update={"issues": issues,
"done": issues == ["OK"] or not issues})

def run(task: str, max_rounds: int = 5) -> str:
ws = Workspace(draft=f"(initial idea: {task})")
for _ in range(max_rounds):
ws = reviewer(ws)
if ws.done:
return ws.draft
ws = writer(ws)
return ws.draft

The LangGraph version formalizes the workspace as the graph's state type and uses Annotated reducers so concurrent updates merge correctly.

from typing import TypedDict, Annotated
from operator import add
from langgraph.graph import StateGraph, START, END
from langchain.chat_models import init_chat_model

model = init_chat_model("gpt-4o-mini")

class State(TypedDict):
draft: str
issues: Annotated[list[str], add]
done: bool

def writer_node(s: State) -> State:
if not s["issues"]:
return s
new_draft = model.invoke(
f"Improve draft:\n{s['draft']}\n\nIssues:\n{s['issues']}").content
return {**s, "draft": new_draft, "issues": []}

def reviewer_node(s: State) -> State:
out = model.invoke(f"Review draft. Bullet issues or OK:\n{s['draft']}").content
issues = [l.lstrip("- ") for l in out.splitlines() if l.strip()]
return {**s, "issues": issues, "done": not issues or issues == ["OK"]}

def cont(s: State) -> str:
return "done" if s["done"] else "revise"

graph = (StateGraph(State)
.add_node("review", reviewer_node).add_node("write", writer_node)
.add_edge(START, "review")
.add_conditional_edges("review", cont,
{"revise": "write", "done": END})
.add_edge("write", "review")
.compile())

Full runnable versions will live at github.com/subodhjena/agentic-patterns under examples/19_shared_scratchpad.py as that lesson lands in the repo.

What the workspace buys

Shared scratchpad is not a default pattern; it is a specific choice with a specific payoff.

Artifacts that evolve. A document drafted by a writer, reviewed by a critic, revised by the writer, and fact-checked by a third agent is a single evolving thing. Passing the document between isolated scratchpads would mean serializing and deserializing it each time. A shared workspace lets the artifact live in one place.

Parallel readers and a serial writer. Multiple agents can read the current state concurrently; one agent writes at a time. Analysis, annotation, and fact-checking tasks fit this shape.

Tight collaboration with full context. When the cost of an agent missing what another agent just did is high (contradictory edits, missed issues), shared state eliminates that class of bug.

Small teams. Two to four agents is the range where the pattern consistently earns its keep. Beyond four, the workspace grows faster than any single agent can read at each turn.

Where the workspace goes wrong

Sharing state is a source of problems as well as a solution.

Distraction from irrelevant updates. A reviewer agent reading the writer's full edit history is processing tokens that will not improve the review. Structure the workspace so agents see only what they need: provide views, not the raw state.

Concurrent write conflicts. Two agents writing to the same field in the same turn produce a race condition. Use reducers (additive lists, last-writer-wins, structured merges) rather than raw field replacement.

Scratchpad bloat. Messages accumulate; each turn's message list grows. Without compaction or windowing, the shared state exceeds every agent's context window. Apply the same compaction strategies as a single agent would, but centrally.

No clear termination. With every agent able to contribute, no single agent owns the "done" signal. Make termination a field on the workspace that any agent can set and the runtime checks.

Role creep. Without isolation, an agent primed for writing may start reviewing, and vice versa. Keep each agent's prompt tightly scoped, and treat their role as their mandate regardless of what is in the workspace.

Leakage of internal reasoning. Agents sometimes record their internal deliberation on the workspace. Other agents then read and react to it, producing cascades of meta-commentary. Use a separate "internal" area per agent that other agents cannot read.

Trade against supervisor and swarm

The three multi-agent coordination topologies have clear operating regions. The table summarizes the differences.

Axis | Supervisor | Swarm (handoffs) | Shared scratchpad
Who holds state | Supervisor, per-specialist isolation | Current active agent | All agents
Parallelism | Parallel delegation possible | One agent active at a time | Parallel readers, serial writers
Coordination overhead | Supervisor round-trips | Handoff turns | Workspace reads per turn
Best team size | 3 to 10 | 2 to 6 | 2 to 4
Debug surface | Supervisor trace | Handoff graph | Workspace history
Canonical use | Parallel specialist work | Customer service flows | Collaborative artifact creation

The shared scratchpad wins when the workload is an artifact evolving through review cycles. It loses when agents have independent subtasks that do not benefit from full visibility.

Neighbors in the series

Supervisor and router and swarm handoffs, the previous two articles, are the alternative topologies. Group chat patterns, the next article, names several orderings for turns in shared-state settings (round-robin, LLM-selected, swarm). Context engineering, in the Foundations stage, describes the compaction and just-in-time retrieval strategies that apply to shared state as much as to single-agent state. The persistence article, in the Memory stage, covers the checkpointing of shared state across sessions.

References

Anthropic. Building effective agents. December 2024.

Wu, Qingyun, et al. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. 2023.

LangChain. Multi-agent collaboration in LangGraph. 2024.

Park, Joon Sung, et al. Generative Agents: Interactive Simulacra of Human Behavior. UIST 2023.

Hong, Sirui, et al. MetaGPT: Meta Programming for Multi-Agent Collaborative Framework. ICLR 2024.