Stop Letting Prompts Run the Workflow

The most expensive agent failures usually do not look like science fiction. They look like ordinary process failures.

A support agent skips the verification step because the customer sounded urgent. A procurement assistant chooses a branch in the policy that was never triggered. A back-office workflow agent calls the right tool with the wrong payload, then explains itself in perfectly reasonable language. Nothing in that story requires a malicious jailbreak. It only requires a model that was asked to keep too much procedure, state, and authority inside a prompt.

That is why a pair of new July 2026 agent papers is worth watching. The useful shift is not “better prompt engineering.” It is the idea that enterprise workflows should be compiled, interpreted, and checked like software.

The clearest version comes from COVENANT: Natural-Language Workflow Compilation for Aligned Agent Execution. The authors describe a failure mode they call workflow misalignment: when a natural-language policy tells an agent which steps, branches, and tool interactions are allowed, but the model still controls both the procedure and the execution. Over a multi-turn interaction, the agent can skip a required step, take an unsupported branch, or execute a valid step with unsupported arguments or effects.

COVENANT’s answer is simple in principle and important in practice: treat workflow instructions as source programs, not prompt context. The system converts natural-language instructions into a workflow abstract syntax tree, lowers that into a workflow control-flow graph, and then uses a runtime controller to interpret the graph one node at a time. Before the controller commits state or advances the workflow, it checks the model’s proposal against requirements extracted from the original instructions. If the proposal does not fit, the controller returns diagnostic feedback for repair.

That is a different trust boundary. The model can still read, reason, draft, and propose. But it does not get to silently rewrite the process while executing it.

The reported results are also a useful signal, with the right caveat. In the arXiv abstract, COVENANT is evaluated on 120 cases from three existing benchmarks across seven workflow scenarios. The authors report benchmark success improving from 50.00% to 83.33%, while workflow-misalignment failures drop from 42.50% to 15.83%. That does not make the system production-proven. It does suggest that moving process control out of the prompt and into an interpreter can materially change failure rates.

A companion idea appears in Explanation-Bound Tool Execution for AI Agents. The paper starts from a point every builder of tool-using agents should internalize: free-form rationales are not authorization. An agent’s explanation for a tool call may be useful as a debugging artifact, but it is not a reliable source of truth about intent, policy, payload safety, provenance, or freshness.

The proposed EBTE pattern converts decision-relevant rationale content into typed action claims, then checks those claims against server-held facts. The abstract names the relevant fact classes: intent, policy, payload, tool, risk, provenance, and freshness. EBTE cannot widen the agent’s baseline authority. Conflicts deny. Incomplete or uncertain claims go to review. Only matching claims remain eligible for governed execution.

This is the missing half of workflow compilation. COVENANT asks, “Is this the next allowed step in the process?” EBTE asks, “Are the claims behind this action consistent with trusted server-side facts?” Together, they point to a healthier enterprise-agent architecture: the model proposes, the controller checks, the server commits.

That architecture matters because multi-turn agent drift is not theoretical. Operational Hallucination and Safety Drift in AI Agents describes how tool-using agents can degrade over extended execution. The paper’s abstract highlights two failure modes: safety drift, where declared safety intent erodes into constraint-violating actions, and operational hallucination, where flawed state perception causes repetitive or livelock-like tool calls. The authors attribute these instabilities partly to a decoupling between reasoning context and execution state, and propose an action-aware supervision layer with intent-action consistency checks, runtime state tracking, and forced termination primitives.

In other words: if the state that matters lives only in the conversation, the process is fragile. The agent may sound aligned while its actions wander.

This is especially relevant as tool ecosystems mature. The Model Context Protocol authorization specification formalizes how MCP servers and clients should participate in OAuth-based authorization discovery and protected-resource metadata. That is necessary infrastructure. But authorization alone does not answer whether this action belongs at this moment in this workflow, with this evidence, after these prior steps. A token can say the agent may access a resource. It cannot, by itself, say the workflow has reached the branch where that access is appropriate.

Anthropic’s “Building Effective AI Agents” makes a useful distinction here: workflows orchestrate LLMs and tools through predefined code paths, while agents dynamically direct their own process and tool use. Many enterprise automations should probably live between those poles. Let the model handle language, ambiguity, summarization, classification, and proposal generation. Let deterministic controllers own the gates, state transitions, hard policies, and commit points.

For teams building with agents now, the practical playbook is straightforward.

First, pick one high-value workflow. Do not start with a universal agent platform. Start with a workflow where skipped steps, unsupported branches, or wrong tool arguments would cause real operational pain.

Second, mark the hard gates. Which steps are mandatory? Which branches require evidence? Which tool calls require fresh data? Which actions must stop for human review? Which states are terminal?

Third, separate proposal from commit. The model can propose the next step and draft the tool payload, but a controller should decide whether the proposal matches the compiled workflow state. If it does not match, return a repairable diagnostic instead of letting the model improvise.

Fourth, make action claims typed. “I’m doing this because the user asked” is not enough. The system should be able to check structured claims about user intent, policy basis, payload contents, risk level, tool scope, evidence provenance, and freshness against server-held facts.

Fifth, log the minimum audit packet that explains the decision. You do not need to store every token forever. You do need enough evidence to answer: what did the model propose, what did the controller verify, what state changed, what was denied or sent to review, and why?

Finally, measure process integrity directly. Track branch violations, stale-state attempts, unsupported payloads, review rates, loop terminations, and recovery time after a rejected step. “The answer sounded good” is not an agent reliability metric.

The larger lesson is that prompts are a language boundary, not a control plane. They are excellent for telling a model what the work means. They are weak at guaranteeing that a multi-step process executes in the right order, with the right authority, against the right state.

Enterprise agents will become more useful when we stop asking the prompt to carry the whole workflow. Compile the procedure. Check the claims. Commit only what the runtime can verify.