Intelligence Operations: Localized Multi-Agent Systems for Government Agencies

Multi-agent architectures have become the default way to structure serious analytic work with large language models. Instead of one model doing everything, a task gets decomposed across specialized agents: one that plans, several that retrieve and cross-reference source material, one that drafts, one that critiques the draft against the sources, one that formats the output to a required product standard. Each agent has a narrower job, a smaller context window to reason over, and a role that can be evaluated and tuned somewhat independently of the others. For intelligence and analytic work inside a government agency, that architecture is genuinely well suited to the task, because finished-intelligence production already looks like a pipeline of narrower analytic steps performed by different people. The problem is that almost every publicly available multi-agent framework and every commercial agent platform assumes it can call out to a hosted model, a hosted vector store, or a hosted orchestration service somewhere on the internet. For a workload touching classified reporting, sensitive sourcing, or material that simply cannot leave a controlled facility, that assumption disqualifies the entire category before the architecture question is even reached.

The agent count problem, restated for a sealed boundary

A single-model, single-call inference pattern has one clear boundary to secure: the prompt goes in, a response comes out, and if that round trip stays inside the perimeter, the workload is contained. A multi-agent pipeline multiplies that boundary problem by the number of agents and the number of handoffs between them. A planning agent's output becomes a retrieval agent's input. A retrieval agent's output, which may itself contain excerpts of sensitive source material, becomes a drafting agent's input. A drafting agent's output becomes a critique agent's input. Every one of those handoffs is a place where, in a cloud-hosted agent framework, data could plausibly cross a network boundary, get logged by a third-party orchestration layer, or land in a hosted vector database that the agency does not control. None of that is hypothetical carelessness on the part of framework vendors. It's simply how those frameworks are built, because they were built for a market where none of the data involved was sensitive.

Running that same architecture on a sealed appliance means every agent, every intermediate handoff, and every piece of retrieved context stays inside one enclosure with no path out. That's a meaningfully different design target than "deploy the same framework on infrastructure the agency happens to own," because most of those frameworks still expect network reachability to a hosted control plane for orchestration, telemetry, or model routing even when the inference itself is self-hosted. A genuinely sealed multi-agent system has to bring its own orchestration layer inside the boundary too. The thing coordinating which agent runs next, what each agent is allowed to see, and how results get assembled has to be as air-gapped as the models it's coordinating.

Why the pipeline shape matters more than the model choice

It's tempting to treat multi-agent intelligence work as primarily a model-selection problem: which model plans best, which model drafts best. In practice, the harder and more consequential design work is the pipeline shape, what each agent is allowed to read, what it's allowed to pass forward, and where a human analyst has to sit in the loop before anything moves to the next stage. An agent tasked with cross-referencing source reporting doesn't need, and arguably shouldn't have, unrestricted access to every corpus on the system. Narrowing what each agent can retrieve is both a security property and a quality property, since an agent reasoning over a tightly scoped, relevant corpus produces more defensible output than one drowning in everything available.

This is where the retrieval and memory layer underneath the agents does as much work as the agents' prompts. A retrieval system that can enforce compartmentation, so that an agent's queries only ever surface material it's cleared and scoped to see, turns "multi-agent pipeline" from a convenience architecture into something closer to a governed analytic workflow. Get that layer wrong and a multi-agent system becomes a faster way to leak scope creep across compartments. Get it right and the pipeline's agent boundaries mirror the compartmentation boundaries an agency already enforces among its human analysts.

Provenance has to survive the handoffs

Finished intelligence products live and die on sourcing. An assessment that can't be traced back to what it was based on isn't usable, no matter how fluent the language. That requirement does not relax just because a machine produced an intermediate draft. If anything it tightens, because a human reviewer now has to be able to verify not just the final output but the chain of retrieval and reasoning that produced it. A multi-agent pipeline that treats provenance as a nice-to-have, logged loosely if at all, produces output that an analyst has to independently re-verify from scratch anyway, at which point the pipeline has added latency without adding trust.

Designing for this means the system has to carry citations and retrieval context through every handoff, not just attach them to the final draft as an afterthought. When a critique agent flags a claim as unsupported, it needs to be able to point at exactly which retrieval step produced that claim and what source material was or wasn't behind it. That's an architectural commitment. It shapes how agents pass state to each other, not just a formatting choice applied at the end of the pipeline.

Auditability as a first-class requirement, not an add-on

Outside a sealed government context, most multi-agent frameworks treat logging as an operational convenience: useful for debugging, occasionally useful for cost tracking. Inside an intelligence workflow, the equivalent record is the thing that lets an inspector general, an oversight body, or an internal review reconstruct exactly what happened: which agent took which action, on what input, producing what output, at what time. That record has to be complete enough to answer "why did the system produce this assessment" months after the fact, and it has to live entirely inside the sealed boundary along with everything else, because an audit trail that phones home to a vendor's hosted logging service defeats the purpose of sealing the workload in the first place.

This pushes multi-agent system design toward treating the orchestration layer itself as an auditable component, with its own integrity guarantees, rather than as disposable glue code sitting on top of the "real" system, which is usually how it gets treated in commercial agent tooling built for lower-stakes use cases.

Where this sits inside Czar

A sealed, self-hosted environment for building and running this kind of pipeline is squarely R&D and fine-tuning territory, not a fixed inference appliance running a single pre-baked workflow. Agencies building analytic multi-agent systems need to iterate: tuning retrieval scoping, adjusting which agent handles which step, refining prompts against real analytic products, and fine-tuning component models against the agency's own reporting style and terminology, all against genuinely sensitive source material that cannot touch a cloud environment at any stage of that iteration. That's the sandbox Czar is built to provide: sovereign compute for training, fine-tuning, and R&D work on sensitive data, sealed end to end, with the Substrate platform underneath handling the compartmented retrieval, provenance tracking, and governed connectivity that a multi-agent intelligence pipeline depends on to be trustworthy rather than merely fast. The architecture question, how many agents, what each one sees, how handoffs get audited, is where the real engineering work happens, and none of it is answerable generically. It has to be worked out against the agency's actual compartments, actual products, and actual review process, inside a boundary built to hold all of it.