How to Stop Planner-Executor Agents From Doing the Right Task the Wrong Way Right Now

Planner-executor patterns look safe because one agent "thinks" and another agent "does." But if the executor can reinterpret the plan however it wants, you have not really reduced risk. You have just spread it across two components.

What "Stop Planner-Executor Agents From Doing the Right Task the Wrong Way Right Now" actually means

Planner-executor failures happen when the planner’s intent is underspecified relative to the executor’s action authority, leaving the execution layer too much room to improvise on consequential steps.

If you are asking this question, the pain is usually immediate: the plan sounds right, but the execution path still has unsafe discretion. Architects designing composed agent systems are not looking for a category lecture in that moment. They need a way to stop the behavior, narrow the blast radius, and create enough evidence to decide whether the agent should keep acting at all.

What to do in the next hour

1. Define which parts of the plan are instructions, constraints, and non-negotiable prohibitions.
2. Limit executor authority to the exact action classes the plan explicitly allows.
3. Require the executor to surface ambiguity instead of silently filling it in.
4. Inspect recent runs for where the executor exceeded or reinterpreted the plan.
5. Add verification between planning and execution for risky actions.

The order matters. Teams get into trouble when they jump straight to prompt edits, add a bigger system prompt, and then tell themselves the issue is handled. That can quiet one visible symptom while leaving the original permission, workflow, or evidence gap untouched.

What not to do when an agent is doing the wrong thing

• Do not assume splitting cognition and execution automatically creates safety.
• Do not let executors inherit broad tool access just because the planner is separate.
• Do not use natural-language plans as the only control surface for consequential actions.

Most "rogue AI" incidents are not dramatic jailbreak movie scenes. They are dull operational failures: a tool should not have been callable, an approval path was missing, context was stale, or nobody could tell whether the agent was still inside its intended scope. Those failures are fixable, but only if you treat them like control problems instead of personality problems.

The red flags that mean you are already late

• Executor tools are broader than the plan’s explicit scope.
• The system cannot show which constraint was active at execution time.
• Executors rarely escalate ambiguity because the workflow over-rewards completion.
• Postmortems cannot tell whether the planner or executor deviated first.

A useful rule of thumb is this: if the only explanation you can give leadership is "the prompt probably drifted," you do not yet have a real operating model. You have a hypothesis. Mature teams replace hypotheses with enforceable boundaries, clear approvals, and a review trail.

Architectural separation vs constraint-preserving execution

Architectural separation is useful, but constraint-preserving execution is what actually reduces risk. Without that, the planner-executor split becomes a false sense of discipline.

This distinction matters because teams under pressure often buy more observability before they define a stop condition. Observability is useful, but it does not prevent a bad action by itself. A useful control changes what the agent is allowed to do, under which conditions, with what proof, and who gets pulled in when the answer is "not yet."

How Armalo helps you stop the wrong action without pretending the problem is solved

• Pacts can define what the executor must preserve from the planner and what always requires re-approval.
• Evaluations can test whether the executor oversteps when the plan is tempting but incomplete.
• Audit trails make it easier to attribute deviation to planning, execution, or interface design.
• Trust surfaces let teams compare executor discipline across workflows instead of relying on anecdote.

That combination is the painkiller. Not "AI governance" in the abstract. A concrete way to define what the agent is allowed to do, independently evaluate whether it stayed inside those boundaries, publish a defensible trust surface, and attach real operational consequence when it does not.

Tiny proof

if (!plan.allowedActions.includes(candidateAction.kind)) {
  return { decision: 'reject_execution', reason: 'executor exceeded plan authority' };
}

Frequently asked questions

Is planner-executor still a good pattern?

Yes, but only when the interface between planning and execution preserves constraints clearly. The split helps most when the executor is easier to bound, not when it becomes a second improviser.

What should stay explicit in the plan?

Allowed actions, forbidden actions, risk thresholds, approval triggers, and environment or tenant constraints should be explicit enough that the executor does not need to guess.

Key takeaways

• A good plan is not enough if execution can improvise dangerously.
• Constraint-preserving interfaces matter more than architectural labels.
• Executor discipline is a trust surface of its own.

Next step: Read the docs, explore the trust surfaces, or email dev@armalo.ai if you need help turning a live incident into an operating control.