Planning architecture is what makes agents complete multi-step work

At a glance

What this is: Arize argues that agent planning must be an enforced architecture layer, not a prompt suggestion, if multi-step workflows are going to complete reliably.

Why it matters: For IAM and AI security teams, this reframes agents as systems that need state, completion rules, and governance controls rather than loose instructions.

Context

Planning is the control layer that keeps a multi-step agent from forgetting its own objective while tools, JSON, and session history accumulate. When planning exists only as prompt text, the model can drift, finish early, or abandon intermediate work because nothing in the system can inspect or enforce the intended sequence.

That problem matters for identity and access governance because an agent operating in production behaves less like a simple model response and more like a non-human actor with tasks, state, and permissions. If completion is not structurally enforced, the same governance gap appears that identity teams already know from unmanaged service workflows: activity happens, but accountability and lifecycle control do not follow cleanly.

Key questions

Q: What breaks when planning is only a prompt instruction for multi-step agents?

A: Prompt-only planning breaks because the model cannot reliably inspect, persist, or enforce the task sequence. Once tool outputs and session history accumulate, the original objective gets buried, and the agent can drift, stop early, or loop without closing work. Structured planning turns intent into state the system can validate.

Q: Why do multi-step agents need visible task state and finish gates?

A: Visible task state keeps the current objective in front of the model, while finish gates prevent the agent from claiming success before declared work is complete. Together they convert planning from a suggestion into an operational contract, which is essential when agents manage complex workflows across many tool calls.

Q: How do security teams know when agent planning is failing in practice?

A: The clearest signs are partial task completion, repeated tool calls without progress, early termination, and plans that disappear behind long histories of tool output. If the agent frequently loses track of what it is doing, the architecture is not preserving state well enough for the workload.

Q: Should organisations treat agent planning as part of governance or just implementation detail?

A: They should treat it as governance. Once an agent can act across multiple steps, planning determines what work is allowed to continue, what is blocked, and when a task is truly finished. That makes planning part of the control plane for agent behaviour, not a cosmetic UX feature.

Technical breakdown

Structured planning tools turn intent into enforceable state

The architectural shift here is to move planning out of prompt text and into tool calls that create structured state. Arize describes todo_write, todo_update, and todo_read as the interface for plan creation, plan mutation, and plan inspection. That matters because structured objects can be stored, displayed, and validated by the system, while free-form reasoning cannot. The addition of in_progress also changes the control model, because it gives the agent a working pointer instead of forcing it to pretend every task is either untouched or done. In effect, planning becomes an observable workflow state, not a hidden thought process.

Practical implication: Practitioners should treat planning as a first-class tool surface and require machine-readable task state before allowing complex agent execution.

PlanMessage placement prevents context drift

A plan only helps if the model keeps seeing it. Arize’s PlanMessage is injected on every iteration right after the system prompt, before session history, so the current task list stays visible even when tool output floods the conversation. That positioning is important because the problem is not only memory loss, but attention competition inside the context window. The model may technically have the plan in history, but if it sits behind pages of JSON and tool output, it is easy to ignore. Fixed placement plus explicit coaching creates a stronger working context than simply appending more messages.

Practical implication: Practitioners should pin the current plan in a predictable position and rebuild it from current state on every loop rather than relying on conversation history.

Finish gates convert planning from guidance into enforcement

The final control is the hard gate on completion. If the agent tries to finish while tasks remain pending or in_progress, the system rejects the attempt and returns the incomplete items. That is a governance pattern, not just an engineering convenience. It ensures the agent cannot claim success before it has actually closed every declared task, and it gives blocked status a legitimate role when human input is required. This is the difference between a model that can narrate progress and an agent that must satisfy a completion contract before exiting.

Practical implication: Practitioners should enforce end-of-task validation in code so unfinished work cannot be masked by a confident finish response.

NHI Mgmt Group analysis

