While building Northstar I kept returning to the word light. Disk space and memory mattered, but the burden I most wanted to remove was repeating the same explanation and browser procedure after giving an instruction. Once I made that distinction, the product needed a different boundary between judgment, reusable execution and proof.
A short instruction could still create a long procedure
Consider publishing a piece of writing. Choosing the title and body does not remove the repeated decisions about which window, account and attachment state to use. If every button needs another interpretation, a fast individual click does little to shorten the job. I needed to reduce the amount of unresolved meaning between a request and its execution.
The early browser contained a CLI that proposed the next actions. That helped establish a working flow, but even familiar procedures could require another transfer of context. I stopped describing this only as a problem of too many features. Some moments require judgment; other moments should carry out a procedure whose conditions are already known.
I separated three kinds of burden
The first burden was observation: obtaining the controls and state needed for this decision rather than repeatedly transferring a whole page or conversation. The second was action: failing to reuse the correct tab can lead to extra windows and duplicate input. The third was judgment: a model does not need to produce another answer simply to discover that a known background job is still running.
These burdens are not the same metric. A reduction in context bytes is different from measured model-token use, and both differ from reduced memory. I kept those units separate so a change could be connected to the burden it actually addressed. Before writing a performance claim, I needed a precise name for what had been measured.
A known procedure should not be rediscovered each time
I kept variable inputs separate from the fixed procedure in a reusable execution definition. The program validates the current inputs and follows the same path. In repeatProgram, the result of one iteration must be verified before the next begins. That is a different responsibility from asking a model to choose the next click repeatedly. The normal path becomes code, while places needing fresh judgment remain visible.
This did not mean reducing verification. An automatic sequence still needs an identified account and tab and a checked outcome. A shorter sequence is not evidence that it is more accurate. Reducing an agent's burden could not be an excuse to skip the checks that make the resulting action understandable.
A large catalog can have a small entrance
In the current external-MCP arrangement, I inspect the working context and discover the relevant tool family or existing plugin. Looking at names and purposes first, then reading the selected input contract, fits repeatable work better than expanding every implementation detail on every request. A simple publication route takes the current content and date and connects saved project defaults.
Simple describes the user's input, not the absence of internal responsibilities. Account boundaries, selected files and actual outcome checks remain. Hiding a field in the interface does not remove the need to verify it. I placed information that a person need not repeat separately from information the program must continue to check.
The same criterion applies to a company's workflow
A company can ask the same questions about its own work. Does a familiar task still require someone to select the destination, attach the same kind of material and inspect progress repeatedly? In that situation, another screen may matter less than a clear connection between request, target, execution and outcome. The work determines what can be prefilled and what must arrive with each request.
For example, a destination account can be saved with the project while this document's content must be supplied anew. A requested repetition count cannot justify copying missing source material to fill the quota. Recording both removable repetition and essential judgment helps keep automation aligned with the person's intent.
What I checked and what this article does not establish
I wrote this decision from the development conversation, the current execution definitions and the external-MCP documentation. I have not presented historical embedded-CLI behavior as a current product feature, and writing the article did not trigger another publication in the original browser. A stored execution path with no internal model calls does not mean the surrounding conversation consumed no tokens.
The linked context module isolates one part of this approach as newly written synthetic code. It selects a declared existing tab and returns a result; it operates no website. A reader adapting it must decide where trusted context comes from and what must be checked again immediately before dispatch. Lightness should not mean removing the explanation needed to make that decision.