Bring your own agent. What does the website bring?

For years websites have been adding chatbots. Most of them started in customer support and sales: answer a question, find an article, collect an email address, maybe hand the conversation to a human.

Recently - kind of recently 😅 - some of those chatbots became capable of taking actions. They can change a booking or put something in a cart, and in some cases they can even complete the checkout and perform irreversible actions. The chatbot is turning into an in-page agent.

But today we want to start with a different assumption:

What if users don't want a different agent on every website? What if they want to bring their own?

When every site has their own agent, it may force users to repeat themselves, their goals, preferences, on every site they visit, creating friction and severely reducing the potential of agents. Sam Broner and Ali Spittel recently shared versions of this argument, and both posts went viral. A user's own agent already knows their preferences, carries their memory and context, uses their preferred model, and lives in the UI they chose. It's like the don't-repeat-yourself (DRY) principle, but for agents.

There seems to be a broader pattern forming around this idea: Bring Your Own Agent (BYOA).

The control used to live with the website

In The three homes of the Agentic Web, I described the in-page agent as the home where the website owner has the most control.

The business receives the prompts. It chooses the model, tools and guardrails. It controls the UI, observes the interaction, connects it to business goals and decides when a human should step in.

And all that control comes at a price: you, the site owner, build and run the whole thing yourself - the model, the tools, the guardrails - and you carry the complexity and the bills 😅.

With BYOA, that trade-off flips. The business no longer has to provide the whole agent, but much of the control moves to the user's agent.

Many websites cannot even reliably tell whether a human or an agent is using them. An agent can click through the UI, operate the DOM or use the accessibility tree while the website sees a familiar sequence of page views and requests. The business sees what happened, but it may have very little visibility into why.

That creates an interesting problem. The user gains continuity across the web, while the business loses the agent surface it used to understand and shape the interaction.

If the user brings an agent, what does the website bring?

Newton's third law says every action has an equal and opposite reaction. When the user’s side of the interaction changes, the website’s side needs to change too.

If the user arrives with an agent representing their goals, preferences and context, the website needs a clearer way to represent its side too.

The user's agent can have much more context about the user than a website's agent will ever have: their preferences, history, budget and what they are actually trying to achieve. At the same time, the website's agent can have much more context about the business than the user's agent will have: its products, policies, inventory and all the edge cases behind them.

The two agents can meet in the middle. The user's agent stays in the driver's seat, but delegates the relevant parts of the conversation to the website's agent as a dedicated subagent. An interesting aspect here is observability, but let’s keep it for another blog post 😁. One brings the user's context, the other brings the business context - and neither needs to know everything 🤝.

Not another chatbot competing for the steering wheel. Something closer to a harness for the website.

By harness, we mean the layer around the website's agent-facing capabilities. It can expose what the business allows, explain how those capabilities should be used, keep the relevant business context and enforce the rules of the interaction.

The user's agent still represents the user. The website harness represents the business. The goal is not to pull control back from the user - it is to create a clear contract between both sides 🤝.

WebMCP gives the website a surface

Without a defined agent surface, a visiting agent has to inspect the page and guess its way through the UI. It might use screenshots, the DOM, the accessibility tree or computer use. That can work, but the website is mostly a passive participant.

WebMCP changes that relationship. A website can expose clear tools for the actions it supports. Instead of asking an agent to find the right button and hope it understood the page, the site can offer a capability such as search_products, check_availability or start_return.

This gives the business visibility into which agent-facing capabilities are being used and control over the surface of action. Tool invocation still has to pass the same authentication, authorization and validation as any other request - remember, registration is not a permission boundary.

André explored the next step in his WebMCP text editor. The page exposes its own specialist agents through tools such as invoke_writer, invoke_reviewer and invoke_planner. The user's agent can call one of them like any other WebMCP tool, while the specialist agent does its own thinking and invokes its own tools behind that boundary.

The user's agent coordinates the task, then delegates the part that needs the website's local expertise.

It also reveals something WebMCP does not provide today. The in-page subagent can think and call tools, but there is no dedicated channel for it to send that work back to the main agent while it is happening. The main agent invokes a tool and receives its result; the richer subagent feedback in between - progress, status or nested tool activity - still needs a mechanism of its own 🤔.

