Planning architecture is what makes agents complete multi-step work

At a glance

What this is: This is an analysis of why agents fail on multi-step work and the architectural patterns that make planning durable.

Why it matters: It matters because identity and access teams now have to govern AI agents that hold context, invoke tools, and complete work across multiple steps without losing control of task scope or completion state.

👉 Read Arize's analysis of planning architecture for multi-step AI agents

Context

Agent planning fails when task state lives only in prompt text and gets buried under tool output, session history, and repeated model turns. In practice, that creates a governance gap: the system can have access, but it cannot reliably remember purpose, sequence, or completion criteria. For identity and security teams, this is the same structural problem that appears when a privileged workflow has no durable state or enforceable boundaries.

The article is primarily about agent architecture, but it has a real identity angle because AI agents increasingly behave like governed software entities with tool permissions, task scope, and runtime state. That makes the planning layer relevant to NHI governance, especially where agents can call external tools, chain actions, or operate with delegated access. For practitioners, the question is not just whether the agent can act, but whether its actions remain inspectable, bounded, and auditable.

Key questions

Q: How should security teams govern AI agents that run long, multi-step workflows?

A: Security teams should require durable execution, full event history, and clear ownership for every multi-step agent workflow that touches sensitive data or privileged tools. If the agent can lose state on failure, the organisation cannot reliably audit what happened or prove which actions were completed versus replayed.

Q: Why do AI agents fail when planning is only a prompt instruction?

A: Prompt-only planning creates text the model can ignore, forget, or bury under later tool output. As context grows, the original task loses priority and the agent can stop early or drift off script. A structured planning layer is more reliable because the system can inspect and enforce it.

Q: What breaks when an agent cannot track task status during execution?

A: Without explicit task status, the agent cannot distinguish active work from finished work or blocked work. That leads to premature finish calls, missing steps, and false confidence that a request is complete. The problem becomes worse in long workflows where tool output crowds out the original intent.

Q: How do you know if an agent planning system is actually working?

A: Look for reliable multi-step completion, fewer looped tool calls, and successful finish calls only after all tasks are resolved. If the agent regularly forgets the last step, drifts after several tool calls, or needs repeated resets, the planning layer is not being enforced strongly enough.

Technical breakdown

Why prompt-based planning breaks under tool load

Prompt instructions such as “think step by step” create text the model may follow, but the system cannot reliably inspect or enforce. Once tool outputs and API responses fill the context window, the original task becomes less salient and the agent drifts into partial completion or premature finish. The failure is not model stupidity. It is a state-management problem where the plan is not treated as first-class runtime data.

Practical implication: Use structured plan state, not prompt advice, when a task must survive multiple turns.

Structured planning tools create enforceable task state

A durable agent plan needs explicit lifecycle objects. In the article’s architecture, todo_write, todo_update, and todo_read let the system represent work as structured tasks with statuses such as pending, in_progress, completed, and blocked. The in_progress state matters because it creates a visible working pointer, while blocked preserves human intervention without pretending the task is done. This is closer to operational control than prompt design.

Practical implication: Model task state as machine-readable objects so the runtime can validate progress and completion.

Fixed plan injection and finish gates preserve execution integrity

The PlanMessage pattern keeps the plan directly after the system prompt on every iteration, ahead of session history and current-turn noise. That positioning reduces context drift because the plan stays visible even when the conversation gets long. The hard finish gate then prevents the agent from exiting with incomplete tasks, turning completion into a structural requirement rather than a behavioral preference. This is the difference between remembered intent and enforced workflow.

Practical implication: Pin the current plan into the prompt stack and block completion until every task is resolved or explicitly blocked.

NHI Mgmt Group analysis

Planning state is now an identity control problem, not just a UX problem. When an AI agent can select tools, carry context, and continue work across iterations, its planning layer becomes part of the control plane. If that state is only expressed in free-form text, it is neither enforceable nor auditable. For NHI and agentic AI programmes, the practical conclusion is that plan persistence belongs in governed runtime state, not conversational memory.

Structured task status is a governance primitive for autonomous work. The move from two task states to four is more than implementation detail because blocked and in_progress make hidden failure modes visible. That visibility matters when an agent is acting as a delegated software entity with temporary access to tools or data. A policy model that cannot distinguish active work from incomplete work will overtrust the agent’s apparent success.

