It was never multi-agent. It's multi-context.

If you want different results from an agent, change the context it works in before you change the agent. System prompt, tools and instructions are set at the start of the session and weigh little. The repo, documents, notes and decisions the agent reads while it works weigh far more, and they decide what it notices and what it ignores. I saw it on 8 November on a real feature, and since then I design contexts instead of agent teams.

By multi-context I mean a system where the same agents work in several separate environments, each with its own material and its own kind of question, and information, never the whole conversation, moves between them. A classic multi-agent system does the opposite: many agents with different roles in the same environment.

What actually decides how an agent behaves

When you start a session, the agent gets a system prompt, a list of tools and the project instructions. That's the part everyone polishes, and it's thin. Then the agent reads: files, tests, documents, past decisions, the history of the repo. That part is thick and grows with every step. In my sessions, which run for weeks, almost everything in front of the model at some point comes from the environment.

There is also a starting bias. Coding agents are built to write code, and a code repo pushes every question toward an implementation. Ask what a feature should do and you get data, screens and components back. That's perfect when the question is how to build. When the question is what to build and for whom, the repo is the wrong place.

The case: one brand, many markets

motive observes what AI assistants answer when someone asks about a market. Until 8 November a brand lived in a single market, with a single language. The real world is different. A brand with an Italian domain sells everywhere and publishes its site in 27 languages. A global brand has an "international" market that can be English, or Spanish if you want to reach Spanish speakers worldwide. An agency splits the work by market and by product line, and brings the client a scorecard per market.

The coding agent already had the prompt and a first answer. I already knew where the material to decide well lived: how agencies work across markets, languages, clients, the mistakes I've seen people make. None of it lives in the repo, and while I'm working on the product I can't recall all of it from memory. It lives in my second brain.

I didn't create a brainstorming agent. I don't think in agents anymore, I think in contexts. I opened a session in the second brain and brought the same prompt, the coding agent's answer and my concerns. No new system prompt, no new tools. Only the place where the work happened changed.

The answer came back with the eye of a serious agency. A few things the repo could not know:

Language matters more than country. An assistant asked in English about a market that speaks another language can skip the web search and answer from old memory.
Every market has its own mix of assistants, each with its own weight. ChatGPT isn't available in China, where Doubao, Qwen, DeepSeek and others count.
A question has to be adapted to each market. Translated word for word it measures something else, and comparing markets is valid only on questions that share the same core.
A brand is the name the buyer says. Aperol is a brand, Campari Group is the company.
The language versions of a site show where content exists. Where the client sells is the client's call.
You pay per observed question. Pricing per market would punish exactly the brand that sells in 27 languages.

I commented, the second brain corrected, and the decision ended up in a short ADR in motive's repo. The coding agent received it with the decision already made. It never joined the brainstorm.

The decision landed in the repo at lunchtime. Before dinner motive was tracking brands across several markets in production: markets suggested from the site, questions adapted per market, a weight for every assistant and a scorecard per market. Five slices, each with its own spec, and by the evening the audits were closed.

Why the same agent answers differently

The model didn't get better at marketing between one session and the next. It read different things. In the repo it had in front of it how the product is built. In the second brain it had who the product is for and how its buyers work. The questions an agent asks itself depend on what surrounds it.

Constructivism has said this for more than forty years. In “The Invented Reality”, the collection Paul Watzlawick edited in 1981, Heinz von Foerster writes that the environment as we perceive it is our invention, and Ernst von Glasersfeld that knowledge has to work inside the experience of whoever uses it, more than match an outside reality. The agent in the repo and the one in the second brain built two realities of the same feature, each consistent with what it had in front of it. The context decides which one you get.

I had already seen it with archiving: the same model wrote deep notes in my vault and thin ones in another memory connected from outside, because the instructions and sources were different (the story). There it changed the quality of the work. Here it changed a product decision.

An agent team is often one model wearing five hats

The most common pattern is a team: the PM agent, the architect agent, the QA agent, each with its own system prompt. If they all run on the same model, in the same repo, reading the same files, the difference between them is a few opening lines. The rest of the context is identical, and so are the blind spots.

That's why I split work by context. A question about what to build goes where users, clients and past decisions live. A question about how to build goes in the repo. Review goes to a model from another family, which looks with different eyes (why). Each context has its job, and the roles come from there.

Between contexts, information is exchanged

The conversation stays where it is. Information moves. Gregory Bateson defined it as a difference that makes a difference ("Steps to an Ecology of Mind", 1972). Out of the whole brainstorm, the coding agent receives only what changes what it will do: the decision, the reasons, what's left out, the criteria for done. The discarded ideas and my half-formed doubts stay where they were born, because to the builder they are noise.

For Luhmann the receiver selects the information: the same decision informs the coding agent one way and the review another. So I write the exchange for whoever will read it, in their context, and I test it from there. The medium matters little. This time it was an ADR, other times it's a spec.

The exchange runs both ways, as in every cybernetic system since Norbert Wiener: without feedback there is no control. What the coding agent learns while building goes back to the second brain when it changes something meant to last, a decision or a lesson. The state of the work stays in the repo, where it belongs.

The strongest objection: so the system prompt doesn't matter

It matters for what must always hold: permissions, safety, the tools the agent can reach. And the model matters when you want a truly different point of view, as in review. The question is where you put the work. Polishing the personas of agents that all live in the same place changes the tone of the answers. Changing the place changes the questions they ask.

From Monday

Before you create a new agent, ask whether you need a new context.
Separate questions about what to build from questions about how to build it, and give each its own place.
Keep what you know about users, clients and the market where an agent can read all of it.
Take the same prompt into two contexts and compare the answers before deciding.
Between contexts, pass information: decision, reasons, what's left out, when it's done. The conversation stays where it was born.
Keep the coding agent out of the brainstorm.
For review, use a model from another family, in a context different from the author's.