Compare

Merlean vs browser agents

Browser agents operate software the way a person does: look at the screen, decide, click, look again. It is a remarkable capability, and it is the wrong tool for repeatedly executing known work in an application you own.

What browser agents are good at

Generality. A browser agent can attempt a task on a site it has never seen, with no integration, no credentials arrangement and no setup. For exploration, for one-off work, and for systems you have no relationship with, that is a capability nothing else offers.

They are also the honest answer when you genuinely have no access to the application - a supplier portal, a government form, a competitor's public site.

The reliability arithmetic

A browser agent completes a task as a chain of perception and decision steps. Each step is individually good and none is certain, so success compounds downwards: a twelve-step workflow at ninety-five percent per step finishes around half the time. For work that must simply happen, that is not a rounding error.

The failure modes are also awkward. An agent that misreads a screen does not stop, it proceeds confidently, which means a half-completed workflow rather than a clean error. Recovering from that is harder than recovering from a refusal.

Then there is cost and latency. Every step is a screenshot sent to a vision model. A task that is three API calls becomes dozens of round trips through an expensive model, and the user waits for all of them.

What changes when you read the application

Merlean does not look at your application, it reads it. The analysis produces the endpoints, the required fields, the validation, the permissions and the real workflow order, so execution is a small number of deliberate calls rather than a long chain of guesses.

The consequences follow from that. Determinism, because the same request produces the same calls. Speed, because there is no perception loop. Cost, because there are no screenshots. And clean failure, because a request that does not fit the model is refused rather than approximated.

Browser agent

Screenshot, reason, click, repeat. Works anywhere with no setup. Reliability compounds downwards over long tasks. Slow and expensive per task. Fails by proceeding confidently.

Merlean

Reads source, calls endpoints. Needs a connected repository. Deterministic per request. Fast and cheap per task. Fails by refusing or asking.

Choose a browser agent when

  • You do not own the application and cannot connect its source.
  • The task is exploratory or one-off, and generality matters more than reliability.
  • There is genuinely no HTTP interface underneath the screen.

Choose Merlean when

  • The application is yours and its source can be connected.
  • The same kinds of work happen repeatedly and have to complete.
  • Users are waiting for the result, so latency is part of the product.
  • Half-completed work is worse than a clear refusal.

Frequently asked questions

Do browser agents not handle interface changes better, since they see the screen?

They tolerate a moved button that a hard-coded selector would miss. But they also re-derive everything on every run, which is why the same change can produce a different path today than yesterday. Merlean re-reads the code after a release and gets one updated model, deterministically.

Is Merlean faster?

Substantially, for known work. There is no perception loop: a task is the calls it needs rather than the dozens of screenshot-and-reason cycles required to find them.

Can we use both?

Yes. Merlean for the applications you own, a browser agent for the external systems you do not. They cover different halves of the problem.

See it against your own application

Merlean reads your repository and shows you what it understood before anything is exposed to a user. The fastest way to judge the fit is to point it at a real codebase.

Get in touch Read the docs

Related