Completion gates are the agent equivalent of Zero Standing Privilege for workflow execution. If an agent can end a task while work remains unresolved, the system has granted effective standing authority over closure. The article’s hard gate shows the opposite model: finish is earned only when all task obligations are satisfied or explicitly blocked. That is a cleaner fit for agent governance than relying on model self-attestation.

Planning also exposes the boundary between orchestration and autonomy. The article shows that an agent can become a workflow orchestrator when it can chain prompts, preserve intermediate state, and decide what to do next. That capability is useful, but it also raises the governance bar because tool access, task sequence, and termination criteria now matter as much as model quality. Practitioners should treat plan execution as a governed permission set, not a pure reasoning problem.

What this signals

Agent planning is becoming a control boundary for AI systems that behave like software identities. Once an agent can retain task context, invoke tools, and decide when to stop, organisations need to govern execution state with the same seriousness they apply to privileged access and service account lifecycle controls. The relevant question is no longer whether the model can reason, but whether the workflow can be bounded, inspected, and shut down cleanly.

Planning-state drift: the failure mode here is not simply bad prompting, but the loss of durable task intent as context grows. That makes the runtime plan a security object in its own right, especially when the agent can reach external tools or production data. For teams aligning to the OWASP Agentic AI Top 10, task persistence and finish enforcement are governance controls, not product features.

AI governance teams should expect more agent frameworks to converge on structured task objects, explicit blocked states, and enforced completion checks. That shift aligns with the NIST AI Risk Management Framework because it turns autonomous execution into something measurable, reviewable, and policy-bound rather than purely conversational.

For practitioners

• Define planning as a governed runtime object Store plan state outside free-form conversation history so the agent can inspect, update, and validate tasks across turns. This makes completion checks and audit logging possible when tool calls pile up.
• Add an explicit in_progress state Use at least four statuses for agent work: pending, in_progress, completed, and blocked. Without in_progress, operators cannot tell whether the agent is actively working or has simply not updated its plan yet.
• Pin the current plan to every iteration Inject the active plan immediately after the system prompt and before session history so the agent always sees task intent ahead of noisy tool output. Rebuild that message from live state each turn.
• Block finish until work is resolved Reject any completion attempt if tasks remain pending or in_progress, and require the agent to mark items blocked when user input is needed. That prevents false completion and preserves workflow integrity.
• Trigger planning only when task complexity warrants it Use simple heuristics, such as two or more requested actions, to decide when a plan is necessary. Single-step requests should remain fast and direct so planning does not become overhead.

Key takeaways

• Planning only works when it is treated as governed state, not as a prompt-level suggestion.
• Structured task statuses and finish gates turn agent execution into something the system can enforce.
• As agents take on more workflow orchestration, identity, privilege, and completion control become part of the same governance problem.

Key terms

• PlanMessage: A PlanMessage is a dedicated runtime message that carries the current task plan into the agent context on every iteration. It keeps work state separate from general conversation history so the system can inspect, update, and enforce progress without relying on free-form memory.
• Blocked Task State: Blocked task state marks work that cannot continue until a missing dependency, user decision, or external input is provided. It prevents an agent from pretending a task is complete and gives operators a clean way to distinguish unfinished work from legitimately paused work.
• Structured Planning Tool: A structured planning tool is a machine-readable function that lets an agent create, update, or inspect work items as data rather than prose. This makes planning auditable and enforceable, which is essential when an agent is orchestrating multi-step actions across tools and sessions.
• Completion Gate: A completion gate is a runtime check that prevents an agent from ending a workflow while tasks remain unresolved. It converts completion from a model preference into a system rule, which reduces false finish states and improves operational reliability.

What's in the full article

Arize's full article covers the implementation detail this post intentionally leaves at the architectural level:

• The exact prompt and tool patterns used to create todo_write, todo_update, and todo_read in production
• The PlanMessage formatting approach, including how the plan is pinned ahead of session history
• The finish-gate enforcement logic that rejects incomplete task closure
• The heuristics used to decide when planning should trigger for multi-step requests

👉 Arize's full post covers the planning loop, task-state design, and enforcement pattern in more implementation detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It is designed for practitioners who need a practical framework for governing delegated software entities and access lifecycle controls.