Read, write, determine — drawing the authority boundary for agentic workflows in benefits programs

The first agentic-workflow proposals to cross our desk in 2024 and 2025 read like product brochures. The 2026 versions read like risk memos. The shift in tone is the right one. The structural decision they continue to get wrong is the same.

Every agentic workflow in a benefits program has to draw a line. On one side, the agent acts on its own. On the other, it routes to a human with a reviewable trail. Where that line falls is the single most consequential design decision in the system, and most teams draw it at the convenience boundary — let the agent do the thing that's annoying — instead of the determination boundary — let the agent do the thing that does not adjudicate a benefit.

M-25-21 has been in effect about eighteen months. Agencies are now in their first round of audited deployments. The OIG community is starting to ask, explicitly, where the authority boundary in each deployment was drawn and how it is enforced. The vendors who can answer cleanly will stay deployed. The vendors who cannot will be unwound.

A three-tier model for agent authority

There are three kinds of operations an agent can perform against a benefits system, and they have to be treated separately:

Read. Pulling information. Eligibility history. Prior decisions. Document contents. Cross-program data. This is the broadest tier and also the lowest-risk, provided the access is least-privileged and auditable. An agent that can read everything in the system in service of helping a caseworker get to the right answer faster is supporting human judgment, not displacing it.

Write. Modifying records. Adding documents to a case file. Annotating an eligibility worksheet. Routing a case to a queue. Updating a contact-information field on a claimant's request. This is the middle tier. Write operations need an idempotency contract, a clear reversal path, and a reviewable trail. They do not typically affect a determination on their own, but they affect the inputs to one.

Determine. Producing a finding that, on its own, changes a claimant's entitlement, eligibility, or status. Denials. Approvals. Overpayment findings. Sanctions. Terminations. Reductions. These are the operations that carry due-process implications under the relevant statutes and regulations, and these are the operations where an unreviewed agent action is not a design choice — it is a violation.

The reflex move when building agentic workflows is to draw the line between read and write, on the theory that anything that does not modify the record is safe. That is the wrong cut. The correct cut is between write and determine. A great deal of write operations can be done by an agent without touching due process. No determine operation can.

What "the determination boundary" actually means in code

It is not enough to write a policy that says the agent does not adjudicate. The agent has tool access. The tool access is where the boundary is enforced or breached.

The right architecture exposes the agent to two categories of tool:

• Read tools. Broad access, audited. Anything the agent can use to inform a human or assemble context for one.
• Write tools. Narrow, scoped, idempotent. Each one names exactly what it modifies and produces a structured log entry the human can replay.

No tool exists that mutates a determination field. Not a denial-flag write. Not a sanction-status update. Not an eligibility-tier change. Those fields are mutated only by a downstream service that requires a human reviewer's signed-off case packet as an input. The agent can prepare the packet. The agent cannot submit it.

This is the architectural realization of the read/write/determine model. The boundary is enforced at the API surface, not by hoping the agent's prompt will hold. Prompt-level guardrails belong to a category of safety control we have learned not to trust under adversarial input.

The reviewable handoff

When an agent escalates a case to a human, the artifact it produces is the entire deliverable. The handoff has to contain enough that the human reviewer can make the determination without re-doing the agent's work, and an OIG reviewer can later reconstruct what the agent considered.

The minimum shape of the handoff:

• The case identifier and the relevant policy basis under which the agent's preparation was done (specific section of the State Plan, federal regulation, or program manual).
• Every input the agent consulted, with content-addressed pointers so the documents can be re-fetched in their state at the time of the agent's review.
• The agent's reasoning trace, written as evidence rather than narrative — what it found, where it found it, what it could not find.
• A suggested disposition with the alternatives the agent considered, scored if scoring applies.
• A list of the questions a reviewer should answer to confirm or reject the suggestion.

This is not an explanation in the sense of "the model says it weighted these features." This is an evidence pack: the reviewable artifact a human reviewer signs off on, and an OIG reviewer asks to see eighteen months later in a redetermination audit. Treating the handoff as the load-bearing deliverable, not the model's intelligence, is what separates the agentic deployments that survive audit from the ones that quietly get unwound.

Where the boundary moves — and where it should not

Some agencies, having drawn the line correctly, then face pressure to move it. The pressure usually comes from the operations side. Cases are queuing. Reviewers are backed up. The agent is right far more often than it is wrong. Why not let it auto-approve the easy ones?

The honest answer is that auto-approval at the determination tier is not a slightly more permissive version of human review. It is a categorically different system. Once an agent can mutate a determination field, the entire chain — including the read and write tiers — needs to be hardened against adversarial inputs, prompt injection, and tool abuse, because the blast radius has changed.

The right move when reviewers are backed up is not to move the boundary. It is to expand what the agent prepares on the read and write tiers so the reviewer's actual work is smaller — usually a single confirm/reject against a complete evidence pack, taking under a minute when the case is clean. The right metric is not "what percentage of cases did the agent auto-approve." It is "how much of the reviewer's time did the agent's preparation save, while preserving the determination as a human act."

In practice we have seen this design produce per-case review times in the thirty-second range for the simple cases, while complex cases get the full reviewer attention they always required. The reviewer remains the determination authority. The caseload becomes manageable. No one is automated out of a job; the caseworker handles substantially more cases at higher quality with less administrative drudgery.

Failure containment

Even with the boundary drawn correctly, an agent will at some point do something wrong on the write tier — annotate the wrong case, route to the wrong queue, attach a document to the wrong file. Containment is the design discipline that bounds the damage when this happens.

Three properties matter:

Idempotency. Every write tool is safe to call twice. The agent never produces a write that cannot be reapplied or reversed without state corruption.

Append-only audit. Every write produces a structured, immutable record of what happened, by which agent, in service of which request, with the input payload and the resulting state. The record survives both the action and the system that performed it.

Reversal paths in code, not procedure. When something goes wrong, the reversal is a function call against a known interface, not a memo to the integrator. The function is tested. It exists in the codebase. It is rehearsed on a cadence.

These are not exotic requirements. They are the basics of any system that takes consequential actions. The fact that they are routinely absent in agentic deployments is what makes those deployments fragile under audit.

What to do Monday

Take the proposed agent on your roadmap. For every action it can perform, tag the action as read, write, or determine.

If anything is tagged determine, that action needs a human-review path before it ships. Not a stretch goal — a release blocker.

For everything tagged write, confirm three things: it is idempotent, it produces an append-only audit record, and there is a tested reversal path.

If the read tier is broader than the read tier on your existing audit log, you have a least-privilege problem the OIG will eventually find. Tighten before deployment, not after.

Where Vardr fits

We help agencies and large enterprises draw the authority boundary explicitly, in code, in the architecture, and in the procurement contract — so that the line is enforced at the API surface and is defensible to a reviewer who arrives eighteen months after launch. The Reference Architecture treats the read/write/determine boundary as the central control plane for agentic workloads. The agentic safety review we run with engineering teams produces, in two weeks, a written authority map of every proposed agent action with the right human-review paths attached.