Industry
SaaS consoles: let them bring their own agent
Your users already have an assistant that holds their context. Exposing tools costs you nothing per call and beats building an in-app agent they did not ask for.
Last reviewed 27 August 2026
The sentiment among people who use agents daily is consistent and worth reading literally: I do not want to use your product's agent. I want my agent to be able to use your product.
It is not hostility toward your assistant. It is that theirs already knows what they are working on, remembers last week, and is connected to the six other tools involved. Yours starts from nothing every session.
The economics
| In-app agent | WebMCP tools | |
|---|---|---|
| Token cost | Yours, per user, forever | Theirs |
| Model choice | Yours to make and re-make | Theirs |
| Context about the user's work | Only what is in your product | Everything they have |
| Build cost | A product in its own right | Days, then upkeep |
| What breaks on a model release | Your prompts and evals | Nothing |
There is a place for in-app agents — a constrained assistant inside a dashboard where the operations are dangerous and you want them narrowly scoped is a defensible design. But as the default answer to make the product agent-friendly, it is the expensive option and it is the one users are pushing back on.
What to expose first
Look at what your users do repeatedly through the UI that the UI is bad at: anything requiring six clicks to answer one question, anything they export to a spreadsheet, anything they ask support to run for them.
query_metrics(metric, range, breakdown) // readOnlyHint list_segments() / create_segment(definition) export_report(format, range) // readOnlyHint list_campaigns() // readOnlyHint pause_campaign(id) // confirm before running search_docs(query) // readOnlyHint
Start with everything marked read-only. They deliver most of the value, they need no confirmation flow, and they are the ones a security review approves without a meeting.
The refactor you will hit
A tool handler cannot reach into React state or a store the way a click handler can. In a mature console, a surprising amount of business logic lives inside components — and that is where the real effort in this project sits.
The move is to extract each operation into a plain function that takes arguments and returns data, then have both the click handler and the tool call it. It is a good refactor to have done regardless. It is also worth scoping before you promise a date, because add some tools and disentangle four years of logic from the view layer are different projects.
Consoles are where errors matter most
Agents retry. A tool that fails with a bare 500 gets called again, identically. A tool that returns segment definition rejected: `date_range` must be an ISO 8601 interval, received `last week` gets called again correctly.
Write failure messages as instructions to a competent stranger. That is exactly the audience.
The safest place to learn this is your own back office. No compliance surface, no public traffic, users who already work with agents, and a measurable result — the report three people click through for twenty minutes becomes one tool call. It also gives you a working proof inside the company before you point any of it at customers. See internal tools.
Sources
Primary documents, checked on 27 August 2026
Keep reading
Check your own site against this
The Agent Readiness Score measures exactly what this article describes, and shows the evidence behind every finding.
Run the check →