One Model Cannot Be Everyone
Ask a single large language model to investigate a phishing alert, audit an AWS account, reverse-engineer a suspicious binary, and map the whole thing to SOC 2 controls, and you get a plausible-sounding answer to each — none of them as good as a specialist would give. The model has too much to hold in mind, too many tools it might reach for, and no clear boundary on what "done" looks like for any one job.
Human security teams solved this problem a long time ago. Nobody expects the malware reverse-engineer to also run the cloud posture review and write the board summary. They hire specialists and put a shift lead on top to route the work. A multi-agent architecture applies exactly that structure to AI: a set of focused agents, each with a narrow remit and a small toolset, coordinated by a router that decides who handles what.
This is the depth layer of an AI-native security platform. It is not where you start — a single well-built investigation agent and a conversational copilot deliver most of the early value. But it is what turns a capable platform into a genuinely capable one, and it is worth understanding before you architect the earlier layers so you don't paint yourself into a corner.
Why Specialists Beat One Generalist
Three things make a specialist agent better than a stretched generalist, and all three are practical rather than philosophical.
Focused context. A malware analyst agent is primed with the vocabulary, the reference material, and the reasoning patterns of that one job. Its system prompt, its retrieval sources, and its examples are all about files and behaviours — not divided across nine unrelated domains. When context is focused, the model spends its attention on the problem rather than on working out which of its many hats to wear.
Scoped tools. A generalist that can query the cloud API, run file-analysis sandboxes, read identity logs, and edit compliance records is a large attack surface and an unpredictable one. A specialist gets only the tools its job requires. The cloud agent can read AWS, Azure, and GCP configuration and nothing else. The identity agent can read directory and permission data and nothing else. This is the least-privilege principle from AI agent security applied per agent rather than per system: each agent is bounded, so a manipulated or malfunctioning agent can do less damage.
Easier to test and trust. You can write a meaningful test suite for an agent that does one thing. Feed the malware agent a known-benign file and a known-malicious one and check the verdicts. Feed the cloud agent an account with a deliberately public bucket and confirm it flags it. A generalist that does everything is far harder to pin down — its behaviour on any one task shifts as you tune it for another. Narrow agents are narrow enough to evaluate, which is what earns them the right to run with less human oversight over time.
The Agent Roster
Instead of one model, the platform runs a team. Each agent has a clear responsibility, a scoped set of tools, and a defined output. A coordinator sits above them and routes each incoming request to the right specialist.
| Agent | Responsibility | Typical tools (read-only unless noted) |
|---|---|---|
| Security Analyst | Investigates alerts and summarises findings | Log search, event timeline, enrichment lookups |
| Malware Analyst | Analyses suspicious files and behaviours | Sandbox detonation, hash reputation, static analysis |
| Cloud Security Agent | Reviews AWS, Azure and GCP configuration | Cloud config APIs, CSPM findings |
| Identity Agent | Detects permission abuse and identity risk | Directory reads, permission graphs, sign-in logs |
| Compliance Agent | Maps evidence to compliance controls | Control catalogues, evidence store, framework mappings |
| Threat Hunter | Searches for hidden attack patterns | Historical log queries, behavioural analytics |
| SOC Agent | Triages, prioritises and escalates incidents | Alert queue, severity scoring, escalation actions |
| Patch Advisor | Recommends the highest-impact updates | Vulnerability data, asset inventory, exploit intel |
| Executive Assistant | Produces business-friendly summaries | Read access to other agents' outputs only |
Two things are worth noticing about that table. First, almost every agent is read-only — the ones that can take action (the SOC agent escalating, a response playbook containing a host) are deliberately few, and their actions are bounded exactly as they would be for any production AI agent. Second, the Executive Assistant has no access to raw systems at all. It reads what the other agents have already produced and rewrites it for a non-technical audience. That separation matters: the agent talking to a CEO is architecturally incapable of touching the cloud account.
How the Coordinator Routes Work
The coordinator — sometimes called the router or orchestrator — is the piece that makes the roster behave like a team rather than a pile of disconnected tools. When a request arrives, whether from a detection firing or a human asking a question in the copilot, the coordinator has to decide three things: which specialist (or specialists) should handle it, in what order, and how to combine what they return.
In practice the coordinator is itself an LLM given a clear description of each agent's remit and a structured way to hand off. A question like "is this login suspicious?" routes to the Identity Agent. "What changed in our AWS account this week and does any of it break ISO 27001?" fans out to the Cloud Security Agent and the Compliance Agent, then combines their answers. A raw alert about an unfamiliar executable goes to the Malware Analyst first, and only if the verdict is bad does the SOC Agent get involved to triage and escalate.
The router does not need to be clever about the domain — it needs to be reliable about delegation. The most common failure mode is a coordinator that tries to answer the question itself instead of handing off, which quietly recreates the over-stretched generalist you were trying to avoid. A good implementation keeps the coordinator thin: its job is to dispatch and to assemble, not to investigate. Its outputs to the user are stitched together from specialist responses, each of which can be traced back to the agent that produced it — which is also what makes the whole system auditable.
How Agents Share Context Safely
Specialists are only useful if they can pass findings to each other, but shared context is exactly where multi-agent systems get dangerous. If every agent can read every other agent's memory and tools, you have rebuilt the broad, unpredictable generalist — just with more moving parts.
The discipline is to share results, not access. When the Cloud Security Agent finds an over-permissioned role, it hands the Identity Agent a structured finding — "role X can assume admin across three accounts" — not its own credentials or its own tool access. The Identity Agent acts on the finding through its own scoped tools. Context flows as data between agents; capability does not. This keeps least privilege intact even as agents collaborate, and it means a compromised or manipulated agent cannot borrow another's reach.
It also helps to give the shared context a defined shape. A common structured hand-off — an affected asset, a confidence level, supporting evidence, a suggested next agent — lets the coordinator assemble a coherent picture without any single agent needing the whole board. The same input-and-output discipline that protects any AI agent handling real systems applies here between agents: validate what comes in, constrain what goes out, and never let a hand-off smuggle in capability that the receiving agent wasn't meant to have.
The Added Complexity Is Real
None of this is free, and it would be dishonest to pretend otherwise. A multi-agent architecture is meaningfully harder to build and run than a single agent, and there are three costs you pay for the capability.
Latency. A question that fans out to three agents and waits for a coordinator to combine their answers takes longer than one model responding directly. Where a single investigation agent might answer in seconds, an orchestrated multi-agent flow can take noticeably longer for complex, multi-domain questions. For an overnight report this is irrelevant; for an interactive copilot query it needs care, often by running independent specialists in parallel rather than in sequence.
Orchestration complexity. Every agent is another prompt to maintain, another toolset to scope, another set of failure modes. The coordinator itself is a component that can misroute, loop, or stall. Debugging becomes "which agent went wrong, and did the coordinator hand off correctly?" rather than "what did the model say?" This is real engineering overhead, not a configuration toggle.
Cost. Multiple model calls per request cost more than one. A fanned-out query might invoke the coordinator plus three specialists — several times the token spend of a single answer. It is usually worth it for the quality gain on hard problems, but it means you route cheap questions to a single agent and reserve the full team for the ones that need it.
This is why multi-agent is a Phase 4 concern in a platform build, not a Phase 1 one. You get the detection engine, a solid investigation agent, and the copilot working over real data first. The multi-agent layer is what you add once the foundations are proven and the extra latency and cost buy you a real jump in capability — not before.
What Good Looks Like
A well-built multi-agent security layer has a few recognisable properties:
Each agent has a one-sentence job. If you cannot describe an agent's responsibility in a single clear sentence, it is doing too much and should be split.
Tools are scoped per agent, not shared globally. No agent has access it does not need for its specific remit, and the action-taking agents are few and bounded.
The coordinator delegates rather than answers. It routes and assembles; it does not investigate. Its outputs trace cleanly back to the specialists that produced them.
Agents share findings, not credentials. Context flows as structured data between agents; tool access never does.
Cheap questions skip the team. Simple queries hit a single agent; the full fan-out is reserved for genuinely multi-domain problems.
Every hand-off is logged. You can reconstruct which agent said what, in what order, and why — the same auditability you would demand of any agent touching production systems.
Questions to Ask
"What is each agent's exact remit and toolset?" You should get a list like the roster above — one job, one scoped set of tools per agent. If agents share a broad toolset, the specialisation is cosmetic.
"How does the coordinator decide who handles a request?" A good answer describes explicit routing logic and a thin coordinator that delegates. If the coordinator is doing the reasoning itself, you have a generalist wearing a costume.
"How do agents pass information without passing access?" The answer should be structured findings, not shared credentials or shared tools. This is the difference between safe collaboration and a rebuilt monolith.
"When does a query use one agent versus the whole team?" There should be a deliberate answer, because routing everything through the full fan-out is slow and expensive for no benefit.
"Where in the roadmap does this sit?" If a team proposes building nine agents and a coordinator before the single investigation agent works, that is a sequencing red flag. Depth comes last.
What It Costs and How Long It Takes
Be realistic about where this fits. A multi-agent layer is not a first engagement — it is what you build on top of a platform whose earlier modules already work. Standing up a coordinator and an initial set of three or four well-scoped specialist agents, with proper routing and structured hand-offs, is typically a multi-week effort for a small team that already has the underlying tools and data in place. Building out the full roster of nine specialists, tuning the coordinator, and getting the latency and cost profile right is a phased effort measured in months, not weeks.
The reason it lands late in the roadmap is that most of the cost is only justified once you have hard, multi-domain problems to throw at it. If your platform's questions are mostly single-domain — "is this login suspicious?", "which patches matter?" — a single well-built agent per domain answers them faster and cheaper. The multi-agent architecture earns its keep when questions genuinely cross domains and when the quality gain from a coordinated team of specialists outweighs the added latency, orchestration burden, and per-query cost. Building it before that point is engineering for a problem you do not yet have.
Related guides
- Building an AI-native security operations platform: the complete architecture
- The AI security investigation agent: auto-gathering evidence
- The AI security copilot: natural-language queries over your data
- Building the detection engine
- AI agent security: what business owners need to know
- Our LLM integration services
We Build the Depth Layer Once the Foundations Are Solid
A multi-agent architecture is the kind of system we enjoy building — but only in the right order. We would start by getting your detection, investigation, and copilot layers working over real data, then add the specialist roster and coordinator once there are genuine multi-domain problems worth the extra complexity. Done the other way round, you pay for orchestration you cannot yet use.
If you are weighing whether a multi-agent layer belongs in your platform, or where it should sit in your roadmap, we are happy to walk through the trade-offs for your specific case — including the cases where a single well-scoped agent is the better answer.
Talk to us about your platform — no commitment, just a conversation.
Frequently Asked Questions
What is a multi-agent architecture in security operations?
It is an approach where, instead of one large language model handling every security task, the platform runs a team of specialist agents — a malware analyst, a cloud security agent, an identity agent, a compliance agent, and so on — each with a narrow remit and a scoped set of tools. A coordinator agent sits on top and routes each request to the right specialist, then combines their outputs into one response. The structure mirrors how a human security team is organised, with specialists and a shift lead.
Why not just use one powerful model for everything?
A single model asked to do everything holds too much in context, has too many tools it might reach for, and no clear definition of "done" for any one job — so it produces plausible but mediocre answers across the board. Specialists win on three counts: focused context (the model spends its attention on one domain), scoped tools (a smaller, safer attack surface per agent), and testability (an agent that does one thing can actually be evaluated). Narrow agents are easier to trust because they are easy enough to verify.
How does the coordinator agent decide which specialist to use?
The coordinator is typically an LLM given a clear description of each agent's remit and a structured way to hand off work. When a request arrives, it decides which specialist or specialists should handle it, in what order, and how to combine the results. A good coordinator stays thin — its job is to dispatch and assemble, not to investigate. The most common failure is a coordinator that answers questions itself instead of delegating, which quietly recreates the over-stretched generalist you were trying to avoid.
How do the agents share information without creating security risks?
The discipline is to share results, not access. When one agent finds something, it hands the next agent a structured finding — an affected asset, a confidence level, supporting evidence — rather than its own credentials or tools. The receiving agent acts through its own scoped tools. Context flows as data; capability does not. This keeps least privilege intact even as agents collaborate, so a compromised or manipulated agent cannot borrow another's reach.
What are the downsides of a multi-agent approach?
Three real costs. Latency: a query that fans out to several agents and waits for a coordinator to combine answers is slower than one model responding directly. Orchestration complexity: every agent is another prompt, toolset, and set of failure modes, and the coordinator itself can misroute or stall. Cost: multiple model calls per request cost more than one. These trade-offs are why you route simple questions to a single agent and reserve the full team for genuinely multi-domain problems.
When should we build the multi-agent layer in our platform roadmap?
Last. It is a Phase 4 concern, not a starting point. You build data collection, processing, the detection engine, a solid investigation agent, and the copilot over real data first — those deliver most of the early value. The multi-agent layer is what you add once the foundations are proven and you have hard, multi-domain problems whose quality gain justifies the extra latency, complexity, and cost. Building nine agents and a coordinator before the single investigation agent works is a sequencing mistake.