Separating planning and execution in agent systems

A plan is not an execution log

An agent can produce an excellent sequence of steps and still be unsafe to run. The plan may be based on incomplete context, a tool call may have a larger effect than its description suggests, or the process may crash after an external action succeeds but before the agent records it. If planning and execution share one conversational stream, it becomes difficult to answer three basic questions: what was intended, what was authorized, and what actually happened?

The remedy is a set of explicit state boundaries.

Treat the plan as a reviewable artifact, execution as a durable state machine, and verification as evidence—not as the agent's final sentence.

This design does not make an agent less capable. It gives autonomy a shape that operators can inspect, pause, resume, and constrain.

Resolve ambiguity before effects begin

The first boundary is the request. A natural-language instruction often omits scope, completion criteria, authority, or risk tolerance. “Deploy this,” for example, may mean create a preview, update a production route, migrate data, or only report readiness.

Before execution, the system should produce a normalized mission containing:

• the objective and explicit non-goals;
• resources and people in scope;
• success evidence;
• constraints on time, cost, data, and external effects;
• decisions that still require human input.

Low-risk unknowns can be resolved through read-only inspection. A choice that would materially change the result or authorize an irreversible action must remain visible instead of being guessed away.

This mission becomes the input to planning. It should not be silently rewritten by tool output later in the run.

Make the plan a versioned artifact

A plan is a proposed route from the current state to the objective. Each step should identify its expected effect, dependencies, verification, and rollback or recovery path. The plan can change as evidence arrives, but changes should create a new version with a reason.

A useful plan record contains:

plan_id
version
mission_id
assumptions
steps[]
risk classification per step
required approvals
expected evidence
created_at

Approval should bind to a specific plan version. Otherwise a plan can be approved and then materially changed without review. Small operational details can remain flexible, but the boundary should be explicit: replacing one read-only data source may be allowed; adding a production write is a new plan.

The plan also should not claim that a step has happened. “Run tests” belongs in the plan. The test command, exit status, timestamp, and artifact belong in execution evidence.

Model execution independently

Execution is a sequence of durable attempts against plan steps. Each step can move through states such as ready, running, waiting_for_approval, blocked, verifying, succeeded, or failed. The current state should live outside the model's prose so a reconnect or provider change does not erase it.

Each execution attempt should record:

• the exact tool and normalized arguments;
• the actor, policy, and plan step that authorized it;
• start and completion timestamps;
• outputs or references to outputs;
• whether an external effect may have occurred;
• the verification result.

This is especially important when the same step is retried. An execution retry is not simply another model turn. The runtime must decide whether it is repeating a read, resuming an interrupted operation, or risking a second side effect.

Put approvals at the effect boundary

Approval is most useful immediately before the protected action, with the exact arguments visible. Approving “deploy the app” at the beginning of a long plan is weaker than approving “route v2.example.com to deployment X” after the deployment has been inspected.

Classify tools or actions by effect:

• read-only — inspection, search, calculation;
• reversible write — draft creation, preview deployment, branch push;
• externally visible write — publication, message send, DNS or routing change;
• sensitive or irreversible effect — payment, deletion, credential or access change.

Policy can pre-authorize some categories while requiring approval for others. OpenAI's Agents SDK exposes this pattern directly: a protected tool call pauses the run, returns an interruption, and resumes from stored run state after approval or rejection. OpenAI's practical guide similarly recommends human intervention for high-risk actions and repeated failures.

An approval record should include the tool, normalized arguments, plan version, approver, decision, and expiry. If arguments change after approval, the action should be reviewed again.

Checkpoint before and after side effects

Long-running agents must survive process failures without repeating uncertain work. A checkpoint should capture the mission, plan version, execution state, pending approvals, and references to completed evidence.

The most important checkpoints surround effects:

1. persist the intent and exact action before calling the tool;
2. execute using a stable operation or idempotency identifier when available;
3. persist the result and external reference;
4. verify the resulting state;
5. only then mark the step complete.

If the process dies between steps 2 and 3, the state must be outcome_unknown, not automatically retried. Recovery first queries the external system with the stable identifier. This is the same uncertainty problem found in payment APIs.

LangGraph's persistence model saves graph state as checkpoints and supports interrupts that can resume later. Its documentation also notes that resumed work restarts at a node boundary, which is why side effects inside a node need deterministic or idempotent handling. A framework can provide persistence, but the application still has to choose safe checkpoint boundaries.

Verification is a separate phase

An agent saying “done” is not evidence. Verification should be defined by the mission and performed after the effect, preferably through an independent observation path.

Examples include:

• a deployed URL returns the expected commit and visible UI;
• a database migration status shows no pending migration and a representative read succeeds;
• a pull request check is green and the target branch contains the merge commit;
• a generated media file passes technical inspection and a visual quality gate;
• an external record appears in the authoritative service, not only in a local response.

The evidence record should say what was observed, when, by which method, and what it proves. A build proves compilation, not production behavior. An HTTP 200 proves reachability, not that the correct content was deployed.

OpenAI's Agents SDK tracing records model generations, tool calls, handoffs, and guardrails. Tracing is valuable for reconstruction, but product verification still needs domain-specific assertions. Logs explain the path; checks establish the outcome.

Provider fallback must not replay effects

Model providers can fail, rate-limit, or lose context. Provider fallback is safe during planning or read-only synthesis when the input artifact is stable. It is dangerous in the middle of an effectful step if the new provider cannot see whether the prior tool call took effect.

Fallback should therefore occur at a checkpoint boundary. The replacement provider receives the mission, approved plan version, current execution state, pending decision, and evidence references—not an unstructured transcript alone. It may continue from ready or verifying; it should not reinterpret outcome_unknown as permission to execute again.

Policies also belong outside the provider prompt. Cost limits, allowed tools, approval requirements, and data boundaries must remain enforced even if the model changes.

A five-record operating model

A practical implementation can begin with five durable records:

1. Mission — objective, constraints, scope, success evidence.
2. Plan — versioned steps, assumptions, risks, approval requirements.
3. Approval — decision bound to an exact action and plan version.
4. Execution — attempts, state transitions, external references, unknown outcomes.
5. Evidence — observations that justify completion or rejection.

The JARVIS case study applies missions, executions, approvals, workspaces, provider policies, and an operator HUD. Arc focuses on StateGraph planning, streamed step state, and checkpoint-based resume. Project Agora adds a different boundary: agent work is submitted and later verified through protocol rules. Together they point to the same method—separate proposing, authorizing, acting, and proving so that every transition remains understandable.

Review questions

Before allowing an agent to run a plan, ask:

1. Is the objective normalized, and are non-goals explicit?
2. Can an operator review the exact plan version being authorized?
3. Does each effectful step have a risk class and recovery path?
4. Are approvals attached to exact tool arguments near execution time?
5. Can the run resume without replaying an uncertain side effect?
6. Is completion based on independent evidence?
7. Can a different provider continue from durable state without gaining new authority?

An agent system becomes operable when these questions have durable answers. Intelligence chooses a route. The runtime preserves intent, authority, state, and proof while that route meets the real world.