Publicus processes procurement data spread across RFPs, contracts, amendments, award notices, invoices, task authorizations, webpages, and other records. Our early AI workflows optimized for producing a useful answer: retrieve relevant context, reason over it, generate structured output, and evaluate the result. That worked until we tried to increase automation in workflows where an answer can be semantically correct while its evidence is incomplete, stale, contradictory, or simply the wrong source.

We redesigned the system around an evidence ledger rather than the generated answer. Extracted facts and agent claims became typed artifacts carrying source document, location, provenance, transformation history, confidence, and conflicts. Retrieval became evidence acquisition rather than context stuffing. Verification became a separate stage that reconciles claims across records. Unsupported or conflicting outputs cross an explicit human-review boundary instead of being silently converted into fluent prose.

The redesign also changed how we evaluate the system. Instead of relying primarily on answer quality or a single LLM-as-judge score, we measure the pipeline at several boundaries: field-extraction F1, claim-to-source agreement, evidence-grounding accuracy, conflict detection precision/recall, unsupported-output rate, lineage coverage, bilingual performance, latency, cost per document, and human-review burden.

I’ll walk through the production architecture, the failure modes that forced the redesign, where deterministic code replaced model judgment, how we preserve evidence through multi-step agent execution, and how we decide whether a new model or workflow is actually safe to promote.

Attendees will leave with a practical pattern for building agents where correctness means more than producing the right-looking answer: designing typed evidence artifacts, separating retrieval from verification, constructing evals around failure boundaries, and defining human escalation rules for high-stakes AI systems.