The Most Valuable Federal AI Work Is Boring

The best early deployments aren't clever. They sort, label, and route documents so people can spend their time on the decisions only they can make.

An AI system that answers questions about a document has done the easy part. Someone still has to decide what the document is, send it to the right person, check the answer against the record, and defend the result when it's challenged. The cost of federal paperwork sits in that gap between an answer and a finished process.

The work in that gap is classification, extraction, reconciliation, and routing. It tends to live in a spreadsheet someone built because two systems disagree about what a record means. That spreadsheet is worth reading before you replace it. It holds the real procedure: the identifier that needs cleaning before it matches, the blank field that means different things in different systems, the discrepancy that goes to a supervisor versus the one resolved by opening an attachment.

Some of that is judgment, some is rules, and some is a workaround that should vanish once an integration is fixed. Sorting these apart comes first, because it tells you where a model helps and where plain software is cheaper and safer. An exception caused by a missing integration is a software problem. Interpreting a paragraph in a supporting document is a reasonable job for a model. The same review queue often contains both. The team should also ask whether each manual step still earns its place, so automation doesn't reproduce an obsolete workaround faster.

You'll need someone with domain knowledge in the room. They explain which source governs a disputed field, who has authority to resolve a dispute, and what counts as done. That person helps write the acceptance criteria and reviews unresolved cases during development. Without them you move uncertainty between applications instead of resolving it.

Public interfaces give a team something concrete to scope against. USAspending's award and account-level API, GSA's procurement and federal-organization APIs, and Treasury Fiscal Data's datasets and dictionaries expose records and definitions you can inspect before committing to a design. Looking at a real response and its documented meaning is a far better basis for a project than assuming every record will match cleanly or that an agency holds all the data the workflow needs.

What actually sits between a prediction and a result

A model's output is a proposal. Turning it into a result takes several pieces of ordinary engineering, and the quality of that engineering determines how much supervision the deployment needs.

Interpretation with evidence. In extraction, the model might propose an amount, a date, and a recipient. Each depends on context. The amount being requested differs from one quoted as background, and the date of the current transaction differs from one in an earlier attachment. If a corrected document supersedes the ingested one, previously plausible values may no longer describe the case. The model should return the source passage for each field, so a reviewer can open it and catch a value that was read correctly but assigned the wrong meaning.

Validation that doesn't depend on the model. Exact identifier matches, arithmetic checks on totals, and confirmation that a supporting record exists should be code. They should behave identically whichever model produced the candidate values, so that swapping an endpoint can't quietly change an established rule.

Handoff that keeps the contradiction. A complete, validated extraction moves forward under the process's rules. A conflict goes to the person authorized to resolve it, with the contradictory evidence attached, rather than being replaced by a persuasive explanation.

Writes that can be retried safely. Writing accepted values to the destination application brings its own permissions and failure modes. If a write succeeds but the acknowledgment is lost, a naive retry creates a duplicate. The operator needs a reliable way to tell a changed record from a proposal that was never executed or one the destination rejected. In practice that means idempotency keys on writes and an explicit record of each action's state.

Durable task state. A failed model call should leave enough state to resume at the right point. Retrieval and validation shouldn't repeat just because the reasoning step needs another attempt. If operators have to reconstruct state from logs after every failed request, you've swapped one administrative burden for another, however good the extraction is.

Routing with an owner. A routing suggestion needs a valid destination, a current permission check, and a way to detect whether the receiving team accepted it. A correct prediction still leaves a form sitting if the queue has no owner, so destination ownership is part of the design, not an afterthought.

Corrections that preserve history. When a reviewer changes an extracted value, keep the original proposal, the corrected value, and who changed it. Otherwise the final record suggests the model was right all along, and the team loses the data it needs to investigate errors. The same applies to reconciliation. If a model associates two records whose descriptions differ, keep the basis for the match, so it can be revisited when later information contradicts it instead of being treated as established fact.

Interpretation that lives in code. Metadata deserves as much attention as the payload. A familiar-looking field name can refer to a different reporting period or level of aggregation than the analyst expects. Verify that a comparison means what the workflow assumes, and keep that interpretation in the integration where it can be tested and reviewed. If it lives only in a prompt written during a prototype, the next developer may change a business rule without realizing it. Public data access is helpful, but a defensible use of the data still needs an owner, who knows which upstream changes would invalidate the comparison and how the application will detect them before publishing another result.

This is why agents interest me as part of operational software. A system with tools and write access can cause consequences well beyond a wrong paragraph, which makes the surrounding engineering more important, not less.

Example 1: First-pass CUI marking

