Extend governance beyond output review
Policies built around drafting, summarizing and employee research need to be examined again when a system gains authority to execute a task. In a drafting workflow, output review is a visible control: a human evaluates the recommendation before acting on it. Privacy, security, data governance and evaluation also matter, and remain essential when tools gain the ability to act.
NASCIO's March 2026 report, "Beyond Generation: The Rise of Agentic AI in State Government", describes the move toward systems that act. The accountability model needs to cover actions as well as generated outputs.
Know when assistance becomes action
Agentic AI often uses generative models but adds tools, permissions and multi-step execution. A generative AI tool helps a caseworker draft an eligibility determination — the caseworker reads it, approves it, signs it. As a hypothetical workflow, an agentic AI system could plan an eligibility review, gather supplemental documentation from connected systems, apply rules, generate the determination, initiate notification correspondence, and log the outcome — completing a multi-step administrative process with limited or no human input at each intermediate stage.
The state agency remains accountable for every outcome. But the governance architecture required to make that accountability real — to trace which decision nodes the AI cleared autonomously, which it flagged for human review, and why — is structurally different from reviewing the text of a document a chatbot drafted. NASCIO's March report describes a gradual transition and reports that eight states had identified some agentic tools in production during its Top Ten research. That finding does not establish the safety or scope of any particular benefits deployment.
Distinguish emerging standards from implementation controls
NIST recognized this architecture shift in February 2026, launching an AI Agent Standards Initiative focused on industry-led standards, open-source protocols, and security and identity research. For a deploying agency, that standards work sits alongside immediate design decisions about logging, containment and authorization. An agency should examine whether its existing framework addresses these concerns rather than assume that all state policies are alike. A policy focused on disclosure, prohibited uses and vendor attestations may not specify what an AI agent is permitted to do without human approval at each step, how its actions are logged in a way that supports after-the-fact accountability, or how its operational scope is bounded so that a malfunction or an adversarial prompt cannot cause it to take consequential action outside its intended authority.
The gap between what state policy currently governs and what agentic architecture actually requires can arise when a policy written for advisory use is applied to a system with permission to act.
Protect accountability for resident outcomes
The accountability stakes are not hypothetical. NASCIO's March 2026 report cites earlier joint research showing 75 percent of state CIOs holding serious concerns about deploying generative AI in direct citizen services — accuracy, data security and privacy, and the availability of training and support. Those concerns can become more consequential to agentic deployments, where the action surface is larger and the opportunity for real-time human correction is structurally reduced. When an AI agent initiates correspondence on behalf of a state agency, the agency should be able to establish which steps were automated, which were reviewed and who authorized the resulting action. A notice may explain the use of automation, but disclosure does not replace that internal evidence.
The oversight architecture needs to match the operational reality — not the procurement representation or the policy intent, but the actual path that a determination traveled before it produced a consequence for a resident.
Build controls before increasing autonomy
The practical implication for state technology executives considering agentic pilots is sequencing. NASCIO's framework describes five phases states might move through — from generative assistance to proactive and adaptive agents — and governance architecture should be built ahead of phase transitions, not retrofitted after deployment. The most durable posture is modular and explicit: define what decisions the agent may make without human confirmation, build action logging that produces a reviewable audit trail at each step, establish containment parameters that prevent the agent's authority from expanding beyond its defined scope, and determine in advance what conditions trigger escalation to a human reviewer.
These are not abstract policy questions. They are engineering requirements that need to be resolved in the system design phase. Retrofitting containment architecture onto an already-deployed agentic system is the same class of problem as retrofitting security onto a running enterprise platform — it can be costly and disruptive to an operating service.
Scale only when oversight works
Agentic AI is already entering some state workflows. An agency considering automation for a benefits, licensing, permitting or compliance backlog has to evaluate both the throughput opportunity and the consequences of a mistaken action. The procurement decision should establish whether its control architecture can support the proposed delegation. Action logs, defined authority and containment requirements provide a basis for testing that proposition; their presence in a design document does not prove that oversight works.
States that deploy pilots without that architecture increase the risk of constituent harm and findings that reveal missing controls. The safer scaling decision is to make authority, evidence and stop conditions part of the initial design.
Set the boundaries before expanding the pilot
- Define the action boundary. List allowed tools, records, actions, spending limits and prohibited outcomes. Use scoped service identities rather than a shared administrator credential.
- Require approval at consequential steps. Specify who reviews eligibility changes, payments, external notices and destructive actions. A hypothetical automated workflow is not authorization to delegate a statutory decision.
- Test hostile and ambiguous inputs. Include misleading documents, prompt injection, conflicting rules, unavailable tools and duplicate requests. Verify the system stops or escalates instead of improvising authority.
- Capture decision evidence. Log source records, model and rule versions, tool calls, approvals and resulting changes, with privacy-aware retention and access controls. Do not rely on a fluent explanation as proof of what happened.
- Exercise the stop and repair path. Revoke credentials, pause new work, reconcile partial transactions and route affected cases to people. Measure whether operators can do this within the service's tolerance.
What to measure
- Unauthorized action rate: attempted and completed actions outside the approved scope.
- Escalation quality: whether difficult cases reach the right human with usable evidence.
- Recovery performance: time to stop execution and reconcile partial work after a simulated failure.
Choose the smallest useful delegation
The practical design choice is how much authority the workflow needs. The following comparison is an engineering recommendation, not a universal maturity ladder.
- Read-only assistance can retrieve authorized records and assemble a proposed next step. This can be appropriate when evidence is fragmented or the agency is still validating accuracy. Staff retain execution responsibility, although retrieval access, privacy and misleading recommendations still need controls.
- A bounded task with approval can prepare a transaction, show its proposed effect and wait for an authorized employee before submitting it. The approval should bind to the actual transaction being executed; a changed amount, recipient or case should require a fresh decision.
- Broader delegated execution can complete defined actions without approval at each step. It demands stronger evidence that scope restrictions, exception handling and recovery work under the conditions the agency expects to face. It should not inherit permission to perform every action available through an integration.
A conventional rules-based workflow is also a credible option when the steps and exceptions are well understood. Use an agent where interpreting variable evidence or coordinating uncertain tasks adds enough value to justify the additional evaluation. Buying greater autonomy is not itself an operational improvement.
Test the transaction that stops halfway
Consider a hypothetical permit-renewal assistant that updates an internal status and then sends a notice. The status update succeeds, the notice service times out, and the request is retried. A useful test asks whether the second attempt repeats a consequential action, sends a contradictory notice or identifies the first attempt and resumes safely.
That scenario exposes responsibilities a text-quality review misses. Before release, have the system owner and program operator demonstrate these controls:
- Identify each intended action. Assign a transaction reference that lets operators distinguish a retry from a new request. Record what the receiving system actually accepted, rather than assuming a tool call means the work completed.
- Recheck authority at execution. Test what happens if access is revoked or a case changes after planning but before the next tool call. The workflow should stop or obtain fresh authorization when its assumptions no longer hold.
- Reconcile partial work. Some actions can be reversed; an external notice cannot simply be unsent. Define which changes can be rolled back, which require a compensating action and which must go to a person with program authority.
- Prove the stop reaches the tools. Pausing the conversational interface is insufficient if queued actions keep running. Exercise the actual credential, queue and integration controls and verify the resulting state in the connected systems.
Use a controlled environment and explicitly authorized test records. Record the expected outcome before the exercise, the observed outcome afterward and the person responsible for each unresolved failure. Keep the limits of the exercise visible: passing one retry test does not demonstrate safe handling of every dependency failure.
The release decision should identify an operating scope that the evidence supports. A narrower deployment with reliable recovery can be more useful than a broader pilot whose operators cannot establish what it changed. Expand authority when tests and operating evidence justify the next step, with a named owner able to suspend it.
Sources and further reading
- NASCIO agentic AI report — March report, earlier survey evidence and staged adoption
- NIST AI Agent Standards Initiative — February launch and official three pillars
Spartan X brings AI consulting, cybersecurity and engineering to the same design problem: giving an automated workflow enough authority to be useful, with controls that keep its actions observable and accountable.