Planning debt is becoming an agent governance problem: the issue is no longer whether a model can reason, but whether its reasoning is translated into enforceable task state. Free-form planning creates invisible drift because there is no durable control plane for progress, completion, or blocking conditions. For teams building agents, the practical conclusion is that planning must be governed as lifecycle state, not left as a conversational suggestion.

Visible state is the missing control in multi-step agent design: the article shows that agents do better when task state is explicit, persistent, and inspected on every iteration. That pattern aligns with broader governance logic in identity systems, where the system must know what exists before it can certify it. For agentic AI, the analogue is clear: if the plan is not continuously visible, the agent will act on stale context instead of current intent.

Completion gates matter more than eloquent prompts: the most important safeguard is the inability to exit with unfinished tasks. That is a control design choice, not a model-behaviour hope, and it is the kind of structural guardrail AI programmes will need as agents take on more production work. The practitioner lesson is to enforce closure conditions in the architecture, not in the prompt.

Agent workflows are starting to resemble non-human identities: once a system has tasks, progress markers, blocking states, and finish authority, it needs governance that looks closer to identity lifecycle management than to simple automation. This is where NHI thinking becomes relevant to agentic AI: the issue is not just what the agent can do, but how its work is tracked, constrained, and formally concluded. Practitioners should design agent control planes with explicit state ownership and termination rules.

Planning architecture is now a differentiator in agent reliability: the interesting divide is no longer between agents that use tools and agents that do not. It is between agents whose workflow is structurally governed and those that rely on prompt discipline alone. The field should expect planning, state visibility, and completion enforcement to become baseline design expectations for serious production agents.

What this signals

Plan state is becoming the core control for agent reliability: once an agent can take several actions in sequence, the main question is not whether it can reason, but whether the current task remains visible to the system that is executing it. That is a control design problem, and it will increasingly separate fragile agents from governed ones.

Non-human workflows need termination rules, not just instructions: agents that can write, read, and update their own tasks need explicit closure conditions because conversational confidence is not proof of completion. For practitioners, the lesson is to design agent loops with structural end states, blocked handling, and auditable task status from the start.

For practitioners

• Implement structured planning tools Expose plan creation, update, and read functions as structured tool calls so the agent can write machine-readable task state instead of free-form text.
• Pin the active plan in a fixed context position Inject the current plan immediately after the system prompt on every loop so the model always sees task status before processing conversation history.
• Enforce completion gates before finish Reject any finish attempt while tasks remain pending or in progress, and return the incomplete items so the agent must resolve them or mark them blocked.
• Use blocked status for human-in-the-loop pauses Allow tasks to move into blocked only when the agent genuinely needs user input or another missing dependency, then resume from the preserved plan state.

Key takeaways

• Multi-step agents fail when planning is left as an informal prompt instead of an enforced workflow state.
• The decisive controls are visible task state, fixed plan placement, and a hard stop on unfinished work.
• For practitioners, planning now belongs in the agent control plane, especially where non-human workflows need accountable completion.

Key terms

• Planning Message: A planning message is a durable, structured representation of an agent's current task list and execution state. It gives the system and the model a shared view of what remains to be done, rather than relying on hidden reasoning or conversational memory.
• Finish Gate: A finish gate is a control that blocks an agent from ending a task until all required steps are complete or explicitly marked blocked. It converts completion from a behavioral hope into an enforceable condition checked by the runtime.
• Task Status Model: A task status model is the finite set of states used to track work as it moves through an agent workflow, such as pending, in_progress, completed, and blocked. It makes progress observable and allows the system to validate whether the agent is actually advancing.
• Agent Planning Architecture: Agent planning architecture is the set of runtime controls that preserve, surface, and enforce an agent's intended sequence of work. It includes how plans are created, where they are injected, how they are updated, and what stops the agent from finishing too early.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and workload identity through an identity-security lens. It helps practitioners connect agent control design to the governance patterns their programmes already depend on.