Controlled Unclassified Information is a good test case because the labels are defined and public, the volume is high, and a wrong call has real consequences in both directions. Over-marking slows sharing, and under-marking exposes information. It is also a reading problem with repetitive work and errors whose consequences can be described and tested.

A fifteen-second demo shows a model highlighting a paragraph and assigning a label. It leaves out the category context, the source evidence, the review decision, and what happens to the information afterward. Those are the parts that decide whether a classifier supports the work people actually need to finish. The document keeps moving through reports, generated summaries, spreadsheet exports, and other workspaces after inference ends, so the system has to carry context across each of those transitions.

Handling rules come from outside the model. NARA's government-wide CUI program publishes marking and handling resources, and NIST SP 800-171 Rev. 3 addresses protecting CUI in covered nonfederal systems. Agency, contract, category, and legal context can all affect a determination. When that context is missing, the system should name the gap and route it for resolution. A high confidence score is not authority.

The DoD CUI Program's category list pairs abbreviations with index groups and runs to more than a hundred entries, such as CTI (Controlled Technical Information, Defense), EXPT (Export Controlled, Export Control), PROPIN (General Proprietary Business Information, Proprietary Business Information), and HLTH (Health Information, Privacy). The design splits the work between two models according to what each is allowed to see.

The large model works at the public boundary. It never touches a sensitive document. Its job is to fetch the category list and stage it as a versioned table: abbreviation, name, index group, and retrieval date. When the source changes, it diffs the new snapshot against the old one and proposes label additions or renames, with draft descriptions and synthetic example passages. A person who owns the taxonomy reviews the proposal, and nothing reaches production until the evaluation set has been re-run against the new label set.

The small classifier works inside the enclave. It reads the actual documents and proposes categories against a supplied category profile. The task is multi-label, since a subcontractor's technical data package might plausibly carry CTI, EXPT, and PROPIN at once. Each proposed label comes with the passage that triggered it, plus the document version and location, including a path back to the scanned page where text was extracted, so the reviewer can catch reading errors. The index group drives routing, so privacy-related labels go to the privacy office, law-enforcement labels to that review queue, and so on.

Deterministic checks run beside it. Known identifiers and explicit policy rules can be matched by code, with results recorded next to the model's findings. A document might carry an identifier in an attachment and a narrative description in the main body. The rule finds the identifier, the model proposes a category for the description, and the reviewer sees both findings and how they relate. When the two methods disagree, keep both results rather than blending them into one score.

Review gets a usable case. The reviewer sees the source artifact, the triggering evidence, the candidate category, and the applicable profile, with the model's suggestion clearly distinguished from a confirmed determination. The workflow waits for confirmation rather than treating a proposal as decided. Rejections should carry a reason, because a rejection can reveal a bad detector, an incomplete profile, or a misunderstanding that will recur. If every rejection collapses into a boolean, the team loses that signal. Keep the determination record's evidence (what was found), authority (the context and process), and outcome (what that process decided) distinct, so the record stays readable after the classifier is replaced.

Ordinary code does the rest. After confirmation, a defined renderer produces the banner and marking formats from the decision and its rules, so output is consistent and testable and the model never writes the marking itself. Summaries, extracted tables, and merged reports derived from a marked source must keep their provenance (source versions used, what was extracted, any unresolved questions) and go through their own determination. Changed wording does not by itself change handling status. Before anything moves, a destination check evaluates the transfer against the permitted handling context, because a workspace's name or its ability to accept a file doesn't establish that it's approved for that information. The same applies to inference itself: an external classifier receives the information, so the approved processing path is part of the design from the start.

Designating something as CUI is a decision by an authorized person. The system prepares that decision and makes review faster, but it doesn't make it. Three properties follow: the category list stays current without anyone retyping it, the sensitive documents never leave the secure environment, and when someone asks why a document was marked a certain way, the record shows the source passage, the label-set version, and who approved it.

Example 2: First-pass triage of VA claims

Disability claims arrive as a pile of mixed evidence: service treatment records, private medical records, discharge paperwork, exam results, and statements from the veteran or family. The first job is to work out what each document is, which claimed condition it relates to, and which part of the case it supports.

The structure mirrors the CUI example.

The large model stages the public reference material. That includes the rating schedule, which organizes conditions by body system with diagnostic codes, and the evidence requirements for service connection, generally framed as a current diagnosis, an in-service event or injury, and a link between the two. It converts these into a versioned label table and flags changes when the source text is amended, with a taxonomy owner approving each update.

