The browser plans, the agent builds, the human decides

When an AI system is asked to do more than draft a text, a tempting shortcut appears: "Just do everything." That is precisely where work becomes unclear. Not because a system cannot contribute, but because planning, execution and decision-making are different jobs. Separating them creates speed, visibility and a better place for responsibility.

The metaphor in the title is deliberate. "Browser" does not stand for a particular tool but for the part of the work that creates orientation. "Agent" stands for consistent execution, "human" for the judgement no machine should take over. Three roles, three artefacts, three transitions — and at each transition a place where a person confirms or corrects the direction. That is the whole trick: not to guess faster, but to work more visibly.

An idea first needs a walkable plan

A browser is more than a window onto the internet here. It represents the part of the work that creates orientation: reading requirements, finding sources, comparing options and making open questions visible. The outcome of this phase is not a finished product. It is a plan a person can follow.

A good plan names the goal, materials, boundaries and the next verifiable step. It may contain gaps; what matters is that they are not hidden. If an assumption is necessary, it is marked as an assumption. If a source is missing, the gap belongs in the plan rather than invisibly in the outcome.

This phase is the cheapest place to prevent expensive mistakes. A wrong assumption written into the plan costs one sentence to correct. The same assumption discovered only in the finished draft costs a re-run. That is why it pays to keep the plan short and readable — half a page someone checks in two minutes beats a document nobody reads. The plan is not a contract with yourself; it is an invitation for others to object early.

The agent builds inside a clear frame

Only when the frame is in place does execution become productive. An agent can structure files, generate drafts, carry out repeatable steps or prepare several variants. Its strength is the consistent treatment of a described task, not guessing the purpose of an unclear one.

The execution phase therefore needs a small hand-off package: What is to be created? Which materials count? Which rules are binding? What may change, and what must stay untouched? The clearer these answers are, the less an agent has to improvise — and the easier its output is to examine.

Two boundaries keep this phase healthy. First, a scope boundary: an agent asked to build too much at once produces output nobody can review in one piece. Smaller, clearly outlined tasks are faster to check and easier to discard. Second, a change boundary: what must not be touched — existing data, binding wording, someone else's code — belongs stated explicitly, not silently assumed. Execution is most valuable when it is boring: predictable, repeatable, traceable.

Deciding remains its own activity

A completed draft is not yet a decision. People decide about priorities, consequences, tone and whether an outcome can be defended. They can also see that a formally correct solution arrives at the wrong time or misses the actual question. This role should not appear only at the end, when changes have become expensive.

Build deliberate checkpoints: after planning, at important intermediate states, and before anything has an external effect. A checkpoint is not a declaration of mistrust. It is the place where a project becomes steerable again. A person can approve, correct, change scope or stop the work there.

The most important one is the last checkpoint before external effect — before an email goes out, a text is published, a change ships to production. Until then everything is reversible; after it, not. Protect that single point and you can keep the earlier phases fast and experimental. Approval carries a name: it should be clear who agreed, and to what. Responsibility without a name evaporates.