Multi-agent systems

What exactly is a team of agents? Let's try to understand. In a simple way. Start with one agent.

One model, one instruction sheet, one set of tools, looping until the job is done. For a small job, that is plenty. Now hand that same agent twelve tools and a five page instruction sheet. It starts grabbing the wrong tool, and forgetting the rule from page two.

Every tool result also lands in the same context window. Halfway through, the plan from the beginning is buried under pages of output. So you split the work. A team is several agents, each a copy of the model with its own short instruction sheet, its own few tools, its own context.

Now an agent reads three instructions instead of thirty, and picks from three tools instead of twelve. Fewer choices, fewer wrong turns. And parts that do not depend on each other can run at the same time. One agent has to do them one after another.

When an agent wanders down a bad path, the mess stays inside its own context. The others never see it. None of this is free. Every extra agent means more tokens, more waiting, and one more handoff where a detail gets dropped.

So one agent still wins when the job fits in one context with a handful of tools. Reach for a team when the work truly splits apart. So, a team beats one agent when the job stops fitting in one head. Short sheets, separate contexts, parts running at once.

Quick check now. One question is coming up. Let's see if it clicked.

What exactly is an agent's world? Let's try to understand. In a simple way. The world is everything outside the agent.

A folder of files, a database, a browser tab. Engineers call it the environment. The agent never touches it directly. It calls a tool, and back comes a block of text describing one slice of the world.

That block is an observation. And it is only a slice. A folder listing gives file names, not what is inside them. Whatever the text left out does not exist for the agent.

That observation lands in the context window, right next to the instructions. So an agent's world is a pile of words in front of it. Here is the catch. Those words are a snapshot, frozen at the moment it looked.

The world keeps moving. The text does not. So while one agent is thinking, a teammate edits that file. The agent still sees the old copy, and acts on it.

That is stale state. So an agent holds a belief about the world, not the world itself. Two agents that looked at different moments hold different beliefs, and both sound sure. Actions close the loop.

The agent acts, the world changes, and it learns what changed only by looking again. Nothing updates by itself. So before acting on something old, look again, and let the fresh observation replace the stale one. So, an agent knows one thing.

The text it was handed. Partial, a snapshot, and going stale from the moment it arrives. Quick check now. One question is coming up.

Let's see if it clicked.

What exactly is a multi-agent system? Let's try to understand. In a simple way. Start with three agents on one machine.

Each has its own model call, its own instructions, its own context. Right now they are three separate programs. The first thing that joins them is one goal. No single output is the answer.

Each agent produces a piece of it. The joining is plain code. One agent finishes, and its output text is pasted into the next agent's prompt. A handoff is a variable, not telepathy.

Draw every allowed handoff and you get the topology. Agents are boxes, handoffs are arrows. You fix that map before anything runs. Something must pick who runs next.

That is the orchestrator, an ordinary loop in your code. It reads state, calls one agent, stores the result. The loop carries one shared record. The task, and every result so far.

Agents read what they need, and write their piece back. From outside, the whole thing has one door. A request goes in, one answer comes out. Nobody talks to agent four.

The loop also needs a stop rule. Finished, or out of steps, or out of budget. Without one, agents hand work in circles. Notice where the system lives.

Not inside any model. Swap the model tomorrow, and the wiring, the loop, and the stop rule stay. So, a system is agents plus the code around them. One goal, wired handoffs, a loop that picks, and a rule that ends it.

Quick check now. One question is coming up. Let's see if it clicked.

What exactly is an agent's job? Let's try to understand. In a simple way. Start with three agents on a team.

Here is the surprise. All three are the same model, with the same weights. Nothing is specialized yet. What makes one a researcher and another a writer is the text in front of it.

Its instruction sheet, the system prompt. A good sheet is three things. What this agent does, what it must never touch, and what it hands back when it finishes. Then the tools.

The searcher gets search and nothing else. The writer gets no database at all. An agent cannot call a tool it was never handed. Notice what does not work by itself.

Calling an agent a world class expert. That shifts the tone. It does not widen what the agent can reach. The hand back line matters most.

Say the shape. Five bullet points, each with a source link. Now the next agent knows what it is reading. Keep it to one job.

If the sheet says research the topic and also write the final draft, that is two jobs, and one gets rushed. Jobs must not overlap. Two agents both allowed to edit the same file will redo each other's work, or quietly undo it. But cover everything.

