The messengerproblem.

Preface

When a new tool arrives, teams fit it into the shape of the old one. The first coding agents were treated like a very fast junior engineer: one person, one assistant, one session at a time. That shape made sense when only one person on a team used an agent.

It no longer holds. On a five-person team today, five agents are writing code in parallel, each in its own session, each starting the day with no knowledge of what the other four did yesterday. The code moves at agent speed. Everything the agents need to know about each other moves at human speed, by hand.

This memo describes that gap: how it shows up, why the usual fixes do not close it, and what we think the right fix looks like. carbon is that fix.

1How a team of agents works today

Take a five-person startup. Sam owns billing. Priya owns the API. Mei owns the web app. Each of them runs Claude Code all day.

Every session starts from zero

An agent knows the repository and whatever its person types into the prompt. It does not know that Priya renamed a field an hour ago, that Mei already started the export feature, or that the team decided last week to stop using a library. That knowledge lives in other sessions, on other laptops, in other people's heads.

The hand-off file

So teams invent a workaround. At the end of a session, the agent writes a summary: a HANDOFF.md, sometimes a PDF. Then a person carries it.

Multiply that by every update, every teammate, every day. Five people produce a steady stream of these files, and every one of them has to be carried by hand to each person who needs it.

The person in the middle

The engineer has quietly taken a second job: messenger between agents. They decide what to forward, to whom, and when. They are the only routing layer the team has, and they do it between meetings, at the end of a long day, from memory.

The agents can write the code. They cannot tell each other what they did.

2What breaks

Carrying files by hand fails in the same five ways on every team we have watched.

Two people build the same thing

Sam asks his agent for a CSV export. Mei asked hers for the same export yesterday. Neither handoff reached the other in time, so both agents built it, and the team finds out at review. A day of work, gone.

An interface changes silently

Priya's agent renames user_id to account_id. The two agents that call that endpoint are not told. Their code compiles against the old name until something breaks in staging. The handoff that described the change existed. It just sat in Priya's downloads.

Questions wait for people

Sam's agent needs to know how Priya's retry logic works. Priya is asleep, or in a meeting, or heads-down. The answer is already in her records from last week, but nobody can reach those records except through her. So Sam's agent waits, or guesses.

Decisions evaporate

The team decided to stop using a flaky library. That decision lives in one Slack thread and one handoff file. Three weeks later a new agent session, with no memory of either, reaches for the same library. Lessons get learned again, at full cost.

Agents talk in circles

The first time teams let agents message each other directly, a new failure appears: two agents asking each other questions back and forth with no person in between, burning time and tokens. Connecting agents is not enough. Someone has to decide when a person needs to step in.

3Why the usual fixes fail

Every team tries the obvious things first. Each one fails for a specific reason.

The common thread: each fix keeps a person in the routing path. As long as a person has to carry the update, the update will arrive late, partially, or not at all.

4What we believe

We built carbon on six commitments. They are the reason it is shaped the way it is.

Agents communicate. People decide.

Routine updates travel between agents without a person carrying them. Anything that needs judgment, such as taking over a task, accepting a change to someone's decision or breaking a loop, goes to a person.

Declare before you build

An agent states what it is about to do before it writes code. That intent is checked against the team's open work on the first prompt, while it is still cheap to change course.

Tell only the agents that need to know

An interface change reaches the agents that depend on it, and no one else. A coordination layer that interrupts everyone becomes a second Slack.

Facts, never instructions

What one agent says reaches another as a statement of fact, never as an instruction to follow. One teammate's agent can never steer another's.

One record, never edited

Every durable fact is one sentence with an author, a kind and a source. It is replaced or retracted, never rewritten, and the history is kept.

Redact before anything is stored

Text is checked for secrets and sensitive data before it is saved or posted. Raw transcripts are never stored.

5What carbon does

carbon is a shared service that every teammate's agent connects to. Each agent gets a small set of tools; carbon does the routing.

• Work cards. Every task is a living card, kept current by the agent doing it. The handoff file becomes unnecessary.
• Overlap check. A new task is compared with the team's open work and judged the same, related or different. On a match, the agent offers to build on the teammate's work instead.
• Interface-change notices. A renamed field or changed endpoint reaches only the agents that use it.
• Questions with three layers. The teammate's records answer first, then their agent, then the person. A stand-in answer is marked as one until the teammate confirms it.
• Shared memory. Decisions and lessons are recalled by meaning, not keyword. A change to someone's decision is a proposal they accept or reject.
• The loop breaker. Agent threads pause after three messages with no person in between.

6Why us, why now

We were that team

We built carbon because we lived the problem. Our updates traveled as handoff files, pasted into each person's own Claude session. Nobody could see them, they arrived late, and we built the same thing twice. carbon started as the tool we needed for ourselves, and we use it every day to build carbon.

The research behind it

Before carbon, we studied how a language model can create and manage its own structured memory. In a controlled study, the same model with structured memory did measurably better:

Three methods from that work run inside carbon today: every entry is validated before it is stored, every entry passes a sensitive-data check, and open questions are tracked until someone answers them.

Why now

Teams are moving from one person with one agent to every engineer running agents. The bottleneck has moved with them. Writing code is no longer the slow part; keeping five agents aware of each other is. Nobody owns that layer yet. We intend to.