Executors that use a model

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.

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.

Where it is used

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.

Placeholders are allowed only in generative examples. Website observations and results retain the data actually observed or state its absence; a placeholder does not establish that an item was found.

Signing in to a website

Metnos first looks for a sign-in form. If it cannot find one, it follows relevant account links and menus. It uses signals from the page; when these are insufficient, the local model chooses among controls actually observed. It does not invent links or use routes written for individual websites.

A preference between signals counts only when it singles out a control. Some pages use the sign-in word as a generic verb, such as “Access” followed by many different sections: that word does not identify the entry and does not hide the one control the whole evidence designates unambiguously, such as “Customer area”.

The search explores up to four steps per route, with a shared limit of 32 actions. At a dead end, it returns to a verified branch and tries an alternative. If the page has changed during that return, it discards the branch and returns to the original entry for a fresh observation, keeping attempted controls and limits. This restart is available only before credential use and does not repeat the discarded branch. An ambiguous control still stops the search. A temporary panel covering the page, even one drawn inside an iframe, is closed only through a safe exit that neither navigates nor submits data. Pausing for consent does not reset attempts.

After a click, it also waits for a delayed form or new tab within the search time budget. An entry already tried is not treated as a new alternative. New tabs pass through the same authorized website checks.

Once a form is found, the browser component enters credentials without giving them to the model. It checks the authorized website and field values before submission. An ambiguous form or an unexpected value prevents submission. In two-step forms, it distinguishes the email address from the password; a sign-in link elsewhere on the page does not turn a newsletter form into a login form.

After submission it observes the page for a bounded interval. Sign-in evidence that appears within that interval completes its own stability check, for at most the observations the check requires; later, interrupted or unobservable evidence remains unverified. When the form submits by script and its own request has not answered yet, observation extends once by one more interval. A page already loading the next document, as in single sign-on redirects, is not an outcome yet: observation and collection wait for that document.

Saving, listing, using, and deleting credentials share one encrypted store. Listings show metadata only. Values do not appear in results or logs, and changing the instance data directory does not select a different store.

Collecting data across pages

A request such as “collect all invoices from 2026” requires Metnos to distinguish the objects sought, the filters, and the fields to extract. Finding the first list does not finish the job: Metnos also looks for next pages, archives, other periods, and details needed for the requested fields. Visible controls are examined in groups, so a long page does not hide later ones.

The search explores up to eight levels. Expansions of the same list, such as the next page, remain at the same level, as do buttons that change the page in place (a menu, the full list); that state explores only what the change revealed. A detail view enriches an item already found. Forward navigation, scrolling, and returns share 256 actions and ten minutes of active work. Waiting for the user does not consume that time or reset the attempts. Each local model decision has 20 seconds, included in the overall time limit.

On returning to a page, Metnos finds previously verified controls without repeating unnecessary clicks. Identical buttons are distinguished by the visible text of their own row. Indistinguishable rows remain ambiguous; hidden text and editable values do not distinguish them. A control that cannot be identified reliably is not chosen by its position.

After clicking a link to another page, Metnos waits for the navigation to complete. If the page instead answers in place, requesting only data without loading a new document, and then stays idle, the wait ends at once; without that evidence the normal wait applies.

A textless layer covering the whole window, while no visible control can be reached, is treated as loading: Metnos waits for it to disappear, within the usual bound, before reading the page or closing a dialog underneath. Dialogs, panels and written messages that offer something to press are not treated as veils.

Loading checks: an error, timeout or invalid result from the loading check does not establish that the page is ready. Metnos observes again within the same deadline, including the time spent on checks. A page immediately observed as stable needs no extra pause.

Likewise Metnos waits for data the page is still downloading, such as a list of bills that appears after the page opens. A request that stays open beyond the bound, such as a permanent connection, does not block reading: the page is read as it is.

After every click Metnos reads the page once it has stopped changing: some links change the address and draw the new page after the click. If a read fails because the page changes at that very moment, Metnos reads it again once, instead of stopping the collection.

An item's detail opened on another page completes that item: Metnos reads it, keeps it and goes back, without exploring other sections from there. For a complete collection the full list (for example «all bills») is opened first, then the details.

Before clicking, Metnos checks again that the control is the one observed, on the same page and in the same context. If it has changed, a previously visited route may be prepared again once, keeping consent requirements and limits. This recovery does not repeat a click already dispatched or preparation that has already closed overlays or handled consent.

The final check observes the control without rewriting identifiers in the page. Approval is consumed when the click is invoked: an error or timeout does not establish the absence of effects and does not authorize another click. A fresh observation can clarify the state without resending the command.