Every part of the task should sit inside exactly one job. Whatever belongs to nobody never gets done. So, a job is a short sheet, a few tools, and a stated hand back. Same model everywhere.

The wording does the work. Quick check now. One question is coming up. Let's see if it clicked.

How does agent to agent messaging work? Let's try to understand. In a simple way. Two agents on one machine share nothing.

Separate context windows. Whatever one worked out, the other learns only if it is sent. So talking is writing. A message is text, and your code pastes that text into the other agent's prompt.

Listening is reading it there. Every message carries an envelope. Who it is from, who it is for, and the body. Your code reads the address, and delivers it.

Name the kind up front. A request asks for work. A result hands work back. A question asks for one missing fact.

The receiver knows what to expect. Better still, fix the shape. Not a paragraph, but named fields. Task, file path, done by.

Now the receiver reads it instead of guessing. Messages do not teleport. Your code drops one in the receiver's inbox, and that agent sees it on its next turn, not before. You can address one agent, or post to all of them.

But a broadcast lands in every context window, and everyone pays to read it. Whatever you leave out is gone. The other agent cannot look inside your context. So write the file path and the order number, never, that file.

And a message costs tokens twice. Once to write it, once to read it. Chatty teams get slow and expensive fast. So, agents talk by writing text into each other's prompts.

An envelope, a stated kind, a fixed shape, and nothing important left unsaid. Quick check now. One question is coming up. Let's see if it clicked.

What exactly is a manager agent? Let's try to understand. In a simple way. A team of agents needs someone to pick who works next.

You can hardcode that. Or hand the decision to an agent. That one is the manager. Same model as the workers, but its job is not the task.

Its job is choosing who does the task. It cannot pick a name it has never seen. So you hand it a roster. Each worker's name, and what it is good at.

In most frameworks the roster is literally a tool list. Calling the researcher looks, to the manager, exactly like calling a search tool. The manager also writes the brief, not just the name. The worker sees that text and nothing else, so a vague brief gets vague work.

The result comes back to the manager, not to you. It reads it, decides if that is enough, and picks again. Here is the common trap. If the manager also holds the workers' tools, it will just do the work itself, and your team never runs.

Everything passes through one context window. Every brief, every result. Hand it short summaries, not full transcripts, or it runs out of room. And it will happily keep delegating.

There is always one more check to order. The step limit lives in your code, not in its instructions. So, a manager agent is one agent whose only output is a decision. A roster, a brief, a result read, and a limit you set.

Quick check now. One question is coming up. Let's see if it clicked.

What exactly is an agent command chain? Let's try to understand. In a simple way. One manager can direct a few workers.

Give it twenty, and the roster is too long, and every single result lands in one context window. So a worker becomes a manager of its own small team. Now there are levels. That stack of levels is the chain of command.

Each agent sees only two things. The brief from above, and its own direct reports. Nobody holds a picture of the whole tree. Work flows down as briefs.

Answers flow back up as reports. The top agent never speaks to a worker sitting three levels below it. The middle agent wears two hats. To the boss above it, it is a worker.

To the three below it, it is the manager. What travels up is a summary, never the transcript. Each level compresses what it heard, then hands one short paragraph to its boss. That is also the danger.

Every hop drops detail, like a story retold twice. Keep file names and numbers word for word. And depth costs time. Every level is another round trip, another wait.

Two or three levels is usually plenty. Ten is a traffic jam. One more rule you must write down. When a level cannot decide, it hands the question back up.

Without that, it guesses, and guessing spreads downward. So, a command chain is managers under managers. Briefs go down, summaries come up, and each agent only knows its neighbours. Quick check now.

One question is coming up. Let's see if it clicked.

How does cooperation without a leader work? Let's try to understand. In a simple way. In a manager team, one agent decides who works next.

Take that agent away, and the decision lives somewhere else. So an agent finishes its part and hands the work straight to a peer, by name. That pass is a handoff. In code the handoff is a tool call.

The writer calls, transfer to editor. Your loop reads that name, and the next turn belongs to the editor. Nobody holds the full plan. Each agent carries one rule.

When my part is done, pass to this one. The route is the sum of those rules. So each agent needs a short list of who it may hand to. If everyone can call everyone, the pass becomes a guess.

The simplest version skips choosing. A fixed circle, each agent speaks in turn. Predictable, but agents speak even when they have nothing to add. Two agents can both think the job is theirs, and do it twice.

