An intelligent executor is an agent with a narrow mandate: it may adapt to states that were not known in advance, but only to achieve the typed purpose of its executor.
| Property | Regular executor | Intelligent executor |
|---|---|---|
| Public contract | Typed input and output | Unchanged |
| Execution | Direct procedure | Bounded adaptive loop |
| Purpose | Fixed by the executor name | Unchanged and not redefinable by the model |
| Authority | Manifest capabilities and gates | Unchanged; it cannot extend itself |
| Outcome | Schema and postconditions | Unchanged, including explicit failure |
Operationally it is a real agent: it observes, selects a step, acts, and verifies. Architecturally it remains an executor because it cannot change its goal, invoke unrelated capabilities, or invent an output format.
The mandate is defined by the executor name and description, argument schema, declared capabilities, consent policy, budgets, and postcondition. The internal model receives only the minimum necessary observation and chooses inside an action space fixed by code.
The planner does not know the internal transitions. To it, login_sites(session_ids) still returns authenticated sessions or a reason for not signing in, even if it internally had to find the sign-in area, cross several screens, or hand 2FA back to the user.
The general loop is observe → resolve → verify preconditions → gate → execute → verify postconditions. Each iteration consumes a step and time budget. Deterministic resolvers run first; a local model handles only residual ambiguity and may select only runtime-enumerated objects.
The loop ends with verified success, an explicit user handoff, or a typed error. It cannot continue indefinitely, weaken policy, approve its own action, or turn an unverified postcondition into success.
The approach is general when the purpose is narrow but the path varies: web login, interface navigation, recovery from variable API responses, multi-stage wizards, and locating an object in an observable structure. It requires a limited action space, observable progress, and a verifiable postcondition.
It is not suitable for open-ended research, cross-domain strategy, or creative tasks without a completion criterion. Those belong to the planner. login_sites and bounded act_sites navigation are the first implementations, not a privileged documentation domain.
An intelligent executor fails closed: it returns the same public schema with a causal code, keeps only state required for a safe handoff, and does not invent an outcome. CAPTCHA, external confirmation, or unresolved ambiguity become explicit user requests; exhausted budgets, unstable targets, and absent postconditions become verifiable errors.