“Agent-native” without the marketing
“Agent-native” has become a marketing phrase in 2026 — every SaaS product wants the label. Most deserve the skepticism that comes with it. Here is what we mean by the term, specifically and architecturally.
1. Orchestrator + atomic tools, not chat-over-a-form
An agent-native system has two layers. The orchestrator is an LLM that plans. The tools are deterministic functions that execute. The orchestrator decides which tools to run; the tools return structured results.
This matters because a “chat over a form” product is brittle by design — the model has to both judge and execute, which means the same prompt can produce different outputs and you can't test the execution in isolation.
In an orchestrator + tools architecture, every numeric value in your CCR comes from a tool you can unit-test. Unit normalization is a function. 90th-percentile calculation is a function. MCL comparison is a function. The LLM judges which tool to call, but the tool itself is deterministic.
2. Provenance per value
Every contaminant value in a published CCR links back to its source — the lab PDF, the page, the row, the extracted text. This is not a compliance nice-to-have; it's an architectural requirement. A value without provenance does not reach the page.
This breaks most chat-over-a-form tools immediately: when the LLM is doing the extraction inline, you can't guarantee the link from value to source, because the model may paraphrase or interpolate. An agent with explicit extraction tools gives you structured output you can trace.
3. Tool parity: API === UI === TUI
Every action an operator can take in our dashboard — draft a section, normalize samples, run a compliance check — is an explicit tool the agent can call. The same tool is exposed via API, via TUI, and via UI. No dashboard-only features, no API-only features.
This is why the agent can drive the dashboard: it's calling the same tools your team calls. When the agent does something, the audit trail shows the tool invocation, with arguments and result — just like a human-initiated action.
4. The rule is source of truth, not training data
40 CFR 141 Subpart O lives at a stable URL on eCFR. We load it from the eCFR JSON API at build time, store the snapshot, and reproduce required verbatim blocks byte-exact. The LLM never generates regulation text.
This is the piece most compliance products skip. Training a model on regulation text lets it drift silently; using a cached JSON snapshot is verifiable. We'd rather be boring and correct than impressive and wrong.
Why this matters for operators
Three practical consequences:
- You can trust the math. The tools are pure functions, unit-tested, and callable independently. Your state reviewer can ask to see the calculation behind any number and we can show them.
- You can switch if we disappoint you. Tool-level portability means your data lives in a structured format you can export. You're not locked into a proprietary CCR format.
- You can audit the agent. Every LLM call, every tool invocation, every decision gets logged to an append-only event stream with 5-year retention.
Why it takes a whole product to get this right
Building these primitives is the unglamorous work. Lab-PDF extraction with cell-level provenance is months of work on edge cases. Unit normalization that handles every known lab format is months more. 90th-percentile calculation per § 141.80(c)(3) is three lines of code — and nine months of argument about whether the state reviewer will accept it.
The agent is the easy part. The tools are the product.
Where to go from here
- Start a free 60-day trial and watch the agent call its tools in real time.
- Read the CCR guide if you're ramping up on 40 CFR 141 Subpart O.
- Open the regulatory hub to see the verbatim eCFR snapshot.