unbrowseImagine asking your assistant for last month's invoice.
“First, create a developer account.”
I wanted a receipt. When did I become a developer?
“Generate an API key.”
Is that my password?
“No, this is a different credential.”
Of course it is. The password only works on the website, where the thing I want is currently available.
“Now configure a service account.”
I thought I was paying you for the service.
The assistant was supposed to take work off my hands. It has hired me as its integration engineer. There is probably a certificate I can get at the end.
Follow the invoice
Follow one invoice from the request to the place the customer needs it. Write down every point where the customer has to take over.
They name the service. That is reasonable. They approve appropriate access. Also reasonable. Then they find a developer console, work out which permissions to choose and discover that the connection can list invoices but cannot download the PDF.
The setup succeeded. The delegation failed.
We have given a receipt a management structure.
An architecture diagram can put the developer portal outside the product boundary. The person doing the work cannot.
A task like “get my invoice” has an obvious result. The right file, for the right billing period and account, delivered where requested. A connector status does not satisfy any of those conditions. Neither does a confident explanation of where to click.
The customer can already click. They hired the assistant because they would like to stop.
Make the setup pay rent
Some setup is valuable. A clear consent screen lets a person choose what access to grant. A separate account can keep work within appropriate permissions. A maintained integration can handle ugly details the customer should never need to learn.
Keep those things. Make them earn their place by reducing what happens afterward.
For the invoice workflow, successful onboarding should establish which account to use and how the person can withdraw access. It should also tell the truth about whether the service supports the required task. Discovering that the PDF is inaccessible after the whole setup ceremony is an expensive way to say no.
The strongest defense of a good integration is pleasantly boring: the user approves access and gets on with their day.
Good. That earns its keep.
The word “just” deserves special suspicion here. “Just create a key.” “Just choose the scopes.” “Just paste it into settings.” Each sentence assigns work to someone. If that someone is the customer, put it in the cost of your assistant.
We cannot roast the setup wizard and then hand the customer a terminal.
Next month is part of the product
Imagine the first invoice arrives correctly. Next month, access has expired. The assistant reports a connection error and offers a link to technical documentation.
The user has been promoted again. This time to incident coordinator.
An access renewal may genuinely require the person. The product can still own the handoff: explain which account needs attention, provide the supported reconnection path and preserve the job so it can continue afterward. “Something went wrong” gives the customer a new investigation. “This account needs you to sign in again” gives them a bounded action.
The same distinction applies when the file is missing. Perhaps the service has not issued it. Perhaps the requested billing period is wrong. Perhaps the tool broke. Those outcomes need different next steps. Reporting all of them as an empty result pushes the diagnosis back onto the person who delegated it.
“Connected” is an excellent demo state. “Still working next Tuesday” is a better product requirement.
The website is allowed to help
When a supported website operation is absent from the official integration, a browser can provide another authorized route. On many sites, downloading a file sends a request that can be observed and, in suitable cases, reused.
Reusing a verified request can remove repeated navigation. Where browser state remains necessary, keep it. The point is to take responsibility for completing the job through an appropriate interface, including an honest explanation when no supported route works.
Unbrowse can expose a supported website operation as a reusable capability, removing repeated navigation where the route works. That is machinery too. We have not defeated abstraction by choosing a shorter name. Use the connection documentation to test the task on your particular billing portal; this example is no promise that every invoice workflow is supported.
Count the work that came back
When testing the assistant, keep a small record of what you still did. Include setup, correcting the result and recovering failed access. Then repeat the task with another billing period.
A useful assistant can ask you a necessary question. It can also stop when it lacks permission. What it should steadily absorb is the operating work between your decision and the result.
The Agentic Web Will Not Wait makes the wider argument for finding usable website operations. The invoice makes the judgment simpler.
If you still locate the file, check the date, download it and put it where it belongs, the assistant has produced commentary on your work.
The invoice is right there.
Bring back the invoice.