The small classifier labels each incoming document with its type, the condition it concerns, the body-system queue it belongs in, and which of the three elements it speaks to. A treatment note recording a back strain during service speaks to the in-service event. A recent private MRI speaks to the current diagnosis. A statement from a family member is lay evidence and carries different weight.

Rules handle the gaps. If the file has a diagnosis and an in-service record but nothing connecting them, a deterministic check flags the missing element and routes the case to whoever requests a medical opinion or exam. No model is involved, and none should be. It's an if-statement over labels the classifier already produced.

Humans keep the decisions. The system assembles the indexed evidence and flags what's missing, and the rater decides the claim.

The same cautions apply, and they matter more because the records contain health and personal information. Sensitive records stay inside the boundary. Conflicting dates, duplicate submissions, and superseded exams go to a person with their evidence attached, and a confident-sounding summary never resolves them. The task-state, idempotency, and correction-history requirements from earlier apply here exactly as they do for CUI.

The model bill is only part of the cost

Inference pricing attracts attention because it's measurable and easy to compare, but it captures only part of what a workflow costs. Connecting sources, agreeing on field meanings, building evaluation cases, handling access, and maintaining the system when an upstream application changes all belong in the assessment. Review effort often outweighs differences between endpoints, especially for frequent tasks or those needing specialist staff. If ambiguous results force a fresh review of every case, a low per-token price won't make up for a reviewer who has to inspect the original, inspect the extraction, understand the flag, and decide whether to trust it.

A smaller local model can be the right choice when it performs adequately and fits the deployment boundary. Predictable infrastructure costs, disconnected operation, and keeping documents inside the environment are all legitimate reasons, and they should shape the design early rather than arrive as surprises after a hosted prototype hardens into the architecture. But a local model that can't do the job incurs its own costs through errors and review, and the infrastructure and people who serve it have to be counted. A hosted model can be reasonable for an approved workload when its dependencies and costs are understood. The comparison has to include the operation around either choice.

Aggregate usage data offers context but not an answer. OpenRouter's 2025 State of AI study analyzed more than 100 trillion tokens on its platform and documented programming use and agentic inference, which says something about how models are used in that ecosystem. The economics of a federal deployment still depend on its own workload, review burden, and operating requirements.

A claim small enough to prove

Pick one workflow, a real owner, and a clear completion condition. "Extract and validate defined fields from one document family" or "prepare the evidence for one recurring review" can be tested. "Help analysts" can't. A 90-day window helps because it forces early decisions on scope, access, data quality, integration, and approval, and it leaves time to evaluate the result.

Before changing the process, keep a representative set of historical cases and establish the baseline: manual touches per case, time spent waiting, and how often output needs correction. Waiting matters because a faster extraction step does little if the approval queue dominates elapsed time.

Then run the same cases through the manual process, a rules-only approach where one is feasible, and each candidate model-assisted architecture, with review and correction time counted in all of them. Include boundary cases: documents that resemble a category without meeting the determination, documents with incomplete context, and cases where the correct result is to request review rather than assert an answer. Count both missed candidates and unnecessary flags, since a detector that flags everything produces an impressive recall number and an unusable queue. Look at the distribution of effort too, because a better average can hide difficult cases that have become more expensive.

Test the stages together, from source inspection through review, marking, derivatives, and destination checks, since a narrow classifier score misses failures between them. Test dependency failures as well. When inference is unavailable, the application should keep the source, the gathered evidence, and the pending review state, and deterministic checks can continue while ambiguous decisions wait. Any fallback should stay within processing paths already approved for that material.

When the first version can't resolve an ambiguity, it should show the operator what it tried and what remains uncertain, and keep the useful work already done. Don't assume saved minutes become saved dollars. Often the result is a shorter queue, faster responses, or capacity for other work, and the evaluation should say how the returned time was used and how that was measured. Another person should be able to reconstruct any outcome from the retained evidence, including corrections and approvals between first extraction and final record.

The result may show that ordinary integration work delivered most of the benefit, which still leaves a working improvement and a clearer picture of where a model earns its place. Or it may show a model handling one narrow ambiguity well enough to remove a lot of searching. If review effort erases the gain, report that and decide whether the architecture can be fixed economically. A bounded deployment that exposes a bad assumption early is worth more than a large program built on it, as long as the evaluation has the authority to affect whether the work continues.

Mission applications with higher stakes deserve serious engineering of their own, and so do administrative workflows where people spend real effort handling records correctly with tools that make it harder than it should be. The most convincing demonstration of this work is a quiet one: a reviewer working through a queue whose labels are mostly right, and a spreadsheet nobody needs anymore.