How do you run multi-agent AI systems in production?

At GOGOGO LLC we build multi-agent systems: an orchestrator routing work between specialised agents, each with concrete tools. I also use agents every day to build our own products, including the GoTasty game. This is what I have found matters once agents leave the demo and touch real systems. None of it is exotic. Most of it is the discipline we already expect from any service, applied to software that decides what to do next.

What makes a multi-agent system different from one big prompt?

A single model with a long prompt and every tool attached is easy to start and hard to trust. When it does something wrong, you cannot tell which part of the prompt caused it, and you cannot restrict one behaviour without touching all of them. A multi-agent system splits the work: one coordinator owns the run and decides which specialist handles each step, and each specialist has one role. Clear roles give you clear blame: when a step fails, you know whose step it was.

That split is also what makes the system operable. You can test, version and roll back one agent without redeploying the others, and you can give each one its own model, budget and permission set.

Why log every step?

Because you will need to answer "why did it do that?" about a run that happened last Tuesday, and the model will not remember. Our rule is that every hand-off, tool call, score and outcome is written down with the input the agent saw and the version of the agent that produced it. That gives you three things:

• Replay. You can run a failed case again against a new prompt or model and compare the two.
• Audit. Anyone can trace a decision back to the context that caused it, which matters the moment a customer asks.
• Rollback. If a change made things worse, you know exactly which runs it touched.

Log at the boundaries, not only at the end. A final answer that looks fine can hide a tool call that should never have happened. We wrote more about this in observability by default.

How do you scope an agent's tools?

Start from the job, not from what is available. An agent that drafts replies does not need to send them. An agent that reads a database does not need write access. Every tool you add is a new way to fail, so each agent gets the smallest set that lets it finish its task, scoped to one product surface.

Then sort actions by consequence. Reading, drafting and computing can run freely. Anything irreversible, anything that spends money and anything that touches credentials needs a person to approve it first. We hold our own coding agents to the same rule: in the GoTasty repository they may commit and push on working branches without asking, but they ask before an irreversible step, a payment or a credential, and some cloud console settings are reserved for a human outright. On the Android emulator, our QA agents must address one device by its serial, never run a broad kill command, and use fixed ports. Small rules like these are what make it safe to leave agents running.

How should agents hand work to each other?

With a typed payload, not a paragraph. When one specialist passes work to the next, the hand-off says what the task is, what has been decided, what evidence it rests on and what is still open. No hidden state lives in a conversation the next agent cannot see. If the payload does not validate, the hand-off fails loudly instead of the next agent guessing.

The same goes for memory. Context should be stored per tenant and per conversation, versioned and queryable, so an agent reads what came before from a record, not from a summary that another model wrote and nobody checked.

How do you know if a multi-agent system is getting better?

You grade it. Every agent needs a definition of a good outcome that can be checked, ideally by code: did the reply answer the question, did the build pass, did the action match the policy. Where code cannot check it, a person checks a sample on a schedule. Our QA agents for GoTasty work this way: a build passes when the log shows zero Unity errors and the bot opens each zone inside its time window, not when an agent says it looks fine. The bot logs its pace every 15 seconds, and pacing runs use a fixed 1/30 s step and a seeded random, so two runs of the same build give the same numbers.

Grades over time are how you notice drift after a model update, and how you decide whether a new agent earns its place. We go deeper in grading multi-agent systems.

Where do you start?

1. Write the workflow down as steps and mark the ones that change something outside the system.
2. Give each step one agent, one role and the minimum tools.
3. Define the hand-off payload between steps before you write prompts.
4. Log every boundary from day one, with the agent version.
5. Put a person in front of every irreversible action until the logs show you can remove them.

To see how we apply this to our own products, start with the agent systems page, or the engineering record on this site, which lists every figure with its date and source.