Agent inside.
Executor outside.
An intelligent executor can handle a changing route without changing its assignment. It observes, selects one step and verifies it; the planner still sees a regular executor.
The architectural boundary
The mandate comes from the name, description, argument schema, declared capabilities, consent rules, limits, and postcondition. The internal model receives only the observation it needs and may choose only among actions enumerated by the runtime.
Same shell, two execution modes
| Property | Direct executor | Intelligent executor |
|---|---|---|
| Public contract | Typed input and output | Identical |
| Route | Predetermined procedure | Adaptive, bounded loop |
| Purpose | Fixed by the name | Unchanged and not redefinable |
| Authority | Manifest and consent | Identical; it cannot expand itself |
| Outcome | Schema and postcondition | Identical, including explicit failure |
Where it earns its complexity
Good fit
A narrow purpose, a changing route, limited actions, observable progress, and a verifiable end state.
Examples include signing in to a website, multi-screen procedures, extracting variable structures, and choosing among equivalent controls.
Poor fit
Open-ended research, cross-domain strategy, or creative work without a crisp completion criterion.
Those decisions belong to the planner, not to a hidden executor.
A new language, layout, or screen sequence should be absorbed by the same executor. New code is warranted when an action primitive, observation channel, authority, or verifiable postcondition is missing: intelligence cannot invent sensors or permissions.
When it cannot finish
The executor fails closed: it returns a causal code in the public schema, keeps only the state required for safe resumption, and does not invent results. External confirmation or unresolved ambiguity produces an explicit user handoff; exhausted limits, an unstable target, and a missing postcondition produce distinguishable errors.