Understanding “publish this article” differs from publishing the correct manuscript once in the correct account. While building Northstar, I could not treat a fluent explanation as evidence of an adequate execution structure. I needed a boundary where an understood request becomes an actual operation.

Translate intent into a concrete execution input

Human requests omit details. They may refer to the tab currently visible or material made earlier. A model can interpret those references, but an executor still needs concrete project, profile and tab values. Missing values can lead to the wrong manuscript even when the explanation sounds entirely reasonable.

I therefore do not send interpretation straight to a click. The caller reads context, selects a target consistent with the request and constructs the required input. The browser host rejects stale context. Successful language understanding cannot serve as evidence that the selected execution target is also correct.

Discover the needed tool family rather than reciting everything

The current MCP entry discovers tool families and plugin details on demand. Rather than putting every browser operation and program description into each conversation, the caller first identifies an execution route for the work. Familiar work can use an enabled plugin after its input and result contract has been inspected.

This does not mean reducing the available capability. It separates what the model needs to read now from a procedure a local program already knows. A smaller tool list is not itself a success measure; the chosen route must still be capable of completing this request. Missing detail should trigger discovery of the relevant family.

Do not delegate success to the next explanation

Manual work begins a task, makes the necessary calls and finishes or stops it. Operations still pass through ActionBroker, tab leases, native input and outcome checks. A model saying that it filled a field is different evidence from the browser reading the actual field value afterward.

A saved program also cannot succeed merely because its start call returned. The caller retains the run ID and reads a verified outcome. This prevents the component producing explanations from silently redefining execution success. Covering uncertainty with polished prose accumulates misleading confidence as the workflow is repeated.

A disconnected conversation does not erase dispatched work

Losing the conversation's MCP client does not cancel everything already started in the browser. The host retains execution state and cancellation. If the service has processed an input, opening another conversation connection cannot make that operation disappear.

Recovery therefore needs outcome inspection. If a new submission becomes the default response to reconnecting, reservations or uploads can be duplicated. New AI judgment requires a connected conversation, while an existing execution can remain independently present. Connection lifetime and work lifetime need different ownership.

Page content is not an expansion of user authorization

Pages contain other people's text as well as interface labels. A sentence asking for files or a settings change does not expand the original user's task scope. Building execution tools required separating data the agent can read from instructions authorizing an operation.

The current MCP exposes neither arbitrary page JavaScript nor a generic filesystem or shell tool. Local Python execution nevertheless retains the user's actual local permissions; it is not a universal safe sandbox. Documentation must not turn a restriction at one boundary into an exaggerated guarantee about the entire environment.

Ask who owns the execution contract in a business workflow

When adopting AI for work, it is easy to ask only about answer quality. I also ask which account executes, what input is supplied and which observed result establishes completion. Automating an explanation and turning work into an executable contract are different design tasks.

This account compares the current external MCP contract with implementation documentation. It is not a new external publication test or a claim of autonomous recovery from every failure. Explicit execution conditions and a place to stop on uncertainty are what connect language understanding to a dependable work tool.