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.

To sign in, Metnos first looks for an authentication form. If none is present, it looks for an account entry, a menu, or a plausible intermediate step. It uses page signals first; only when those are insufficient does it ask the local model to choose among observed controls. There are no special navigation paths for individual sites.

A label such as “Private customers” or “customer area” can hint at a route to sign-in, but it is not itself a sign-in control. Metnos follows that clue only when it leads to a different page and no explicit entry is available; after a click, it also waits briefly for menus and forms that appear late. The terms come from its multilingual lexicon.

Search follows at most four steps along each path. At a dead end, it returns to the starting page, replays the verified path to a useful fork, and tries an alternative not yet attempted. Forward and return steps share a 32-action cap and a limited search time; waiting for consent does not reset the attempts. If the path changes in the meantime, Metnos stops.

A subsequent search for a complete collection distinguishes target objects, filters and requested fields. The local model interprets content by meaning and chooses only among observed controls. Relevant objects, including those outside the filters, guide navigation; their presence does not certify completion. Search explores up to three levels and returns through the starting page to try other branches. Pagination stays at the same level. After finding initial results it still looks for further pages and details needed for requested fields. Observed controls are examined in groups, so pages with many links do not hide later controls from the search.

This collection uses 96 actions and 300 active seconds, shared by forward steps, scrolling and returns; waiting for the user neither consumes active time nor resets attempts. It finishes after exhausting observed relevant paths. Time, action, depth or reading limits produce a partial result without inventing the total number of objects. Filters apply to collected records, without excluding paths because of dates on an intermediate page.

The usual site boundaries and consent forms still apply during search. Cookies use the separate procedure for rejecting optional choices, checked again before submission if a new banner appears. Once a form is found, credential entry remains deterministic: the model receives no field values and explores no further paths once typing begins.

Saving, listing, login and deletion share one encrypted credential vault. The list contains metadata only; changing the instance data directory does not select a different vault.

For supported Cloudflare challenges, Metnos tries the local playwright-captcha library once, in the same session, for no more than 10 seconds. The attempt counts towards the login limits and its result is checked against the page. It uses no paid service. If the challenge remains pending or is unsupported, such as reCAPTCHA, Metnos requests user intervention and keeps the session. OTP codes follow a separate procedure: the user provides them unless explicit permission for automation already exists. The CAPTCHA solver neither accepts cookies nor reads OTP codes.

The CAPTCHA panel shows the already open session, with sensitive fields hidden. The user can click, scroll, refresh the image and press Resume. Metnos checks the login again and continues the original request; an unresolved CAPTCHA opens the panel again. The check associates the response with its own widget, even if it remains visible after completion; another widget's response does not count. When the CAPTCHA preceded the form, Metnos now fills the credentials. If they were already submitted, it checks that attempt without submitting them again. The panel expires after ten minutes; cancelling closes its session. Challenges requiring keyboard or audio input are not supported by this panel.

For forms asking for email before password, the broker also uses the form's heading or accessible name and the validated multilingual lexicon. This works even when the URL contains no login terms. Text outside the form, such as a header link, does not turn a newsletter into a login. Ambiguous fields are not selected; authorized origins remain checked before filling and submitting credentials. Shared credential filling clears each field, enters its value and checks it before continuing; a mismatch prevents submission. Values stay inside the broker and are not returned or logged.

Post-submit observation uses the same criteria as final verification, including any declared session cookies. A generic cookie changing during loading does not end observation. The time limit, single submission and separate handling of CAPTCHA, codes and rejections remain unchanged.

Continuations after a form or consent use the ordinary turn log. Each resume has a new identifier linked to the paused turn and preserves the owner, conversation, outcomes and attachments. Image links resolve through this persisted record. The resumed branch and remaining steps are observed without replaying previous steps; form inputs are not copied into the logged arguments.

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.