How Anthropic Builds Multi-Agent Systems

Summary

This video from Anthropic presents practical engineering patterns for scaling agent capabilities using multi-agent architectures, emphasizing that the harness surrounding a model—not the model benchmark alone—determines real-world performance.
Four architectural patterns are covered: Generator-Verifier loops for unbiased accuracy, Orchestrator/Sub-Agent systems for scope isolation and parallelization, Shared State systems for creative iteration, and event-driven message-bus architectures for asynchronous workflows.
Anthropic recommends starting with a single agent to identify specific failure modes before adding multi-agent complexity, and its internal culture of 'demos, not memos' drives rapid prototyping of real implementations over prolonged design planning.

How Anthropic Builds Multi-Agent Systems

Moving beyond simple "tokens in/out" chat interfaces requires optimizing the harness surrounding large language models. This talk breaks down practical engineering patterns for scaling agent capabilities using multi-agent architectures. The session highlights how to choose the right system structure based on context constraints, specialization requirements, and task execution styles.
𝗞𝗲𝘆 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀:
• 𝗛𝗮𝗿𝗻𝗲𝘀𝘀 𝗘𝗾𝘂𝗮𝗹𝘀 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲: Model benchmarks alone do not dictate real-world success; the surrounding harness heavily influences final output quality.
• 𝗦𝘁𝗮𝗿𝘁 𝗦𝗶𝗺𝗽𝗹𝗲: Developers should begin with a single agent to identify specific failure modes before jumping into multi-agent complexity.
• 𝗖𝗼𝗻𝘁𝗲𝘅𝘁-𝗖𝗲𝗻𝘁𝗿𝗶𝗰 𝗗𝗲𝘀𝗶𝗴𝗻: Multi-agent systems should be structured around isolating context to prevent compaction and context dilution.
• 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗮𝗹 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀: Proven patterns include Generator-Verifier loops for accuracy, Orchestrator/Sub-Agent for scope isolation, and Shared State for creative exploration.
• 𝗗𝗲𝘁𝗲𝗿𝗺𝗶𝗻𝗶𝘀𝘁𝗶𝗰 𝗚𝘂𝗮𝗿𝗱𝗿𝗮𝗶𝗹𝘀: Critical safety boundaries, security permissions, and API verifications must live in external code hooks rather than relying on LLM self-governance.
• 𝗗𝗲𝗺𝗼𝘀 𝗢𝘃𝗲𝗿 𝗠𝗲𝗺𝗼𝘀: Rapidly building and testing real implementations yields better results than prolonged planning in infinitely complex AI design spaces.
00:00 — Introduction & The Agent Harness
02:32 — Why You Should Always Start With a Single Agent
03:42 — Triggers for Multi-Agent Complexity: Dilution, Specialization, Parallelization
05:40 — Pattern 1: Generator-Verifier Architectures for Accuracy
07:22 — Pattern 2: Orchestrator & Sub-Agent Systems
09:50 — Pattern 3: Shared State Systems for Exploration & Iteration
12:06 — Anthropic’s Internal Culture: "Demos, Not Memos"
13:01 — Pattern 4: Event-Driven Message Bus Architectures
14:49 — Overcoming Prompt Bloat and Starting Clean
16:32 — Navigating Non-Deterministic, Infinitely Dimensional Problem Spaces

Chapters

FAQs

When should developers choose a multi-agent architecture over a single agent?

According to this video, there are three signals that justify moving to a multi-agent architecture: context dilution where a single agent's context window becomes overloaded, specialization requirements where different tasks need different model configurations or tools, and parallelization opportunities where independent work can run concurrently. Developers should start with a single agent to identify specific failure modes before introducing multi-agent complexity. Adding more agents when a single well-designed agent would suffice is described as bringing unnecessary complexity to a solvable problem.

What is the Generator-Verifier pattern and when should it be used?

The Generator-Verifier pattern uses two separate agents where one generates a candidate output and the second independently evaluates whether that output is correct, without being biased by having produced it. This separation is particularly valuable for tasks where accuracy is critical and self-evaluation by the generating agent would be unreliable. The pattern is presented in this video as one of the most effective approaches for improving factual accuracy in multi-step agent outputs.

