How several AIs share one workspace

Most people who first ask two AIs to help at the same time run into the same problems. A paragraph one of them just fixed gets overwritten by the other. A direction agreed yesterday is forgotten today because a different tool is open. In the end everyone says "done", but nobody can say exactly what was finished.

None of this is because the AI isn't smart enough. It happens because we are organising a team of assistants the way we would chat with one. This post explains how we put several AIs in one workspace so they can work at the same time without stepping on each other, and what people need to look at along the way, and what they don't.

First: what an AI agent actually is

Take an AI agent apart and there are only three things: a model, the context read in for this turn, and the tools it can use. It reads files, thinks, calls tools to write or check something, hands back the result, and starts the next turn. It is a loop.

The key point is that the model itself has no memory. When a turn ends it does not "remember" what just happened; everything it knows next time comes from context read in again. A chat window looks like it is building up memory, but chats end, get compressed, and disappear when you switch tools.

So our first principle is simple: continuity lives in files, not in chat memory. What to do is written on a work order, how far it has got is recorded in status, and what happened is written in an event log. Switch to another AI, come back a day later, or use a completely different AI tool: as long as it reads the same files, it picks up from the same place.

One coordinator splits the work

When the workload grows, we don't let several AIs each figure it out on their own. We first name one coordinator. It doesn't rush to start; it breaks the whole job apart first.

The split has two layers. The first is work orders: each one says what to do, what the inputs are and what counts as done. Once issued, a work order is fixed and isn't quietly changed halfway through. The second is waves: work that depends on other work goes in a later wave, and work that can happen at once shares a wave.

The benefit is that everyone, people and AIs alike, sees the same map. Which work is in which wave, who is on it and whether it is finished never depends on someone remembering to tell you.

Many workers: in parallel, each writing its own part

Then come the workers. They can run in parallel, but the number of slots is limited. A kitchen has a fixed number of burners; put too many pots on and none of them gets proper attention. Limiting slots keeps quality and cost within reach.

Each worker may write only its own cell. Picture the workspace as a large table: everyone can read all of it, but each person writes only in the cell assigned to them. Overlaps don't fight; they queue. When a real conflict appears, both sides are kept and handed to the coordinator or a person to merge, rather than the later writer overwriting everything.

Before handing work in, each worker checks itself with a checker: is the format right, are required fields filled, did it write anywhere it shouldn't? The coordinator then runs the same checker again on receipt. Because self-check and re-check use the same standard, there is no gap between "I think it's fine" and "you think it isn't".

Sampling, status, and the one card people see

Machine checks only catch mistakes that can be written as rules. Some problems, like an odd tone or an example that doesn't quite fit, still need a person or another AI to look. But if people had to read everything, there would be no point in working in parallel.

So we sample. For example, one in every twenty is read closely. Which one isn't picked at random by hand; a fixed rule decides, so anyone re-running it gets the same pick. That makes the sampling itself checkable, instead of happening to land on the ones that were fine.

As for "is it done?", we don't accept anyone simply declaring it. Status is always derived from files: the work order exists, the output exists, the record of a passed check exists. If any of these is missing, the status simply won't become done.

People's attention is the scarcest resource. The system's job is to turn a hundred drafts into one decision worth their time.

So at the end of each wave, people get one short decision card: what this wave did, what passed, what needs their decision, and what we recommend. They can answer each item with "yes" or "later" without opening a hundred files.

After a failure: attach the reason and run again

Some work orders won't pass, and that's normal. What matters is what happens next. We write down clearly why it failed and send that back with the work order, so the next run sees the reason from the start.

It sounds obvious, but often an AI retry is just "try again", and it makes the same mistake. Attaching the reason writes the last round's experience into the next round's context, which brings us back to where we started: memory lives in files, not in the model.

• Every retry carries the previous failure reason.
• If a work order still fails after a few retries, it becomes a decision card for a person.
• Every retry is recorded in the event log so it can be traced later.

What people do here

By now it may sound as if people have been taken out of the loop. It's the opposite. People no longer watch every step; they spend their time where judgement is really needed: whether the direction is right, whether an exception should go through, what is worth doing first.

The system does the repetitive, checkable part well and lays out clearly what needs a person's decision. People make the call, and that decision is also written back to files, becoming the basis for the next round of work.

In short

• An AI agent is a loop with no memory; continuity lives in files.
• A coordinator splits work into fixed work orders and waves; workers run in parallel within limited slots and write only their own cells.
• Self-check and re-check use the same checker, plus reproducible sampling; status is derived from files.
• People see one decision card per wave; failures are retried with the reason attached.

Getting several AIs to work together doesn't depend on a smarter model. It depends on a division of work and a record that everyone can read. Put the rules in files, and it no longer matters who picks the work up.