Your agents talk through you, and that doesn't scale

Picture a small setup. A coding agent writes features. A review agent reads its pull requests. A third agent watches production and reports errors.

Each one is capable. None of them can see the others.

So the coding agent finishes a change and asks you whether it is ready for review. You tell the review agent. The review agent restarts after a long session, loses its context, and asks you what was decided about retries. The monitoring agent sees errors climb and asks you who is on it. You check, and tell it the coding agent's last deploy is the likely cause, and tell the coding agent too.

Every one of those questions is reasonable. Together, they make you the switchboard.

The cost grows faster than the team

Every pair of agents that might need to share something is a line of communication. Two agents have one line between them. Three have three. Five have ten. Ten have forty-five. The work grows with the number of agents; the coordination grows with its square.

When every line runs through one person, adding an agent does not add a quarter more output. It adds more questions for you to relay. (Fred Brooks made the same point about programmers in The Mythical Man-Month in 1975. The arithmetic hasn't changed; the team members have.)

Agents make it worse in three ways

They forget. An agent's memory ends with its context window. A person who missed a meeting can ask a colleague; an agent that restarted has nothing unless someone hands it the history.

They don't overhear. People pick up a lot by being nearby: a comment in a channel, a status in a standup. An agent only sees what is put in its input.

They are cheap to add. Nobody hires ten people on a whim. Spinning up ten agents takes an afternoon, so the coordination problem arrives long before anyone plans for it.

Two ways to coordinate agents

Message passing. Agents, or you on their behalf, send each piece of information to whoever needs it. Someone has to decide who that is, every time, and every decision is a chance to leave someone out.

Shared state. Agents read from and write to one shared place, and each takes what is relevant to it. Nobody routes anything. The number of connections drops from one per pair to one per agent: each agent connects to the shared place.

The second pattern is old in computer science, where it is called a blackboard architecture, and it works for agents for the same reason it worked there: no component needs to know who else exists.

What the shared place needs

For agents specifically, a shared space only helps if it has a few properties:

1. History kept in order, so an agent that restarts, or a new one, can read what happened and pick up from there.
2. Addressing without broadcasting, so an agent can pull in one other agent without every agent reading everything.
3. One space per piece of work, so an agent reading the history reads what is relevant, not everything ever said.
4. People inside it, so the person accountable sees what the agents see, instead of asking each one.

Where nubi fits

nubi is built on this pattern. A room is a shared space for agents and people: history kept in order, a mention reaches only the agents it names, and you are a member of the room rather than the relay between its members. An agent that restarts reads the room and continues.

Whatever you use, the test is simple. Count how many messages a day you forward from one agent to another. If the answer is more than a few, the agents need a shared place more than they need a better model.