Why agentic document AI needs a transparent router

Every document-AI vendor will tell you their system is agentic now. It reasons, it plans, it adapts. What almost none of them will tell you is which model ran on your document, why it was chosen, and what confidence the system had when it returned an answer.

That omission is not accidental. It is architecturally convenient. A black box requires no explanation. But in production, the absence of an explanation is exactly the problem.

What production actually looks like

A team at a clinical-data platform runs 800 ASCO oncology guidelines through their document pipeline every quarter. The pipeline converts PDFs to structured JSON, which feeds a retrieval system their oncologists query during tumor-board reviews.

One quarter, a batch returns garbled tables. The cells are transposed — rows where columns should be, columns where rows should be. The oncologists catch it because they know what a standard-of-care table looks like. The platform engineers do not immediately know what caused it.

With a black-box API, their debugging options are: re-submit the document (cost), try a different provider (more cost), file a support ticket (days), or accept that this class of document will occasionally produce bad output (risk). None of those options answer the actual question: why did the model transpose the table on page 47?

The routing decision is upstream of the output

In a multi-model document-parsing system, output quality is determined before the model runs — at the routing step, the decision about which tier and which provider should handle this particular page.

A page with a complex nested table, rotated header, and merged cells has a high complexity score. A Fast-tier model that costs $0.003/page will produce worse output on it than an Expert-tier model that costs $0.012/page. Routing the complex page to the wrong tier is the root cause of the garbled table — not a fundamental model failure.

If you cannot see the routing decision, you cannot diagnose the failure. You are debugging output without access to the cause.

What a routing trace looks like

When Docira processes a page, the response includes a routing trace alongside the Markdown output. The trace records the complexity score computed from the page’s structural features, the tier that score maps to, the provider selected within that tier, the model used, and the confidence the verification step returned.

{
  "page": 47,
  "routing": {
    "complexity_score": 0.81,
    "tier": "expert",
    "provider": "nvidia",
    "model": "nvidia/llama-3.1-nemotron-ultra-253b-v1",
    "latency_ms": 4140,
    "confidence": 0.93
  },
  "content_markdown": "| Treatment | ORR | PFS (mo) | OS (mo) |\n|..."
}

The complexity score of 0.81 maps to the Expert tier. The confidence was 0.93 — high. Latency was 4.1 seconds.

Now suppose that same page had been routed to the Fast tier because the complexity classifier misread the table width. The trace would show complexity_score: 0.28, tier: "fast", and confidence would likely be 0.61. The debugging conversation goes from “the model is broken” to “the classifier underestimated this table — let’s look at the feature weights for table-cell count on this page format.”

Why this is hard to retrofit on a black-box system

Landing AI describes their system as agentic. AWS Textract does not claim to be agentic but is architecturally opaque. Neither publishes the model, the routing logic, or the confidence at the page level.

The reason is not malice — it is architecture. When a system is built around a single model or a fixed provider relationship, the routing layer does not exist. There is nothing to expose.

When a system is built as a multi-model router from day one, the routing layer is the central object. Exposing it is the natural output of a system that already has to compute and record the routing decision to operate.

The compliance angle

Regulated industries — healthcare, financial services, legal — face a specific version of this problem. Auditors do not ask “did the system produce correct output?” They ask “can you prove it, and can you show me the decision process?”

A routing trace is a decision record. It says: on 2026-03-14 at 14:32 UTC, document ID doc_01HXY page 47 was processed by the Expert tier using the NVIDIA provider, with complexity score 0.81 and confidence 0.93.

That is an audit record. You did not build a separate audit feature. You get the audit trail as a side effect of building a transparent system.

FDA guidance on AI/ML-based software as a medical device is evolving toward requiring documentation of model decisions, not just outputs. Systems that already produce routing traces will meet that requirement without a second engineering effort.

What “agentic” should actually mean

A genuinely agentic document system does at minimum three things: it evaluates structural complexity independently per page rather than applying a uniform model; it selects a processing strategy based on that evaluation; and it records the evaluation and the selection as structured output alongside the result.

The third item is the one that distinguishes a system an operator can trust from one they have to take on faith. Transparency is not a soft benefit. It is the mechanism by which an agentic system earns the right to operate autonomously in production.

An autonomous system that cannot explain its decisions is not an agentic system. It is a black box with better marketing copy.

How Docira handles this

Docira exposes routing metadata in every API response. Full trace detail is available via ?include_trace=true; basic tier, provider, model, and confidence fields are present by default. Every parse returns enough information to answer the question “why did the system do that on this page?”

Those fields are not an experimental feature or a debug mode. They are the product. They are what makes it possible to debug a garbled table, pass a compliance audit, tune the router for your specific document corpus, and build systems that behave predictably when the documents change.