Retrieval First, Answer Second: Grounded AI for Network Operators

There is a specific kind of danger that shows up the moment you point a general-purpose language model at a network problem. Ask a cloud chatbot why BGP is flapping on a core router and it will answer — fluently, immediately, and with total confidence — whether or not it has ever seen your topology, your configuration baselines, or the session logs from the box that's actually misbehaving. It will invent a plausible cause. It will suggest a command. And at 2 a.m., with a circuit down and a maintenance window closing, a plausible-but-wrong answer delivered with confidence is not a help. It's a liability wearing the costume of one.

The problem isn't that the model is stupid. It's that it's ungrounded. It's reasoning from the statistical shape of a million network forum posts instead of from the one network in front of you. For casual questions that gap is invisible. For operational troubleshooting — where the right answer depends entirely on this device, this config, and this fault — it's the whole game. That gap between a model that sounds right and a model that is grounded in your evidence is exactly the line DRAGON is built along.

The hallucination tax is highest exactly where AI looks most useful

Network operations is a near-worst-case environment for an ungrounded model, and it's worth being precise about why.

First, the cost of a wrong action is asymmetric and immediate. A hallucinated no in front of the wrong config line doesn't produce a bad paragraph you can shrug off — it drops a session, black-holes a prefix, or takes down the management plane you were reaching the box through. Second, the correct answer is almost never general. "Why is this interface dropping frames" has a real answer that lives in the interface counters, the running config, the vendor's actual behavior on that platform, and what changed in the last maintenance window — not in the aggregate of everything ever written about interface drops. Third, the environments where operators most need help are frequently the ones a cloud model can't legally or physically reach: classified networks, air-gapped labs, an austere site with no uplink, a hospital core in the middle of a migration where the data is regulated and egress is simply not on the table.

So the naïve pitch — "put a chatbot on it" — inverts exactly where it should. The situations with the highest stakes and the least tolerance for a confident guess are the situations a general cloud model handles worst. DRAGON's design starts by taking that seriously.

Retrieval first, answer second. The order is the architecture, not a slogan — a model that reaches for your evidence before it reaches for its own fluency is a fundamentally different tool.

Grounded means the answer traces back to your evidence

The core commitment is retrieval-augmented generation, but the emphasis matters: retrieval first, then answer. Before DRAGON generates anything, it retrieves from your own material — your documentation, your configuration baselines, and the session history from the gear you're actually working on. The answer is composed from that retrieved evidence, not from the model's open-internet priors. When you ask why BGP is flapping on core-01, a grounded copilot's job is to pull the relevant config, the recent session output, and the baseline you captured when the box was healthy — and reason over those, so the response is anchored to the device in front of you rather than to the average of every BGP thread ever posted.

That single ordering decision changes the failure mode in a way that matters operationally. An ungrounded model's natural failure is to confabulate — to fill a gap with a fluent invention. A retrieval-grounded model's natural failure is to come back with "I don't have evidence for that," which, at 2 a.m., is dramatically the safer failure. The first sends you chasing a cause that never existed. The second tells you the truth: the answer isn't in what I can see, go look wider. Operators can work with the second. The first is how you lose an hour and a maintenance window.

There's a deeper reason grounding is the right primitive for infrastructure specifically. The knowledge that resolves a real incident is local and current — it's the config as it exists tonight, the log line from this session, the baseline from last week. That information was never in any model's training set and never will be. Grounding it through retrieval is the only mechanism that puts the one thing that actually answers the question into the model's context at the moment it answers.

On the operator's machine, off the grid

Grounding solves what the model reasons over. It does nothing about where the reasoning happens — and for the environments network operators actually work in, that second question is just as load-bearing.

DRAGON runs the model locally, on the operator's own machine. No cloud, no telemetry, no egress. It is fully functional disconnected — a standalone installer supports air-gapped deployment with no external dependencies, and it meets the gear where it lives: over SSH or a serial console, on Windows, macOS, or Linux. When DRAGON establishes a session, the banner is blunt about it: uplink none, egress blocked. Nothing leaves the room.

For a large swath of the people who most need an operator copilot, this isn't a privacy nicety — it's the entry ticket:

• Classified and defense networks where a cloud round-trip is a non-starter by policy, full stop.
• Air-gapped labs and test ranges that have no uplink by design, and where introducing one to service a chatbot would defeat the purpose of the enclave.
• Regulated environments — a hospital core mid-migration, a utility's OT network — where the configs and session data are sensitive and "we send it to a vendor's model to analyze" is not an answer a compliance officer accepts.
• Austere and expeditionary sites where there simply is no reliable link home, and a tool that degrades to uselessness without connectivity is dead weight.

