Agent inside.
Executor outside.

An intelligent executor uses a model to resolve one or more uncertain steps while keeping the ordinary executor contract. The planner gives it a precise task and receives the expected result without having to know its internal route.

Core idea. The model may propose how to proceed within a bounded set of possibilities. This does not grant it new permissions or let it decide by itself what counts as success.

Stable contractArguments, authority, and result shape do not change when the model is involved.

Bounded choiceThe model proposes only values or actions that the adapter knows how to validate.

Verified outcomeThe executor's postcondition, not a model's claim, determines whether an attempt succeeded.

The architectural boundary

The executor's manifest and code define its purpose, arguments, capabilities, consent, limits, and result shape. When part of the route needs a model, the adapter prepares a bounded observation, validates the proposal, and decides which concrete operation to run. The model does not invoke executors directly or alter its own contract.

In a manifest, intelligence = "agentic" declares this mode so that the registry and interface can represent it correctly. The declaration is validated, but it does not prove that an implementation is safe: proposal limits, validators, and postconditions must still be checked in code and tests.

The shared loop limits attempts, elapsed time, history, and observation size. The adapter retains control of the action.

What the shared runtime provides today

Metnos provides both synchronous and asynchronous loops. On each attempt, the loop may refresh the observation, request a proposal, validate it, execute it, and check its postcondition. The internal outcome is completed, inconclusive, or exhausted. A deterministic-first variant is also available: when the model fallback fails to produce a valid improvement, the initial deterministic result is retained.

Responsibility	Shared runtime	Executor adapter
Limits	Caps attempts, elapsed time, history, and observations	May choose tighter limits and must bound each individual operation
Proposal	Requests it and manages the loop	Decides what the model may see and propose
Validation	Never executes a rejected proposal	Defines the concrete admission rules
Success	Returns the loop outcome	Defines and checks the postcondition
Authority	Does not expand it	Operates within the manifest, policy, consent, and sandbox

The loop's elapsed-time limit does not automatically cancel an operation that has already started. It stops further attempts. The adapter must give each operation its own timeout, especially when that operation can change data.

Where it is used

Controlled selection

During web navigation, the model may choose a control identifier from candidates prepared by the broker. It cannot produce CSS or XPath selectors.

During image search, it may reorder known identifiers when metadata provides no useful lexical signal.

Controlled fallback

OCR tries Tesseract first. Only when the text is insufficient may it ask the vision model for a transcription; a weak result does not replace the original.

Structured extraction and some consultation paths apply the same principle under their own contracts.

A model is useful when the purpose is narrow, the route may vary, and the end state is verifiable. It is not a good way to hide open-ended research, cross-domain strategy, or a task without a crisp completion criterion inside an executor. Those decisions belong to the planner.

When it cannot finish

If no proposal is admitted, the loop is inconclusive. If its attempts or elapsed-time budget runs out, it is exhausted. The adapter then maps that outcome to its executor's public contract: it may keep the deterministic result, return a typed error, or request user intervention. The shared loop does not invent a result or promise persistent resumption by itself.

Transport and intelligence are independent. A local or remote executor may be direct or intelligent. Transport determines how it is reached; the manifest, policy, and code determine what it may do.