Field Notes: AI Agents Are Separating Plans From Permission

An AI agent can produce a sound plan without being entitled to execute it. That distinction is becoming operationally important as agents move from drafting and analysis into systems that can send messages, change records, initiate purchases, or alter production environments.

The emerging design pattern is a separation between plan authority and execution authority. The model may inspect context, compare options, and propose a sequence of actions. A separate control layer decides whether those actions are permitted, whether approval is required, and whether the approved plan still matches the environment at execution time.

This is more than conventional access control. Access control answers, “Can this identity call this tool?” Plan-aware permission asks, “May this specific action, for this purpose, under these conditions, happen now?”

What changed: agents now prepare actions before they perform them

Early tool-using assistants often combined reasoning and execution in one loop. The model selected a tool, supplied arguments, observed the result, and continued. That pattern remains useful for low-risk retrieval, but it becomes fragile when a tool call creates an external commitment.

Newer operating patterns introduce an intermediate artifact: a proposed plan, change set, transaction preview, or execution manifest. The exact format varies, but the mechanism is consistent. The agent states what it intends to do before the system grants the capability to do it.

A useful plan artifact contains more than prose. It identifies the target, operation, material inputs, dependencies, expected effect, validation method, and conditions that should stop execution. For example, “resolve the customer issue” is not an approvable plan. “Issue a replacement for order A, waive standard shipping, add case note B, and send template C after confirming the delivery address” is closer to one.

This separation creates a stable object that policy engines, reviewers, and audit systems can inspect. It also prevents conversational approval from becoming an unrestricted license for whatever the model decides next.

Why ordinary role-based access is not enough

Role-based access control is necessary, but its unit of control is usually too broad for an adaptive agent. A service account may be allowed to update customer records, yet that does not mean every proposed update is appropriate. The risk sits inside the arguments, timing, purpose, and sequence of calls.

The practical answer is layered control. Identity limits the available surface. Schemas constrain arguments. Policy evaluates business rules. Approval covers consequential judgment. Runtime checks ensure the approved assumptions remain true.

None of these layers should rely on the model merely saying that it complied. Enforcement belongs outside the model, close to the tool or transaction boundary.

What it means in practice: approval must bind to a specific plan

A weak approval flow asks, “Should I proceed?” The operator sees a summary, clicks approve, and the agent continues reasoning. If the agent changes the recipient, quantity, account, or sequence afterward, the original approval may still be treated as valid.

A stronger flow binds approval to a canonical representation of the plan. The approved object can include exact tool operations, constrained ranges, and named preconditions. Any material mutation invalidates the approval and triggers a new review.

A worked procurement example

Suppose an operations agent is asked to replenish packaging. It finds recent consumption, checks approved suppliers, and prepares a purchase order. The proposal specifies the supplier, item identifiers, quantities, delivery location, payment terms, and maximum total. A manager approves that object.

Before execution, the supplier system reports that one item is unavailable. The agent finds a substitute with a different specification and higher total cost. A conversational system might treat substitution as normal plan adaptation. A permission-separated system recognizes that the approved object has changed. It may allow the agent to prepare a revision, but it does not inherit permission to submit it.

The point is not to prohibit adaptation. It is to distinguish replanning from authorization.

The hidden problem: plans decay

Even an unchanged plan can become unsafe because the world changes between approval and execution. Inventory moves, exchange rates change, incidents are resolved, customer records are edited, and another operator may complete the same task.

This creates a form of permission decay. Approval was rational under one state; execution occurs under another. Systems therefore need explicit invariants rather than relying only on an approval timestamp.

• Object invariants: The target account, order, file, or environment is unchanged.
• Value invariants: Amounts, quantities, dates, and thresholds remain within the approved bounds.
• State invariants: The case is still open, the deployment version is still current, or the invoice remains unpaid.
• Dependency invariants: Required checks, signatures, or upstream jobs have completed successfully.
• Uniqueness invariants: The action has not already been performed through another channel.

If an invariant fails, the correct response is usually not blind cancellation or autonomous improvisation. The agent should explain what changed, revise the plan, and request only the additional decision that the change requires.

Approval interfaces need to show consequences, not reasoning theater

Long model explanations do not necessarily improve oversight. Reviewers need decision-relevant facts: what will change, where, at what cost, with which exceptions, and how the action can be reversed.

A useful approval view should present the proposed external effects, policy exceptions, unresolved assumptions, source state, and rollback path. It should also distinguish generated recommendations from verified system facts.

Consider a customer-support agent proposing a refund. The reviewer needs the order amount, refund amount, refund destination, policy basis, prior concessions, and whether the shipment can still be intercepted. A paragraph describing the model’s reasoning process adds less value than those concrete fields.

Approval design should also prevent “approve all” fatigue. Routine actions within narrow policy limits can be pre-authorized. Novel, irreversible, unusually large, or exception-bearing actions should receive focused review. The objective is not maximum human involvement; it is human attention at the point where judgment changes the outcome.

A practical architecture for plan-bound execution

Operators do not need an elaborate autonomous-agent platform to implement this pattern. A small set of components is sufficient:

1. Planner: Produces a structured proposal without credentials that can create the final external effect.
2. Resolver: Converts references into current system objects and retrieves the state needed for review.
3. Policy layer: Classifies actions as pre-authorized, approval-required, or prohibited.
4. Approval service: Records the exact plan, approver, scope, conditions, and expiry criteria.
5. Executor: Receives short-lived authority limited to the approved operations.
6. Verifier: Rechecks invariants before execution and validates the result afterward.

The short-lived execution grant is important. The planner should not retain standing credentials merely because one plan was approved. Where possible, the executor should accept only declared operations rather than arbitrary instructions. For database work, that may mean a constrained command service instead of direct query access. For communications, it may mean a send endpoint that accepts an approved recipient, template, and bounded variables.

This architecture also makes partial failure manageable. If action three of five fails, the system knows which effects occurred, which remain pending, and whether compensation is possible. The agent can propose recovery without pretending the original transaction completed cleanly.

What remains unresolved

The first unresolved issue is plan granularity. Plans that are too broad provide weak control; plans that are too detailed create approval overload and break whenever a harmless parameter changes. Organizations need a definition of “material change” for each workflow. A shipping-method substitution may be immaterial in one process and contractually significant in another.

The second issue is delegation across agents. A planning agent may ask a specialist agent to price options or schedule work. Permission should not automatically propagate through that chain. Systems need clear rules for whether a delegate is gathering information, preparing a sub-plan, or exercising authority.

The third issue is emergency adaptation. Production incidents sometimes require rapid changes when prior assumptions fail. Strict reapproval can increase operational harm, while broad emergency authority can become a bypass. A defensible design uses narrow break-glass permissions, explicit logging, limited duration, and mandatory after-action review.

The fourth issue is semantic equivalence. Two plans may differ textually but produce the same effect, while a small textual edit may create a materially different obligation. Deterministic comparison works for structured fields; judging equivalent intent remains harder. The safest approach is to define equivalence at the tool and business-rule level rather than asking a model to decide whether its own revision is harmless.

The operating test

Before connecting an agent to a consequential tool, ask one question: Can the system prove that the executed action is the action that was permitted?

If the answer depends on chat history, model memory, or a generic approval button, the control is weak. If the system can point to a specific plan, bounded authorization, verified preconditions, execution record, and observed result, the control is operational.

The durable shift is not toward agents that ask permission more often. It is toward systems that know exactly what permission applies to—and that can plan freely without confusing a good idea with the right to carry it out.

This post was drafted with AI assistance and reviewed against our editorial policy before publication. Corrections are made at the source, on the page, with the date shown.