A cloud copilot's entire value proposition assumes a fast, always-available link to someone else's datacenter. Every one of the environments above violates that assumption. Local inference isn't a downgrade of the cloud experience — for these operators it's the only version of the experience that can exist at all.

Secrets stripped at the boundary

Local inference dramatically shrinks the exposure surface, but "the model runs on your machine" is not by itself a complete answer to the secrets problem. Operator sessions are full of credentials, keys, community strings, and tokens, and you don't want those flowing into a model's context even locally — because context can end up in logs, in caches, in an exported session. So DRAGON strips them at the boundary.

Credentials, keys, and secrets are removed before anything reaches the model, and — this is the part that separates a real control from a checkbox — the redaction is enforced by a regression-tested engine. That phrasing is deliberate and it matters technically. Redaction is exactly the kind of security control that rots silently: a new device type emits secrets in a format the regex didn't anticipate, and you don't find out until one leaks. Pinning the redaction behavior under a regression test suite means the boundary's guarantees are verified as the tool evolves, not assumed and quietly eroded. The secret-stripping is a tested property of the system, not a hopeful feature.

The operator stays in command

The last piece is the one that most cleanly separates a copilot from an autopilot, and it's a philosophy choice as much as an engineering one. DRAGON suggests; it does not act.

It will track a fault to a root cause, propose the remediation, and stage an action — but running that action is the operator's decision, reviewed and approved, every time. It never touches a system on its own. That constraint is doing real work in an operational setting. The failure modes of autonomous action on production infrastructure are catastrophic and irreversible on exactly the timescale — seconds — where a human's veto is the only reliable safeguard. Keeping the operator in the loop isn't a lack of ambition; it's the correct amount of ambition for a system that can reach the enable prompt.

And because every session, retrieval, and model call is written to a tamper-evident, hash-chained audit log you can export, the record of what the copilot read and suggested is reconstructable after the fact. When an accreditor asks what the tool saw before it recommended a change, the log answers — down to which files, at which millisecond. Accountability is the default state, not an add-on you remember to switch on.

Put the four properties in one line and the shape of the tool is obvious: it runs locally, reasons only from grounded evidence, strips secrets at the boundary, and leaves the operator in command. Each one closes a specific hole that a general cloud chatbot leaves wide open.

What this looks like at 2 a.m.

Return to the flapping BGP session, and walk the two tools side by side. The ungrounded cloud model answers instantly from nothing in particular, names a cause it can't substantiate, and suggests a command you now have to second-guess under time pressure — with your config and session data having just traveled to someone else's server to get there.

operator> why is bgp flapping on core-01?

grounded · local:
  retrieving…  config(core-01), session log(core-01), baseline(core-01)
  → neighbor 10.0.0.2 resetting on hold-timer expiry; last-flap 14:29:57
  → suggested (staged, awaiting approval): show ip bgp neighbors 10.0.0.2

DRAGON does the opposite. It retrieves the config, the live session output, and the healthy baseline for that specific box; it reasons over that evidence; and if the evidence doesn't support a conclusion, it says so rather than inventing one. It stages a diagnostic for you to approve. Nothing left the room, no secret reached the model, and there's a hash-chained record of every step. The difference isn't that one tool is smarter. It's that one is grounded, contained, and accountable and the other is confidently guessing with your data on the wire.

The takeaway

The instinct to put a language model in front of a hard operational problem is the right instinct — the models really are useful. The mistake is deploying the ungrounded, cloud-hosted, act-on-its-own version into an environment that punishes every one of those properties. Network operations rewards the opposite stance at every turn: retrieve before you answer, run on the operator's own machine, strip the secrets at the door, and let a human make the call. That's the stance DRAGON is built from, and it's why it's currently in limited commercial release with a first group of operators rather than shipped to our warfighters as a demo that impresses in the conference room and fails in the enclave.

It's the same principle that runs through our ML integrations work more broadly — open-weight models deployed inside your perimeter, air-gapped if needed, so full inference stays fully private — and through the network infrastructure we build for the environments where that discretion isn't optional. If your operators work somewhere a cloud chatbot can't follow, and you want AI that answers from your evidence instead of its imagination, that's the