So your code tracks exactly one holder of the work at a time. Handoffs also bounce. The writer sends to the reviewer, the reviewer sends it right back. Nobody notices, because nobody is watching the pair.

And no agent announces that the team is done. You write the stop rule. A done signal to look for, and a hard cap on handoffs. So, a leaderless team runs on handoffs.

Local rules choose the route, one agent holds the baton, and your code decides when to stop. Quick check now. One question is coming up. Let's see if it clicked.

What exactly is shared memory for agents? Let's try to understand. In a simple way. An agent's context window is its own.

When its turn ends, that window is thrown away, and everything it worked out goes too. You could message a teammate. But a message reaches only the agent you name, while it is running. An agent starting later learns nothing.

So you keep one store outside every agent. A file, a table, a small database. Anyone can write, anyone can read. That is shared memory.

Reading and writing are tool calls. Nothing lands in an agent's prompt by itself. It arrives only when that agent asks, on its turn. So give every entry a name.

Chosen model. Budget left. Test results. A reader looks up one key, instead of a wall of notes.

Write settled facts and file paths, not whole conversations. Every line in that store is a line somebody else pays tokens to read. Stamp each entry with who wrote it, and when. Otherwise a reader cannot tell a checked fact from a guess left there an hour ago.

Two agents write the same key at once, and the last write quietly wins. Safer to add a new entry, and leave the old one. And never let an agent read the whole store. It fills the window with other people's notes.

Fetch the keys the job needs. So, shared memory is one store every agent can reach. Named entries, stamped with a writer, read on purpose. It keeps what a window forgets.

Quick check now. One question is coming up. Let's see if it clicked.

What exactly is a disagreement between two agents? Let's try to understand. In a simple way. You give two agents the same question.

One says four hundred dollars. The other says six hundred. Both sound certain. Your code is holding two strings, not two truths.

So the next step takes whichever arrived first. A winner got picked, by ordering. So you decide the tie-break rule before the run. In your code, not in a prompt.

Three rules people actually use. First, vote. Ask three agents, and keep the answer the majority gave. Cheap, and it needs no new logic.

But a majority is popular, not correct. The same model, given the same prompt, makes the same mistake three times. Vary the model, or the vote means little. Second, evidence.

Make each agent say where its number came from. Your code opens that source and checks. The answer that holds up wins. Third, a judge.

Another agent reads both answers against a rubric you wrote, and picks. But the judge is a model too. It leans toward the longer answer. You can also let the two argue it out.

Cap that at two rounds. Otherwise they flip back and forth, and you pay for every turn. And log every conflict. Two agents disagreeing is the loudest signal you get that something is wrong.

Settle it silently, and you never see it. So, nothing settles a disagreement by itself. You pick the rule. Vote, evidence, or a judge.

Cap the argument, and write the conflict down. Quick check now. One question is coming up. Let's see if it clicked.

How does a big task become small jobs? Let's try to understand. In a simple way. You start with one sentence.

Build me a competitor report. No single agent can do that in one go. It is not one job, it is many. So something writes a plan first.

A list of smaller jobs, in plain text. Usually a planner agent, before any work begins. Each job has to stand alone. What to do, what it starts from, and what finished looks like.

The worker sees that text and nothing else. Then you mark which job waits on which. Summarize the reviews cannot start until the reviews are collected. Those arrows are the dependency graph.

Jobs with no arrow between them run at the same time. That is where the speed comes from. Not from owning more agents. Every split needs a join.

Someone has to stitch the pieces into one answer. That merge is a job too, so put it in the plan. Size matters. Too big, and the worker drifts.

Too small, and you pay a whole model call to do almost nothing. And the plan was written before anyone looked at anything. It is a guess. When a result contradicts it, plan again.

The pieces must also cover the whole goal. This is the quiet bug. Every job succeeds, and the report is still missing a section. So, a big task becomes a written list of small jobs.

Standalone briefs, arrows for what waits on what, a join at the end. Quick check now. One question is coming up. Let's see if it clicked.

What exactly is a proxy agent? Let's try to understand. In a simple way. A team of agents keeps needing a human.

Approve this. Which one did you mean. But you are not there for every step. So one agent holds your seat.

That agent is the proxy. It is the only member you talk to. Your request goes in through it, and the answer comes back out. In most frameworks the proxy barely thinks.

