Microsoft Foundry's Evidence Gateway Guidance Puts Document Quality Before Agent Decisions

11 minutes ago
4 min read

Microsoft's Foundry Blog published Evidence Gateway architecture guidance on September 7, 2026. Its recommendation is to process and validate incoming documents before asking an agent to reason over them.

This is an architecture pattern, not a newly launched Azure service or a blanket ban on attaching files to agents. It is particularly relevant when a document-based recommendation needs to be checked, explained, or challenged. Read Microsoft's guidance.

For cloud engineers, the useful question is simple: when an answer is wrong, can we tell whether the document was misread, the application supplied the wrong evidence, or the reasoning failed?

What the Pattern Changes

The guidance separates ingestion, document understanding, schema mapping, quality controls, and reasoning. An agent receives a task-specific evidence package rather than being responsible for every transformation hidden inside a large file.

That package retains references to the source and makes uncertainty visible. Missing or conflicting material information can enter a review path before a recommendation proceeds.

Think of it as an explicit interface between two independently testable parts of the application: document processing and decision support.

The Azure Building Blocks Already Exist

Azure Content Understanding supports field confidence and grounding information that connects extracted results to their original location. Its documentation describes these capabilities for both the 2025-11-01 GA and 2026-06-01-preview APIs.

The same documentation distinguishes ordinary labeled-sample training from the optimized training behavior introduced in the preview API. Teams should choose a supported API version deliberately rather than assuming every documented improvement has identical production status. Content Understanding quality guidance.

Azure Document Intelligence also exposes confidence information for supported extraction outputs. Its guidance recommends evaluating the relevant confidence signals and including human review where needed; not every field provides a score. Document Intelligence confidence guidance.

My implementation recommendation is to treat these outputs as inputs to application policy. A confidence number does not determine whether a business action is authorized.

An Illustrative Engineering Review

Consider an internal procurement assistant reviewing a supplier quotation. This is an example design, not a Microsoft product demonstration.

The assistant needs to compare three things: the requested item, the supplier's quoted item, and the approved purchasing rules. Before it reasons, the application could check:

Whether an item identifier was actually extracted.
Whether quantity and unit of measure are present.
Whether the quote contains conflicting delivery dates.
Whether the supplier reference matches the record selected by the user.

A clear item description should not compensate for an unreadable quantity. Likewise, a technically valid JSON response should not turn an unresolved delivery-date conflict into an approval.

Start with the fields that could change the outcome. Write tests for those fields before spending time making the generated explanation sound more polished.

Extraction Quality and Prompt Security Are Different Checks

A document can be easy to read and still contain hostile instructions. Azure AI Content Safety's Prompt Shields for documents addresses indirect prompt-injection attempts embedded in external content. That is a different problem from OCR accuracy. Prompt Shields documentation.

My recommendation is to keep the action boundary outside the document. Supplier text must not grant tool permissions, select a more privileged identity, or authorize a transaction. The application should enforce those rules independently of whatever explanation the model produces.

For a pilot, keep downstream write operations disabled. Compare recommendations against known examples first, then introduce narrowly scoped actions only after separate authorization and recovery requirements are established.

Test Failures, Not Just Happy Paths

A useful evaluation set should include deliberately awkward inputs:

A quotation with two different quantities in separate sections.
A scanned page with a missing decimal point.
An attachment belonging to a different supplier.
A document that asks the assistant to ignore its task.
A correct extraction paired with an outdated purchasing rule.
A request for an action the current user cannot authorize.

Score extraction correctness and recommendation correctness separately. Otherwise, an improved model can appear worse because the extractor changed, or an extractor regression can disappear inside an aggregate answer-quality score.

Also record how long a reviewer needs to resolve an exception. A system that flags every case safely but takes longer to operate than the original process needs further design work.

Who Should Care?

This guidance is useful for Azure teams building document-heavy internal assistants, integration workflows, and review tools. It is especially valuable when multiple teams own ingestion, application logic, and AI behavior.

It is less compelling to build an elaborate pipeline for a low-risk, occasional summarization task. Match the engineering investment to the consequence of a wrong output.

Practical Cloud Engineer Takeaway

Start with one document type and one decision-support task. Define what correct input looks like, measure how often you obtain it, and test what happens when it is absent.

The operational win is clearer diagnosis: engineers can investigate a specific processing stage instead of repeatedly changing a prompt and hoping the end-to-end result improves.

Bottom Line

The new guidance is a useful reason to review the interfaces around an Azure AI application. Better document handling deserves its own tests, ownership, and deployment checks.

A convincing answer is only one part of a dependable workflow.