Yes. CHARLIE runs retrieval, task decomposition, structured memory, and verification entirely inside institutional infrastructure with no cloud LLM API calls, which is the core requirement the paper sets out to meet (arXiv:2607.05428; DOI). Posted to arXiv on July 1, 2026 as the archival version of a workshop paper, it is the first documented multi-agent retrieval-augmented generation system built specifically for evidential reasoning in forensic science under chain-of-custody and data-sovereignty constraints.
What is CHARLIE, and why does forensics need it?
CHARLIE is an on-premise, multi-agent retrieval-augmented generation system purpose-built for digital forensics, where evidential reasoning must happen under strict traceability, confidentiality, and legal-compliance rules. The problem it targets is structural: forensic workflows handle “large volumes of heterogeneous and unstructured documents” under conditions that make the default cloud-RAG approach, sending the text through a third-party API, a non-starter (arXiv:2607.05428). Every egress is a potential break in chain of custody and a data-sovereignty question a defense attorney can raise in court.
So the design constraint runs the other way. Rather than asking which vendor is compliant enough, CHARLIE keeps the entire pipeline on institutional infrastructure. The paper frames this as preserving “data sovereignty and evidential integrity,” which in a forensic context is not a nice-to-have but the precondition for the output being usable as evidence at all. The system was presented at RELAF 2026, the 1st Workshop on Reasoning with Evidence in Law Enforcement and Forensics, co-located with ICAIL 2026 in Singapore in June 2026, with the archival version posted to arXiv on July 1, 2026 (10 pages, 1 figure).
How does the architecture keep retrieval and reasoning local?
The architecture combines four components: local retrieval, task decomposition, structured memory, and verification mechanisms, orchestrated by what the paper calls a “controlled agent architecture” representing a transition “from classical RAG to agent-based orchestration” (arXiv:2607.05428). Each component runs on-premise; nothing in the described pipeline calls out to a hosted model API.
The “controlled” qualifier matters more than it first appears. This is not a fully autonomous agent loop given free rein over sensitive evidence. Task decomposition splits an evidential query into subtasks, local retrieval pulls relevant passages from the institutional corpus, structured memory holds intermediate state across documents, and verification mechanisms sit on top. The case studies describe this enabling “scalable multi-document data extraction” and “longitudinal forensic intelligence generation,” meaning the system targets investigations that span many documents and long time horizons rather than single-query lookups.
What the abstract does not specify is how the verification mechanisms actually work. That gap matters enough to flag separately, because in a forensic pipeline the difference between an LLM-based consistency check and a formal, reproducible verification step is the difference between an agent’s answer being corroborated and being defensible in court.
What does air-gapped operation actually cost?
Here the paper is mostly silent, and that silence is the most important thing to say about cost. The abstract reports no performance benchmarks, no GPU requirements, no latency figures, and no head-to-head comparison with cloud-based RAG. Any concrete GPU-versus-API-cost comparison is therefore operational reasoning, not a reported result.
The tradeoff is still real and worth naming without numbers. In a cloud RAG deployment, the dominant cost is compliance: data-processing agreements, jurisdictional checks, contractual limits on retention and training use, and the standing risk that evidence leaves the institution. Move the stack on-premise and that entire class of cost disappears. What replaces it is operational: you provision and keep warm enough GPU capacity to run the retrieval and reasoning models, you staff the hosting, and you carry the reliability burden a managed API previously absorbed. The bottleneck moves from legal and contractual risk to hardware capacity and operational load. The paper quantifies neither side, which limits how far anyone can take the cost argument today.
How does chain-of-custody survive agent orchestration?
The paper claims CHARLIE “maintains traceability and auditability” across multi-document extraction and longitudinal intelligence generation, but treats the audit mechanism at the architecture level rather than specifying the log format, integrity model, or how individual retrieval steps are recorded (arXiv:2607.05428).
That matters because agents add nondeterminism in exactly the places chain-of-custody is fragile. Task decomposition creates branches; each retrieval is a decision about what evidence the agent considered; verification steps add another layer of model output. If none of that is logged with the rigor evidence handling demands, the agent’s answer is only as trustworthy as its least-recorded step. The structured-memory and verification-mechanism components are what the paper offers against this risk, but the abstract leaves their internals unspecified.
This is the crux of the operational tradeoff. Self-hosting removes the data-egress problem but transfers the cost of trusting an agent’s evidentiary chain onto your own audit logging. The institution now owns the integrity of every retrieval, decomposition, and verification step, because there is no vendor to point at and no external system of record.
How does it compare to cloud-based multi-agent RAG?
Most production multi-agent RAG tooling, frameworks such as LangChain, AutoGen, and CrewAI, defaults to routing model calls through hosted APIs and is optimized around latency and cost. CHARLIE inverts the priority order: it treats air-gapped operation and chain-of-custody as the primary design constraints and lets performance fall where it may. Whether that tradeoff is acceptable depends entirely on whether your evidence can leave the building, which for the intended users it cannot.
The contrast is architectural rather than a benchmark, since the paper reports no head-to-head numbers. The useful comparison runs along operational dimensions:
| Dimension | Cloud-based multi-agent RAG | CHARLIE (on-premise) |
|---|---|---|
| Model hosting | Third-party API | Institutional infrastructure |
| Data egress | Required | None |
| Data sovereignty | Contract-dependent | Preserved by design |
| Primary optimization | Latency, cost | Traceability, auditability |
| Audit posture | Vendor-mediated | Self-owned, evidence-grade |
None of the cells above are paper-reported metrics; they are characteristics that follow directly from the abstract’s description of where CHARLIE runs and what it optimizes for. The contribution is not beating cloud RAG on speed. It is showing the agentic-RAG pattern is tractable without the cloud at all.
What does this mean for legal, healthcare, and government teams?
For regulated industries that cloud-only agent platforms have effectively locked out, CHARLIE’s existence is a proof point: agentic RAG can run entirely inside institutional infrastructure with evidential-grade audit trails, which lowers the barrier from “is it even legal to send this through an API” to “do we have the GPU capacity and can we log every retrieval step” (arXiv:2607.05428).
That is a genuine lowering of the barrier for legal, healthcare, and government teams whose data cannot cross a vendor boundary. It is also directional rather than deployment-ready. The paper describes “real-world forensic scenarios” in its case studies but does not specify them, so how directly the blueprint transfers to a hospital’s clinical-evidence corpus or a government intelligence backlog is an open question the abstract does not resolve.
It is not an isolated pattern, either. Specialized multi-agent systems are appearing in other regulated, high-stakes infrastructure settings; Onnes, for example, applies multi-agent LLM operation to cryogenic fault diagnosis in quantum-computing infrastructure (arXiv:2607.05805). The shared shape is a domain-specific agent stack that cannot offload its reasoning to a general-purpose cloud API, which suggests the air-gapped agentic-RAG category is broader than one forensic system.
What is missing from the blueprint?
The paper describes CHARLIE as “a practical and reproducible blueprint,” but the abstract-level evidence leaves several operational questions open (arXiv:2607.05428).
The gaps are concrete. No performance benchmarks or latency figures are reported. No GPU or hardware requirements are specified. There is no comparison against cloud-based RAG on any axis. The verification mechanisms are named as a core component but not technically detailed. The “real-world forensic scenarios” in the case studies are unspecified, which makes the breadth of validation hard to judge. And there is no indication in the abstract of published code or implementation artifacts, so “reproducible” currently reads as a claim about documentation rather than an artifact a team can clone and run.
The honest reading is that the contribution is the architectural pattern plus a demonstration that it is tractable on-premise, not a turnkey product. Any team adopting it inherits the work the paper did not do: sizing the hardware, defining an audit-log format to an evidence standard, and making the verification mechanisms concrete enough to survive scrutiny. The value of CHARLIE is that it makes that work the remaining work rather than an unsolved research question. Whether the blueprint holds up under adversarial evidentiary challenge is exactly what the unspecified case studies and missing benchmarks leave unanswered.
Frequently Asked Questions
Does CHARLIE’s air-gapped design apply only to forensics?
No. Onnes applies multi-agent LLMs to cryogenic fault diagnosis in quantum-computing infrastructure (arXiv:2607.05805), and other papers from the same July 2026 arXiv cluster extend multi-agent reasoning to dairy-farm battery management (arXiv:2607.06489) and human-AI curiosity ecosystems (arXiv:2607.06214). CHARLIE is unique in optimizing for forensic chain of custody, but the broader signal is domain-specific agent stacks that treat cloud API offload as unacceptable, a pattern that also fits clinical evidence review and classified intelligence backlogs.
How is CHARLIE different from cloud-first agent frameworks like LangChain or CrewAI?
Cloud frameworks and recent papers such as Decision Protocols in Multi-Agent LLM Conversations and Task Decomposition-Guided Reranking optimize how agents converse and retrieve skills, not where the data resides. CHARLIE ignores that optimization axis and hardcodes locality and auditability as constraints. Its contribution is not a better protocol but a proof that agentic RAG can run when every retrieval step must be defensible in court.
What would a team actually have to log to make an on-prem multi-agent RAG evidence-grade?
Teams would need tamper-evident logs covering every decomposition decision, retrieval query, returned chunk identifier, model version, timestamp, and verification output, each tied to an operator or custodian. The abstract does not specify a format, yet forensic chain-of-custody standards require that no step can be altered undetected. That logging burden shifts from vendor SLA to internal infrastructure and becomes the dominant cost once GPU hosting is solved.
What is the weakest point if verification is itself model-based?
If verification is another LLM consistency check, it cannot independently corroborate evidence because it inherits the same hallucination and prompt-sensitivity risks as the generator. A court-ready system would need rule-based cross-references, direct source quotations, or formal reproducible checks. The paper names verification as a component but does not say which of those it uses, so the defensibility of the whole chain rests on an unspecified detail.
What development could make CHARLIE’s tradeoff look less attractive?
A sovereign-cloud or confidential-computing offering that keeps data inside a contractual enclave while supplying GPU capacity elastically could shift the bottleneck back to vendor audit agreements. Alternatively, case law that accepts vendor-mediated logs as sufficient chain-of-custody would reduce the premium on self-hosting. Until either happens, the operational burden of warm on-prem GPUs and internal audit logging remains the price of data sovereignty.
