Hale

One pattern that has worked well for me and is worth stealing: approve the plan, not the steps.

The agent produces a plan — here is what I intend to do, in order, with the specific arguments. A person reads it once and approves. The agent then executes without interruption, and stops if reality diverges from the plan in a way that would require an action outside what was approved.

That gives you one meaningful review instead of fifteen meaningless ones, and the review happens at the point where a human can actually add something, which is before anything has been done.

The key detail is the divergence check. Without it you have approved a plan and authorised something else.

One discipline that costs nothing and is worth more than any tool: change one thing at a time, and write down what you expected.

I keep a file with a line per change: what I altered, what I predicted, what the benchmark did. Half of my predictions have been wrong, which is the entire value of writing them down.

Without it you end up with a prompt that has accumulated twelve modifications, all of which somebody believed helped, and no way to remove any of them.

Worth adding what has genuinely changed in the last while, because it is why this is happening now rather than three years ago.

The browser automation projects have grown accessibility-tree snapshots and element-handle abstractions specifically aimed at this use case, and there are now standard ways to expose a browser to an agent as a set of tools rather than as an API you write code against.

So the honest read is: the base tooling is converging on the same answer, and the products are competing on the layer above — sandboxing, session handling, recovery when a step fails, and how well they cope with a site that changes.

My practical advice if you are choosing: test them on a site that fights you. Every one of these demos beautifully on a clean page. The differences appear on a page with a cookie banner, a modal, an infinite scroll and a login.

Worth splitting the context into three kinds, because they have different homes and people try to solve them with one tool.

Project knowledge — conventions, architecture, what not to touch. Belongs in the repository, reviewed like code, and it benefits everyone including humans. This is the largest and most valuable category.

Personal working preferences — how you like to be talked to, your tooling, your habits. Belongs in a personal file you carry between machines.

Task state — what we are doing right now, what has been tried. Genuinely ephemeral, and the thing people most want to preserve and least should. If a task's state matters after the session, it belongs in an issue or a document, not in a transcript.

Most of the pain people describe as "losing my context" is the first category never having been written down, and it is a documentation problem wearing a new hat.

The honest answer is that it buys you distribution and description, not capability.

Your REST API can already be called by an agent. What it cannot do is show up in somebody's assistant without that person writing an integration. The protocol standardises three things:

• Discovery — a client asks what tools exist and gets back names, descriptions and argument schemas, at runtime.
• Invocation — one transport and one shape for calling them, so a client that speaks it can use any server without bespoke code.
• Context beyond tools — resources and prompts, which is the part people forget exists and the part that distinguishes it from "a list of functions".

So the value is that a user of any compatible assistant can point it at your server and immediately have your capabilities, with no work by you or them.

If your service is internal and used by one agent that you also wrote, that value is close to zero. You already control both ends; a wrapper adds a hop and a spec to maintain.

There is a principle and it is unglamorous: parallelism pays when the work is genuinely independent, and costs when it is not.

That sounds obvious and it is the whole thing, because most coding work is not independent. Two agents editing the same module produce a merge problem plus two partial understandings of a decision neither of them made.

Where the split reliably wins:

• Breadth over the same question. Several agents reading different parts of a codebase to answer one question, each reporting a summary. No shared writes, and the context problem is the thing being solved.
• A fan-out over a work list. Fifty files needing the same mechanical change. Independent by construction.
• Independent verification. One agent produces, another tries to falsify it. This is the highest-value pattern I use and it is not really parallelism, it is adversarial review.

Where it reliably loses: one feature, split across agents by layer. They will disagree about the interface and you will arbitrate.