Compare

Merlean vs in-product copilots

Nearly every serious product has shipped a copilot. Most of them help a user do the work faster. Fewer of them do the work, and the distinction is where the value sits.

What copilots typically ship as

The common pattern is assistance around the edges of a workflow: summarise this record, draft this message, explain this chart, suggest the next step. All useful, all fast to build, and all leaving the user in the driving seat for the part that takes the time.

The reason is architectural rather than a lack of ambition. Wiring a copilot to actually perform actions means writing a tool definition per action, keeping each in step with the application, and handling the permission question for every one. Teams build five or ten tools for the highest-value paths and stop, because the eleventh costs as much as the first.

Why the tool catalogue does not scale

Every action needs a hand-written definition, and every definition is another thing that can drift from the code.
The tools cover what someone prioritised, so a user request that falls outside the list gets a suggestion instead of a result, unpredictably.
Permissions get re-implemented in the copilot layer, creating a second authorisation system to keep correct.
Multi-step work needs the order encoded somewhere, and that somewhere is usually a prompt, which is not a good place to keep a workflow.

Deriving the surface instead of writing it

Merlean produces the executable surface from your application's source: the endpoints, the fields, the validation, the permissions, and the workflows those pieces form. Coverage is therefore a property of the application rather than of how much integration work a team had time for.

Permissions are not re-implemented, because execution happens through your application with the user's own credentials. And workflow order is derived from how the application actually behaves rather than described in a prompt.

When a hand-built copilot is the right call

The valuable AI feature is generative - drafting, summarising, rewriting - rather than operational.
A small number of actions carry nearly all the value, and they are stable.
The interaction needs bespoke interface work that a general execution layer would not provide.

Frequently asked questions

We already built a copilot. Is that wasted?

No. The generative parts - drafting, summarising, explaining - are worth keeping. What Merlean replaces is the tool catalogue behind the action-taking parts, which is the piece that is expensive to extend and to keep accurate.

Can we keep our own interface?

Yes. The execution layer is reachable directly, so you can keep the interface you designed and change what sits behind it.

How is coverage different in practice?

A hand-built copilot covers the actions someone had time to wire up. Merlean covers what the application exposes, and a re-analysis after a release brings new capability with it.

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