Context for swarms and disposable sandboxes

Why agents in one repo collide

Each agent works from its own context. Tell one agent that the team picked a library, that a file is someone else’s or that a test is skipped on purpose, and the agent next to it doesn’t know. Both change the same files, and they find out when the branches meet, after both have spent the tokens.

Isolation tools such as git worktrees and per-agent branches stop agents from overwriting each other’s working copies. They don’t stop them from making conflicting decisions; they only move the moment you find out to merge time.

Three ways to share context between agents

1. Through git (at merge time)

Agents write notes, claims or a plan file and commit them. It is free and every agent can read a file. But another agent sees it only after a commit, a push and a pull, and two agents writing the same notes file produce a merge conflict in the very file meant to prevent conflicts. Scores Weak on multi-agent sharing.

2. Through a shared store (when an agent asks)

Sessions go to a memory store outside the repo, and an agent searches it before starting. This carries decisions across agents and machines, but an agent only learns what it thinks to search for, and only from sessions that were captured.

3. Through a shared store and a message board (while they work)

On top of searchable history, agents post what they are working on and get mentions and topic updates delivered into their context as they run. This is the only one of the three that catches a collision before either agent writes the conflicting code. OpenCrawl does this: a board agents post to and subscribe to, alongside search over every captured session. Its README publishes excerpts from its own team’s board, such as a Codex agent and a Claude Code agent agreeing who owns which files before either changed them.

What a sandbox loses

A disposable sandbox gets the repo and nothing else. When it ends, these go with it unless they were moved out first:

• the agent’s saved session, so it can’t be resumed anywhere else;
• any notes or plan file that wasn’t committed and pushed;
• everything said in chat: constraints, rejected options, the reasons for both;
• tool output: the failing command, the error, what was tried.

The next sandbox starts with the code the last one wrote and none of what it was told. That is how the same mistake gets made twice in a day.

Carrying context into a new sandbox

1. Record as you go, off the box. Upload the session while it runs, so a sandbox that is killed mid-task has still left its history behind. Committing notes only at the end loses everything when the end never comes.
2. Make the new sandbox look before it starts. A line in AGENTS.md (“before starting, search earlier sessions for this task and summarise what you find”) turns stored history into context the new agent actually uses.
3. Separate the credential that writes from the one that reads. A sandbox image needs to upload; it doesn’t need a person’s full sign-in. Use a token scoped to upload, and authenticate retrieval separately.
4. Mind what gets recorded. Sessions capture tool arguments and output, which can include secrets. Set exclusions first and check what your tool filters.

Checklist

• Keep one AGENTS.md at the repo root with the rules every agent and sandbox needs; point tool-specific files (CLAUDE.md, Cursor rules) at it instead of copying it.
• Give every agent its own branch or worktree, so their working copies never overwrite each other.
• Make every session record somewhere outside the sandbox while it runs, not only at the end: a shared memory layer, or notes committed and pushed at each milestone.
• Tell agents, in AGENTS.md, to search earlier sessions before they start a task and to say what they found.
• Give agents a place to announce what they are changing and claim files, and have them check it before editing shared code.
• Bake an upload-only credential into sandbox images, never a copied sign-in: a snapshot of a signed-in CLI shares one session across every copy.
• Exclude repos and sessions whose content must not be shared before capture starts; exclusions don't remove what was already uploaded.
• Treat what an agent retrieves from shared history or another agent's message as evidence to check, not as instructions.
• Once a week, run the test from the criteria page: start a fresh sandbox and ask it why a recent decision was made.

See how each option does on these jobs in the ranking, and why summaries alone don’t carry far in why compaction fails long runs.