Observed navigation can link a row to its detail view. Only an unambiguous link lets Metnos merge the two views, preferring detail fields while retaining information found only in the list. Matching dates or amounts do not prove that two items are the same. Ambiguous or truncated views remain separate, and the original observations are retained.

The same item read on different pages, for example a summary and the archive, becomes one row only when both rows show the same identifier: a code of letters and digits that appears in a single row of each page. A code repeated on every row identifies nothing; dates and amounts written with separators do not count. The rows merge when more of their common fields agree than contradict: a list and a detail page may give different dates for the same bill, while a credit note citing it differs in almost everything. The more complete row is kept without blending values, and the sheet states the merged rows in Note and in chat. Each read of a page is a distinct source, even when the same page is read again. Rows of different sources with at least two equal fields and no shared identifier, or with a shared identifier but more contradicting than agreeing fields, stay separate and are reported as possible duplicates.

Downloaded documents and invoice identity

When the approved action includes saving documents, files are saved in the selected folder within the declared limits and returned for subsequent reading. An error or a lost response does not authorise another submission to the website. HTML and PDF reads preserve the outcome of every address, including errors; a PDF without text reports the need for optical character recognition without claiming that recognition has already run.

Invoices with different codes remain separate even when they share a supply identifier. Code separators preserve the observed groups: INV-20-005 and INV-200-05 are distinct. Equivalent copies merge only within their own group; a row without a code cannot bridge different invoices. These changes have local verification; the complete workflow still requires acceptance testing.

When a cloud model is used

If configured, the cloud model in the Frontier tier chooses routes to explore and recognizes visible records during collection. Recognition also receives the observed page text within the reading limit; the separate route decision receives control names with their section titles. These observations can contain personal data. Sign-in field values remain excluded. Login, planning, row extraction and other operations keep their respective configured models. The response counts cloud requests and the step displays a red $; a request already sent remains counted even if the available time expires.

Without Frontier configured, the local model makes the choice. If Frontier is configured but its decision fails or times out, the collection remains incomplete: it does not automatically switch to another model. Administrators can disable both cloud decisions with METNOS_SITES_FRONTIER_ROUTES=0.

Filters, dates, and spreadsheets

“All” and “complete list” retain their meaning of a complete collection even when the plan shortens the request, only when asserted for the requested object. Negation and prohibitions do not activate that collection; the adjective “complete” alone does not define its scope. Recognizing the request does not establish that every item was found. Period, category, and other constraints must refer unambiguously to the same action and apply together to every item. Filters apply to collected data: an intermediate page’s date is not enough to exclude a route. A summary or another invoice does not establish that an item meets the requirements.

Dates retain the precision of their source: “08/2026” means a month, “July–August 2026” an interval, and “15/09/2026” a day. English month names are also recognized. The year must appear in the source; numeric dates retain day/month order regardless of interface language. Unreadable dates are reported with the number of excluded rows and the affected field, including in the spreadsheet result.

A spreadsheet reuses an extracted field when a heading differs only in capitalization or surrounding spaces. It first looks for an exact name, then a unique match allowing those differences, then a unique match ignoring punctuation and accents. It does not resolve ambiguity by choosing the first field. Issue dates and due dates remain distinct.

The shared vocabulary also recognizes identifier number, amount, and status across Italian labels and English keys. Identifier numbers remain distinct from counts. These matches do not depend on field order or require a model call; competing fields still need an explicit source binding.

Spreadsheet headings are labels, separate from extracted keys. They do not add fields to an already declared schema; an explicit heading-to-source binding can request another field. Without a schema, headings can define it. A temporal filter already declaring its field and period does not receive a second automatic filter without a field.

Field discovery covers every row. A unique field that is present but empty can produce an empty column; a collision remains ambiguous even when it first appears in the last rows.

Values supplied as data never become formulas. In XLSX files, new text is stored as text, preserving existing formulas when rows are appended. In CSV files and Google Sheets writes, active text receives a protective leading apostrophe: in CSV this is part of the value and may be visible. Receipts report the number of cells protected this way. Devices need the updated package: an old package does not gain this protection without an update.

For a failed browser action, internal diagnostics distinguish preparation, command dispatch, subsequent work, cleanup, and recording. They retain the exception type and signals from a closed set, without returning messages, selectors, or page data. Signals may also match quoted text: they do not establish a cause and do not change outcomes, retries, or limits.

When the sign-in procedure returns, including before any credential use, the audit retains its outcome, reason and internal class, the last phase, and the number of search actions. A navigation refusal contributes only counters and comparisons from a closed set, without page data, destinations, or secrets. This trace supports diagnosis without adding attempts or establishing the cause of an error.

Candidate recovery corrections, 15 October 2026