What does 'harness equals performance' mean in the context of multi-agent systems?

The phrase reflects Anthropic's observation that the surrounding harness—including tool definitions, context management, prompt structure, and system constraints—influences agent performance as much as or more than the underlying model's benchmark scores. Teams that select models based on leaderboard rankings often find their real-world results diverge because the harness is poorly configured for their specific task. This video emphasizes testing the full model-plus-harness combination rather than relying on benchmarks alone.

What are deterministic guardrails and why must they live outside the LLM?

Deterministic guardrails are hard constraints—such as security permission checks, API verification, and safety boundaries—that must be enforced by external code hooks rather than relying on the LLM to self-govern. LLMs are probabilistic and can be prompted or manipulated into bypassing safety instructions, making them unreliable as the sole enforcement layer for critical boundaries. This video argues that placing these guardrails in deterministic code ensures they cannot be overridden regardless of how the model's context is constructed.

Full transcript

[00:04] I'm Alex coming from Anthropic. Principal Architect for some of our strategic accounts. So, I'm responsible for bringing AI into the fold both internally to large tech companies, but also helping to enable their products with AI. So, clients of mine include Microsoft,
[00:16] Apple, ServiceNow, etc. I'm leading the charge as we as we go through the implementation integration across these customers. And today I want to talk to you all about some of the patterns that I'm seeing that we're seeing at Anthropic in terms
[00:29] of how people trying to increase the capacity of agents by going to multi-agent architectures. Throughout this topic, I want to make it very clear that, you know, there's a lot of buzz around using the newest tool, the biggest thing, you
[00:42] know, multi-agent is is what I see a lot of VPs saying, "We need an architecture to have these things." And I want to like just be very clear, it's not always the answer to bring more complicated tools to the fight, right? Sometimes it's like bringing, you know, a nuke to
[00:54] a knife fight when you're trying to do a very very simple task and you say, "Let me get multiple agents in there." And so, I want to kind of ground us a bit in how we at Anthropic are thinking about this, how customers are failing and succeeding, and some of the patterns
[01:06] that we think people can take away here from this. So, first just to settle on some vernacular, we talk a lot about model intelligence, right? We see evals come out, Opus 4.7 versus GPT 5.5, etc.
[01:18] Those are often, you know, model benchmarks. And so, it's become very clear to us at Anthropic that it's not the model alone we need to test, it is the model plus harness combination that is really the measure of how well these
[01:31] things can perform because the range of outputs you can get from a model really are dependent on the harness. I see times we will say, "Oh, this harness is a lot better than this one." Or "This one's performing super much better on
[01:43] SweBench or whatever it might be." And they go and implement with them and find it's just not following my task guidelines. It's doing it's kind of it's kind of derailing throughout the process of a long running task. When I hear those things and I see the benchmarks
[01:56] offer one way, but the results go a different way, it signals signals to me that it's often the way people are tapping into these models versus, you know, the models themselves. For a long back two years, it really was chat back
[02:09] and forth, right? I put an input in, that's the context and that's all, it responds back. Now, when we expect these models to pull in information from MCPs, from tools, from, you know, previous context, from other agents, etc., the
[02:21] way we pass that information, the formatting, the moment in time we do so, how we're actually getting it to you know, internalize all that context has massive impact in the quality of response. My philosophy whenever I talk
[02:33] to a customer we're going in to develop something new is to start with a single agent. I have so many people that say, oh, well, we've got these three different personas, we need to attack this problem and so we're going to have a multi-agent architecture and each one
[02:45] will have a different persona and they'll all work together and collaborate and by the end we'll have the output. And the problem with that is not that they're wrong, but that is that that that could be the correct way. It's that we're working now in AI
[02:59] in an infinitely dimensional complex space. We have to perfect our prompts, our tool descriptions, the way that our tools operate, the connectivity the connective tissue between these things,
[03:11] system prompts on top of that. And when you think about the language reason to describe these problems, the difference between, you know, put and place. I put something on the table, I place something on the table. Kind of meaningful impact on the way a prompt actually, you know, ends up running. And
[03:25] when you have that many variables, starting from even more of them with multiple agents is often the wrong way to approach the problem. So, my perspective is start with a single agent and understand your failure modes. Try and figure out what's not working with
[03:38] that agent before you head to developing and delivering more capabilities. The three things that tell me that we need to maybe invest in multi-agent architectures or adding complexity to the space. One, context delusion. If
[03:52] we're hitting a lot of compaction, we're losing specificity in our content. It might be a great opportunity to use a new architecture that may involve sub agents with their own context, multiple agents that share a central context,
[04:04] etc. Second one is specialization. And last one is really parallelization. I think this is just clear, that's really an optimization at the end. We don't often start by optimizing our software from day one. The same goes for agents, right? We want to see if we can get good
[04:17] output before we start to think about making it faster and more effective and efficient, right? Tangenting here for a moment, I think the same thing goes with I often tell people start with the strongest intelligence models, the Opus, you know,
[04:29] lines of the world. See if you can get good results and then tune down to the Sonics and the Haikus of the world to make sure that the task is even possible. Again, removing variables from the equation is a really, really
[04:41] important part of this process because there already are so many variables. I think it goes into the same type of thing like optimizing with parallelization. This kind of leads into how we start thinking about siloing different agents from that. I think that
[04:53] people start to think about problems. I want to solve this problem and that problem, which which I think makes sense in our faces as humans. We want to want to think about these problems step-by-step. These aren't These two concepts, concept context-centric versus
[05:05] problem-centric, are not at odds with each other, but I really want to focus on the one on the right there that you guys see context-centric. Separating the work with agents is really a task of making sure the the
[05:17] agents themselves are able to focus and provide attention, both, you know, literal attention, capital A attention in the the ML sense, but also just attention generally, to the right content. So, when you think about the work that you want to do, think about
[05:29] the context an agent needs to have and let that be the guide for whether or not you believe there's two very, very divisible pieces of context, three divisible pieces of context before you start to get multiple agents in the loop. The first one I want to start
[05:41] with, I'm going to walk through a couple of different models we're seeing as effective in different cases, is generator verify. This is a super simple one that I'm often advocating for in places where accuracy and absolute
[05:55] citation quality and and and data consistency is super key. So, a great example of this is um financial institutions. When they have an output that comes out from an Excel spreadsheet, and they want to make sure
[06:07] that content is valid and accurate, they may have one agent generate that content and a second one verify it. The first thing we do when when building this uh this this agent is again, start with a single agent, and at the end you can say
[06:20] final step in that skill, please verify your work and double-check that it's correct. This can work on simple cases, but we want absolute best-in-class accuracy. You can imagine that all the things that it did in its reasoning up to that point
[06:33] are part of the context of the verifier. The verifier is aware of all the steps that it took and all the confidence that it built in its answer. And that means that you've polluted the verifier's per-
[06:45] spective and biased it towards the fact that it may be correct. And so, separating context two separate context windows is a really really valuable thing in a generator verifier uh use case. This can exist in a loop. We can
[06:57] have the verifier send back content to the generator to then have a fresh context to work on the next iteration to make the fixes the verifier believes are valuable. We get convergence on accuracy and quality up to a point using this
[07:10] kind of model. Really helpful as well in long-running coding tasks where you have some sort of eval set or tests, etc., where you want to generate code and then have the outcome verified to see if it actually matches. Second one that's
[07:22] super common and you will already see built into products like Claude Code and others is orchestrator sub-agent. Uh there are often these tasks that are one-off tasks that you don't need to
[07:35] come dilute the orchestrator's uh context. So, you can imagine that in a in a search function, if you want to go and gather context from a lot of different sources, having one agent that
[07:47] is going to each one after another, not only is is inefficient because you are doing that in in serial, uh it's also filling the context linearly as it grows and grows and grows. At some point, if
[07:59] you find 100 different search results and they all go into the context window and you compact, you end up losing a lot of the specific information that lives in that context window. This is a great case for sub agents. Sub agents, it is not about
[08:13] saying your persona is this and your persona is that. Sub agents, the moment to really leverage them is when you need a fresh context window to do a scope task and do not care what happens afterwards. That is the best case
[08:26] scenario for a sub agent where you're creating fresh context, fresh window, and you are uh getting a result back that is very tangible and tractable for the orchestrator to work off. Search is a very great example of this because again, now we only have nine search
[08:39] results instead of 100 100 search results that come in. One thing I want to be clear about here though, some downsides. One, they're not aware of each other, so you don't have any cross context you know capabilities here. But two, um we also have uh
[08:52] questions around token efficiency and prompt ca- uh prompt caching. So, when you open up these new context windows, every new context window that has a new prefix to that conversation is going to uh end up having to reinfer the entire
[09:06] uh its entire stack and so you're going to have higher costs here for starting up sub agents. These are very similar, but you don't throw away the context on the workers. So, you can imagine that in agentic coding task, let's just say you're working on a client server
[09:19] implementation, and it makes sense to have an orchestrator who's figuring out what needs to happen next between new API endpoints and the client actually consuming them. You might want to have workers that actually retain their
[09:31] context. One is working on client, one is working on server, so they know what changes they've previously made and they can keep in context all the research they've done on the code base. Remember that these things are also composable, right? So, each one of these workers
[09:43] might have sub agents in the previous slide that's done to gather research and understand a code base in this example. And that's where agent teams come into play here. Shared state, I love this architecture for certain things. It's actually been super fun to use. This is
[09:56] one that I use a ton for exploration, uh when I want to create new ideas and to generate new creativity. The concept here is that we have different agents who can all read each other's shared
[10:08] file state from each other. Let's say develop I let's say we have a skill in house that I want to make effective for the next generation model. We've just gone from 46 to 47. What I might do is put the original skill in shared state
[10:21] and give all four of these agents a prompt saying, "I'd like you to come up with a creative idea to adapt this skill with 47, test it, and come back with your findings and put them in the shared state. Keep on doing that in a loop."
[10:34] And what happens is agent 1 2 3 and 4 will go off. They will go test their hypotheses, come back with their findings, and put them in the center. And in the next loop, they're now reading everyone's findings. This kind of feels to me very frontier for uh us
[10:49] as a lab, and I think for any company that's trying to understand how to go out and tackle something. People ask me all the time how Anthropic is delivering products so quickly, how we are iterating so fast, and kind of staying at the frontier of the things that we are. And
[11:02] I want to tell you a couple things. One, there is nothing we have in house that you guys don't have. I think people assume that we have some special tooling, and anything we do have in house that we do use was built in the exact same tools that we provide to the
[11:14] public. But the thing that we do do in droves, non-stop, is just say, "Let's try this." And we put agents to the task, we see what the output is, we see what the outcome is, we play with it. We don't we
[11:27] we're we call ourselves ants internally Anthropic. We're ants. We ant food everything, not dog food. We ant food everything. And we are so quick to jump to something like this and saying, "Hey, I think we should have a skill that can
[11:39] do this, but I'm not sure if we can system." Instead of talking about it, put it into this and say, "Hill climb it. How far can you get after a day? Are we able to see better results or not?" But the number one thing that has enabled us to move quickly is not
[11:52] understanding these architectures, cuz we're learning these at the same time you guys all are. All these things are concepts in our book that we're working on and learning. This is so, so new. We're all in this together, this new space. But the thing we are doing is
[12:04] just trying everything. We've got an entire channel called demos not memos. And it's all about just not writing what you're thinking. It's just go do the thing and show us. And if people like it, we continue on. If they don't, we don't. It is now more expensive to
[12:17] measure than it is to cut. It used to be that you could sit down and you could have meetings with, you know, product managers and engineers and leaders and say, "Let's put together a plan to put all this together." And it would take a
[12:29] couple weeks because you knew that the build would take a couple months. And if you did it wrong in the first bit, you'd have huge expense in change in those couple months. It is now so quick and so cost-effective
[12:41] to try things, those weeks of meetings are what are delaying a lot of implementations from happening. And I find with the customers that I work with, clients walking into an EVP's room with a demo of what you're thinking is a
[12:53] lot more powerful than saying, "I have an idea. Here's the PRD. Here's the spec. What do you think?" Like feeling it is just a lot more tangible. The last one I'll share, um, is is the message bus, um, which is really about, you
[13:05] know, kind of a pub-sub architecture. This is one where, uh, we may have multiple actors that need to, uh, react to information coming through some sort of a system. But a security implementation where you have signals
[13:18] that might be coming in. You might have certain agents that need to be, uh, that are being tagged for certain tasks to understand where to put them in triage, who to notify, etc. This is a really, really useful architecture for things where you have kind of an event loop
[13:30] that is occurring you want to respond to them. It is very, very hard to debug. My my uh recommendation here is test each agent on its own. Like think of each of these as its own bucket. Like
[13:43] we go back to that single agent, the triage agent, make sure it's working exactly as expected when you just send messages directly to it, and then start to think about if we should have multiple agents actually working on the same bus and listening to the same events and reacting. Because you might
[13:55] find they're actually responding to the same events. You don't actually need two agents. They both do the same thing and you can collapse them. I know I just talked a lot about kind of the specifics of these agents, and I want to just go back to uh some kind of broader concepts
[14:08] here. The simplicity tends to be king and queen in this in this world. When I'm working with uh these large enterprises, I'm finding all there are a lot of
[14:21] really creative engineering ideas to try to squeeze the most out of the models. And I appreciate people trying those things, but sometimes they skip the simplest thing first. And I'll give you an example, it's not really about
[14:33] multi-agent harnesses, but I had a customer who had a product that I'm sure all of you I have used or are familiar with, and um they were struggling when uh when uh the new 47 came out to adjust their prompts
[14:46] to make it work effectively. And we sat there and we kind of like added different components to their prompts, and we said, "Okay, it seems to be having this different type of uh uh characteristic. What if we prompt that out by kind of saying, 'Don't do that.'"
[14:58] We put a lot of exclamation points and capital letters and all that stuff that you guys have seen. And at the end of the day, what we realized was that there was a lot of bloat from previous prompts from previous generations. And what we did was just say, "Why don't we just delete the whole prompt and just see
[15:11] what happens from scratch? Just the input prompt for like do this thing that the user was putting in, not any of the guard railing." And it actually added two points to their evals just like that. And I think that like there is this idea that like we are complexity
[15:25] and specificity is useful, but as these models get smarter and smarter, we don't need to tell them to do as much. We can just kind of let them do their thing. I really implore all of you when you're thinking about either adjusting a system
[15:37] or building something new, start from the basics. Start from a clean slate, see what's not working, and use that as a direction for how you should end up kind of changing implementation going forward. As far as multi-agent
[15:49] architectures go, I think similarly, when you see the the limitations of what you're hitting, whether it's compaction, which might mean running you toward a sub-agent, whether it is, you know, that the agents are working, but shared
[16:01] context means they're actually taking multiple loops to actually get context from each other, and that means shared state could be useful, right? These indicators are what are going to drive your product, not a first sense of like, "Hey, this looks like the same problem.
[16:13] Let's throw that at it." Really, really, really start with that single-agent thing, because the simpler things are the things you can test faster. At Anthropic, the absolute name of the game is get someone to use it as quickly
[16:25] as possible. And the more complexity you add on in the beginning, the less likely you are to get there quickly. And it's okay if things don't work. I said earlier that we are living in an infinitely dimensional problem space.
[16:37] And that to me is like the defining concept of AI development compared to traditional developments. I spent 10 years, you know, writing software. I wrote assembly code at Intel as my first job. And like you better believe that
[16:49] stuff was deterministic, okay? 1 + 1 always equaled 2. Sometimes AI will say that 1 + 1 equals fish. If we prompt it hard enough, it will do that. And I think that like trying to navigate the debugging and iteration on this problem
[17:04] where you have so many levers to pull, model model class, model vendor, system prompt, input prompt, tool availability, tool descriptions, the agentic loop, you know, the actual implementation, whether it's GitHub Copilot SDK, Codex, Cloud
[17:17] Code, Agent SDK, etc. All these things you can't simply pick one out as like that's the thing I need to fix. And so, I think starting from the simple basics, trying to minimize the variables, and
[17:29] understanding that you can create controls by using one model to start, one agent to start, a specific harness, etc. Finding where the limits lie and using that to guide your implementations is the I don't want to say the best path, I want to say truly is the only
[17:41] path to go forward in this world because there simply is too much complexity otherwise.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.