WebMCP might therefore be a first step toward the website-side harness. Tools only tell an agent what it can do. They do not fully explain how the business expects a longer journey to work.

Tools define capabilities. Skills explain how to use them

This is where skills become interesting.

In WebMCP, skills and Agentic Resource Discovery, I explored a simple distinction:

• WebMCP: What can I do on this page right now?
• Skill: How do I complete the whole journey?
• Agentic Resource Discovery: Where do other capabilities I need live?

A tool can say "start a return." A skill can explain which orders are eligible, when to ask for a reason, how exchanges differ from refunds, what to do with a damaged item and which steps require explicit approval.

André was experimenting with a very interesting pattern - WebMCP tools as skills: in this demo you will find registered tools where description is the one-line summary and what do they return? Full recipe on how to complete certain workflows - progressive disclosure through the tools 😎.

It gives the website a way to describe how the business wants the experience to work without owning the entire agent loop.

The website-side harness

Once we have tools and skills, the harness can expand around them.

It might include business context that should not be copied into every tool description: catalog knowledge, policies, current inventory, eligibility rules or the state of a longer workflow.

It might keep memory and sessions, so a journey can pause and continue without pretending every tool call is the first time both sides have met.

It can carry identity and permissions: who is the user, which agent is acting for them, what can it access, and what requires a fresh confirmation?

It can define approval rules. Searching and comparing might happen freely, while placing an order, sending a message or changing a subscription requires the user to take the wheel for a moment.

And it can decide where the work happens. Some processing belongs on the website side because it depends on private business data or policy. Some can be delegated to the user's agent because it depends on personal context the business does not need to see.

This split is not only technical detail. It decides who sees the data, who pays for inference and who is responsible when the agent makes a decision.

Maybe the most useful website-side harness is not one giant agent at all. It could be a small set of tools, a few focused skills, a session and policy layer, and an agent only for the parts that actually need judgment.

Does this eventually become A2A?

Once both sides have identity, context and the ability to hold a longer interaction, the shape starts to look familiar.

In Agents talking to each other, I experimented with a visiting browser agent handing work to a website's agent through a plain tool and through A2A.

So does the website-side harness eventually converge on A2A?

Maybe - especially when the website has a real agent that owns long-running tasks, asks follow-up questions and can be reached outside the page. In that case, an agent-to-agent protocol is a natural fit.

We might end up with a hub-and-spoke architecture. The user's agent becomes the hub: it keeps the user's goal, coordinates the journey and calls specialist agents when it needs them. The spokes can be agents from one website, or agents across several different websites.

Imagine planning a trip. The user's agent could delegate one part to an airline's agent, another to a hotel's agent and another to a local transport agent - then bring the results back together around the user's preferences. Each site-side agent knows its own business; the user's agent keeps the whole journey connected.

A2A starts to look useful here because those spokes are no longer just functions. They might hold tasks, ask for missing information, report progress and continue later. The user's agent remains the coordinator, while each business owns the work inside its spoke.

But not every website needs to become an A2A server, not every interaction deserves another agent loop, and a lot can be achieved by injecting the right context into the user's agent using skills, resources and prompt templates, and by giving it the right tools . A price lookup might remain a tool call. A journey for returning an item back to the store could be guided by a skill. A complex booking that pauses for approval might become a task held by the website's agent.

The harness is the bigger idea. A2A could be one of its interfaces.

A contract, not a takeover

BYOA gives users something websites struggle to provide on their own: continuity. One agent can know the user across many businesses and carry their intent from one tab to the next.

The website has a different advantage: local knowledge and authority. It knows its inventory, policies, current state and the actions it is actually willing to perform.

The user's agent should not have to reverse-engineer every website. The website should not need to own the user's assistant to take part in the experience. A website-side harness can sit between those two extremes - tools for capability, skills for guidance, and enough identity, context and policy to make the interaction clear.

We are still figuring out what belongs in that harness and which pieces should become web standards.

Bring your own agent - and let the website bring a clear, trustworthy way to work with it.

We will be exploring this further in future blog posts 🚀.

More soon. ✨