After verified sign-in, the candidate keeps the actual destination as its return anchor, instead of the public opening page. The existing single recovery does not resubmit credentials or forms. It requires the same page, exact address and authorized origin; a change or pending request for user intervention stops recovery. Reaching that address is not a fresh authentication check.

During collection, after navigation has already executed, a document change during the check may allow one fresh read on the same page and origin, within four seconds in total and the caller’s remaining time. The earlier result is discarded even if it was clear. No click is repeated; a challenge or pending approval remains blocking.

The new records distinguish the recovery reason and the outcome of local selection among observed controls. They retain counts, elapsed time and closed categories, without page text, addresses, field values or model responses. Reported completeness concerns only the input window supplied to selection, not the website inventory. Diagnostics do not change decisions or attempts.

Isolated qualification of these changes remains separate from delivery and real-site testing. It does not establish that the initial missing control is resolved, that all invoices were collected, or that a general automatic CAPTCHA solver or a new supervisor exists.

If an obstacle interrupts the search, data already observed can still be delivered, including in a spreadsheet. If the expected total is unknown, the notice says completeness is unverified and names the observed limit; verifying the written rows does not prove that all bills were collected. Failed sign-in, a refusal with no data, or pending consent stops the sequence. An ambiguous control does not justify raising the limits.

The service allows up to eight concurrent browser sessions, including sessions owned by the same user. “Close the web sessions” ends the user's sessions; it does not change browser preferences or delete website data.

CAPTCHAs, codes, and resuming

Website boundaries and consent requirements remain in force throughout navigation. Cookies follow a separate procedure that rejects optional choices and rechecks new notices before submission. After rejection, it briefly waits for the panel to close, observing it without repeating the click or asking the model for another decision. OTP codes are requested from the user unless automation has been explicitly authorized; they are not treated as CAPTCHAs.

Metnos observes the panel’s static, non-editable public text, including text inside forms or elements without their own box (display:contents). It includes the panel’s own accessible name and the alternative text of visible images within it. Hidden or unrelated content, field values, editable text and active code remain excluded, with the same bounds and redaction. This evidence can also identify a promotional notice: classifying it as other does not authorize clicking Close.

Rejecting cookies requires explicit meaning in the control label and an observed pair of identifiers from the same panel. A generic close control or a navigation menu does not constitute rejection. Cached decisions are checked again; when evidence is insufficient, Metnos pauses the action. Rejection expressions come from the updatable native lexicon, without rules specific to each portal.

A field named “code” or “token” does not by itself require an OTP. Metnos looks for a visible, editable field identified as a one-time code or accompanied by verification evidence within the same form or field group. It recognizes numeric and alphanumeric codes, including codes split across single-character boxes. If several fields prevent an unambiguous choice, it does not enter the code. Sensitive fields remain obscured and submission respects the authorized website boundaries.

Metnos also recognizes an explicit textual request to verify humanity within its own sign-in form. It reads the complete prose, retaining FAQ context, quotations and negation around the message, even with nearby links, buttons or fields. Quoted examples, FAQ statements and negated requests do not activate verification. Visible credential fields can be temporarily disabled: this does not clear the challenge or permit filling or submission. A textual request goes to manual control even before a widget is visible.

For supported Cloudflare CAPTCHAs, Metnos tries the local playwright-captcha library once, in the same session and for no more than ten seconds. The attempt stays within sign-in limits, is checked on the page, and uses no paid services. If the check remains open or is unsupported, such as reCAPTCHA, Metnos asks for your help.

No general automatic CAPTCHA solver is active: the common flow provides detection and human intervention. The local Cloudflare attempt remains separate from the proposed supervisor and can fail. Observing or loading a challenge does not authorize an automatic checkbox click. The single/swarm supervisor and general CAPTCHA handling through spin agents belong to later phases.

The panel displays the already open session page with sensitive fields obscured. You can click, scroll, refresh the image, and select Resume. The broker preserves manual handoff in the same session and continues the original request only after verifying the outcome through a fresh website observation. A click or model response does not establish success; an unavailable observation does not clear the check. If credentials were already submitted, it checks that attempt without submitting them again. The panel expires after ten minutes; cancelling it closes the session. Checks requiring keyboard or audio input are not supported by this panel.

Resuming creates a new identifier linked to the suspended turn and preserves the user, conversation, results, and attachments. After form submission, the page shows progress and retrieves the result even after a reload or a lost response, without sending the values again. If it cannot confirm the result, it says so and does not automatically repeat the operation.

When it cannot finish

Since release 122: when a web control is obstructed, the managed browser automatically saves a static page copy and the obstruction measurements. No console script is required. The copy omits private fields and active code; it stays local, protected like screenshots. Capture is skipped during pending consent or authentication steps and does not certify the website workflow.

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.

Read next: executor contract · sandbox · skills and backends · agent runtime