It is mostly plain code. It forwards messages, runs the tools, and decides when to interrupt you. One setting decides how often it interrupts. It is called the human input mode.

Always ask, never ask, or ask only at the end. Always ask means the run pauses at every turn and waits for your typing. Safe, and slow. Never ask means it does not wait.

When the team needs a decision, the proxy answers for you, from the standing instructions you wrote before the run. So it answers things you never covered. And that guess lands in the transcript looking exactly like your words. Nobody downstream can tell the difference.

The proxy is also the hand. It runs the code and calls the tools. So the approval gate belongs right here, before anything spends money. On the way out it squeezes the whole conversation into one message.

Whatever it leaves out, you never see. So, the proxy agent is your seat. One door in and out, one setting for how often it asks, and a guess when you are away. Quick check now.

One question is coming up. Let's see if it clicked.

What exactly is a team that forms on the fly? Let's try to understand. In a simple way. In most systems you name the team before the run, written into your code.

But you cannot know what the task needs until you read it. So you hand one agent an extra tool. Create agent. Calling it makes a new teammate appear in the middle of the run.

That call carries the whole teammate. An instruction sheet written on the spot, a short tool list, and the first brief. Same model, new text. It rarely invents that sheet.

You keep a few templates. Researcher, coder, checker. The spawning agent picks one and fills in the blanks. Your code then registers the new agent under a name.

That registry is what makes it reachable by the others. A fresh agent starts empty. It never saw the earlier turns. Everything it needs must be copied into its brief, or it works from nothing.

When it hands back its result, it usually disappears. Its context is thrown away. What it learned is gone, unless it went to shared memory. Here is the trap.

The agent you spawned can spawn too. Two become four, then sixteen, and your bill with them. The cap lives in your code. Spawn only when you cannot predict the shape of the work.

A fixed team is cheaper, and easier to debug. So, a team formed on the fly means the roster is written during the run. A template, a brief, a name, and a hard limit. Quick check now.

One question is coming up. Let's see if it clicked.

What exactly is agent peer review? Let's try to understand. In a simple way. An agent finishes its work and hands it over.

Nobody looked at it. Whatever it produced on the first try is what you ship. So you add a second agent with one job. Read that output and judge it.

The finished work is pasted into its prompt as text. Why not ask the writer to check itself? Its own answer is already in the context, and it reads as settled. A separate call starts clean.

A reviewer with no checklist just says, looks good. So you write the rubric yourself. Every number sourced. No step skipped.

Nothing invented. What comes back is not a rewrite. It is a verdict. Pass or fail, the exact lines that failed, and the reason for each.

Your code sends that verdict back to the writer as a new message. It fixes those lines and returns. Make, check, fix. That is the loop.

The loop needs a stop rule, written in your code. Stop on a pass, or after two rounds. Without one, the two can argue forever. Here is the failure mode.

Asked if the work is good, a model tends to say yes. So demand a quoted line and a reason. Every round is another paid call. So put review where a mistake is expensive.

Code that runs, numbers you publish, anything a customer reads. So, peer review is a second agent, a rubric, a verdict with reasons, one revision pass, and a stop rule. Quick check now. One question is coming up.

Let's see if it clicked.

What exactly is emergent behavior? Let's try to understand. In a simple way. You build a team of agents.

Then the team does something you never wrote down. Not in any sheet, not in your code. That is emergent behavior. It happens because no agent holds the plan.

Each one follows its own short sheet and answers whatever message lands in front of it. So the behavior is not inside any agent. It sits in the interactions. Add one more agent, and the number of paths jumps.

Sometimes the surprise helps. Two agents settle into a split of the work that you never assigned, and the job finishes sooner. And sometimes it hurts. Agent one asks agent two to confirm.

Agent two asks agent one. Neither is broken. The loop just runs, and every turn costs money. Another one.

An agent guesses a number. The next agent quotes it. The third cites the second. Repetition turns the guess into a fact nobody checked.

That is why debugging is hard. Every sheet looks sensible on its own. The problem only shows up in the log of who said what to whom. Emergence is also fragile.

Change one word, or the order the agents run in, and the surprise appears or vanishes. You cannot design it away. You fence it in. A step limit, a message cap, and one check outside the agents that can stop the run.

So, emergent behavior belongs to the group, not to any agent. Read the interactions, keep the logs, set hard limits. Quick check now. One question is coming up.

Let's see if it clicked.