London · Agent Engineering London 2026

Browser Use Is the Default. Your UI Is Not Your Agent API.

Name: Browser Use Is the Default. Your UI Is Not Your Agent API.
Uploaded: 2026-10-16
Description: Browser Use Is the Default. Your UI Is Not Your Agent API. by Frédéric Barthelet, Alpic. Agent Engineering London 2026, London. Watch the recording.

Frédéric Barthelet, CTO & Co-founder, Alpic

Watch on YouTube

Protocol

Transcript

This transcript was generated by AI and may contain mistakes, including in names and technical terms. It has not been manually verified. Please refer to the recording for accuracy.

Source: YouTube automatic transcript. Select a timestamp to watch that moment on YouTube.

0:00
Hi everyone. Um, so yeah, my name is Fred. I'm CTO and co-founder of Alpic.
0:05
Um, I'll try to be as joyful as possible on stage here. I know we're just after lunch. I don't want you everybody to
0:13
fall asleep during my talk. So I'll try to be interesting. Um, today uh I'm going to talk a little bit
0:20
about agentic experience. Um, Alpik, we are the MCP hosting platform. We help business and uh provide product and services to AI agents using MCP server.
0:31
But today today talk is going to be a little bit larger than MCP and focus more largely on all surfaces an agent
0:38
can use. Um this number are not new uh but they do reflect the current trend of
0:46
agents being uh the majority of traffic using business interfaces online going from 20% from some blog post uh from
0:56
above from versel back in 2025 to 57% which was the last number publicly shared from cloudflare during this
1:04
summer. So there are no more agent traffic than human traffic on existing surfaces of the web. Um agents varies
1:14
greatly from one to another in what they are made of. And the reason we see more and more of them online is because they
1:21
most of them all have a browser that they can use to crawl website and access pages. But that's not all that they are
1:28
made of. And it's important that we take a look at what uh are inside each of them to better understand what we can do
1:35
to help them. Um each agent uh has an host that provides a UI for you as the end user of the agent to interact with
1:44
it. Whether it be a web application like a TGBT web or cloud AAI or a desktop application like you would have codex or cloud code running locally on your
1:52
machine. all are powered by a model that provides the inference layer for the uh agents to uh generate tokens on. They
2:01
most of them have a virtual machine that they can use to interact with their brother or with their shell or with distant server. Um or they can use your
2:09
own machine most of the time sandboxed through some virtualization technology. Um and each OS provide an ecosystem.
2:16
Most of the time it's an ecosystem of tools that you can inject into the OS that are branded uh for specifically the OS. Um this is the visible part provided
2:26
by the OS. There is also the arness that's powers the loop of the agent that's made of gates to help you
2:34
validate if you want to go further memory that the agent can rely on from previous conversation. uh context that is being injected into the conversation
2:42
uh when you start the session and tools tools which will be the matter of interest for today presentation. Tools
2:49
being the one used to interact with the browser shell and the various server uh talking um used to communicate with the outside world.
2:58
Um there are two ways agents communicate with the outside world. First one is to discover uh things that you can do out
3:05
there. Um, one big names that everybody knows behind agent discovery which is um general engine optimiz the gener
3:13
generative engine optimization or GEO um which uh focus on helping agent better discover your product. Um there are four
3:23
ways three of them that you can really have an impact on. Uh agents discover your existence online when they're looking for a service or looking for a
3:30
solution to their issue. um previous knowledge from their training data set.
3:34
Um that if you are a very old company would be very something that you can really rely on because they will know you. Um tools that power search on the
3:44
internet. Uh tools that power fetch to actually grab content and context from existing web pages out there and registries which are mostly powered by
3:52
uh the OS as part of the ecosystem powered to the uh given to the agent.
3:58
Um let's take a closer look at uh various uh agents. So various um host and their aresses and their model um
4:07
using um the existing way that they have to uh discover services. And one way to
4:15
put that in light is using a small product that we built at Alpic to help us better understand how agents were
4:22
behaving finding about Alpic. Um, it's a small tool that allows us to very easily
4:29
run multiple simulation of agents and their RNSes with a given task and some variation whether it be uh some existing
4:38
access to a browser, access to web MCP technologies, access to MCPS or skills that might influence the way it behaves,
4:46
previous connection to other services, existing competitor services and let them run with this given task and see
4:53
what they do. Um yeah, for example, I show with you on the screenshot. I hope it's big enough. Um some uh No, it's not big enough. Okay, so I'm going to
5:01
describe mostly what's there. I put uh Cloud Code, Codex, Cursor, and Grogbot uh on the lookout for a sandboxing
5:09
solution to deploy the recently coding agent I've been playing with. And I asked them to uh find out about existing
5:17
solution, why they would discard some of them and which one they would pick and ways of um moving forward for those
5:25
agents um trying to find an answer to this task from one agent to another was quite different. Um if we take a look at some of the results from cloud code
5:34
running this specific task um we can see that out of the three runs that were performed for this specific task three times out of three cloudcut performed an
5:43
answer provided an answer based on existing knowledge. It didn't want to go outside and look in the world for existing sandboxing solutions. If you
5:50
look at codeex that's just below three times out of three it performed a web search with specific keyword to find solutions and it performed a search that
5:59
put forward most of the time E2B and then in the ramp up data I believe and model as well. So if you look at two
6:09
agents with the same task they will behave greatly differently um in order to find an existing solution to a
6:16
problem. um things uh inside this discovery phase for various type of harnesses you can impact on. For
6:24
example, if we take a look at the codeex run um and we look closely at what kind of search term it's made to find
6:32
solutions, we can help steer the decision on which solution to use to u deploy this uh coding agent and
6:41
profitably I hope deploy it on my sandboxing solution. um search term here. What you see is the um debug trace
6:50
of uh the session um that Codex performed to look for a solution for sandboxing environment. Um and we can
6:57
see a lot of the search term they use to crawl u the web and find uh solutions to look for. Um things that we uh do at
7:07
ALPIC to help improve uh us being selected as a prime solution for hosting MCP server is look on the keyword that
7:15
Codex or CL code or cursor are going to look for in the internet based on task like deploy an MCP server and try to
7:22
produce content that is susceptible to pick to be picked up in such search search results in order to appear in the conversation and at least be uh there
7:31
when somebody is trying to find the perfect solution for deploying MCP server.
7:38
Um marketplaces that comes with host is another way where you can have a great impact if you want to be discovered.
7:44
That's the fourth and last way of being discovered. Uh here for example I put uh Atlas. Atlas which is one also of the
7:51
small product that we built at Alpic to help you better understand um um agent uh environment. Atlas list all of the
8:00
plugins uh ecosystem inside cloud code and chp. So plug-in ecosystem is skills
8:07
and mcp server packaged together to uh your to provide your solutions inside those ecosystems. If you're inside this
8:14
list, chances are um you will get uh uh at least reference or or suggested in
8:22
sessions where somebody might be looking for um hosting solution or for an image generation solution because those
8:30
ecosystem will provide some ways for the agents to discover them and provide a way for the user to add them inside their conversation. So that's the last
8:39
way to be discovered is be on those ecosystem as a brand so that your solution is visible to uh agents.
8:48
Now that your solution is uh found there is an extra step for it to be actually used and used properly in production.
8:58
And um being found through a web search or a web fetch or through marketplace is not enough for the agent to go and
9:07
perform the actual task that is going to bring you value as a service provider.
9:12
Um in order to do that u most of the time what uh agents have been doing until today is rely on the exact same
9:20
set of tools that helped us find our solution in the first place. So if they stumble on your domain on your product using a web search they are going to
9:29
rely on their existing web capacity to interact with your platform try to create an account login on it and use
9:36
your service. So they are going to through their virtual machine use a lot of uh browser use especially since last
9:43
six months where the quantity of virtual machine available to agents have been greatly increased. Um so now they have
9:50
browser that they can use to perform the same exact set of action that human perform when they want to start using your service. Problem is when you use
10:00
browser use to interact with the service. So basically controlling the pointer and controlling the browser through an AI agent you have four big
10:08
failure point that is going to uh impact quite a lot the usability of your product. First one is um the uh agents
10:17
trying to guess the intent from tools it has. So most of the time it's going to pass existing DOM of the website is scrolling or screenshot of what is
10:26
actually seeing and trying to guess what the intent of this specific button here does so that it knows when to press it
10:32
to act specifically on the interface. If it fails um as you may have seen many times on web application you will see a
10:41
toaster saying something bad happened and doesn't work which is not a lot of detail for an agents to act upon. So details in errors that are displayed
10:50
through trust is a painful very painful for ber use. The quantity of tokens that are injected into context especially the DOM that is being described which is
10:58
usually quite large with a lot of elements that are not relevant to take decision is token consumed into the context and additional time to generate
11:07
inference and decide where to click or what to put. And last but not least um once your uh AI agent has access to the
11:15
complete set of your browser it means not only the tab is looking at but also other tabs so other services and there is no way to contain it specifically to
11:23
this tab in order to cope for all those things.
11:28
Um there are surfaces that you can act upon to make it more usable. And today I'm going to talk about three specifically, but there are many others.
11:38
Um, like in the AI agent world, there is a new technology coming up every day.
11:43
Those are the three most used surfaces that an agent is susceptible to use if not using browser use. And it will use them most of the time if you provide
11:52
them, which is a nice addition. That's why browser browser use most of the time is a default. It will always be there because it's been there for humans for
12:00
quite a long time. But if you provide those, you will have better chances of having agents successfully use your product.
12:07
Let's look at them one by one. Um let's start with WebMCP. Who implemented or played with WebMCP here? With a quick
12:15
show of hand. Okay, a few hands. Um for those that don't know, WebMCP and MCP
12:24
have nothing related, which was a perfect naming from Google. Um the only thing that they rely on which is common
12:31
is um providing tools to a model to act upon but that's all. Web MCP is um
12:39
protocol to extend web pages with tools natively made to be used by an agent. So
12:48
instead of looking at a page interpreting the DOM trying to find out which button to click or which input to
12:56
input to fill it will have through the browser a list of all tools a web page
13:03
exposed for an agent to be used in the same format an MCP server would expose tool to a model. So a description, a
13:11
name, an input sha saying which kind of parameter expect and what's going to be outputed from the operation.
13:19
I don't need to guess whether this specific button or this specific form is what I'm trying to achieve on the on the
13:26
website. I have tools like invite user or deploy application that I can interact with programmatically from a
13:35
model uh standpoint uh without having to figure out uh if this is a correct place in the interface to click into. Um I'm
13:43
going to show you a little demo just to illustrate this. So this is codeex uh
13:48
running the browser uh on alpic website using webmcp
13:56
to find different actions it can perform the website. So it was quite quick but uh what I showed just before launching
14:04
codeex on the task of inviting a few members into my team on alpic was um opening the chrome dev tools uh in which
14:11
you have specific debug tools to see what are webmc tool potentially exposed by a web page. Um and among those tools
14:19
um you can see a bunch of them and those tools are all available by any agent with browser capabilities with web mcp
14:27
enabled. As of today only codeex has shipped uh as a major agent um
14:34
compatibility for webmc tools inside it browser that is packaged inside the desktop app. Um, Chrome that is behind
14:42
the spec with Microsoft has not even yet come out of general availability which was a bit of fun that somebody else actually raised it released it before
14:50
they did. Um, and it speeds up consequently all operations that you can do on the website. Plus, you don't need
14:58
always to power the same kind of navigation that used to be the way of doing the action on the website. You can expose as you see on this demonstration
15:07
18 tools like all the red pieces that you see are the tool names that are available on this page. There is not 18 button on the page. So basically when
15:15
the agent lands on Alpic website, it can do 18 different stuff which are not options that a human could physically do with this specific page of the website.
15:24
So you can really do whatever you want in terms of designing of which tools you want to expose at which pages and which visual feedback to provide when the
15:32
model uses specific tool. Like you see here when Codex use the invite member tool, you see the feedback of a new line
15:39
of invitation being shown in the display so that the human behind it still has the feedback that it works as expected.
15:47
Okay. Yeah.
15:50
Another one MCP. So this one is much more known if I ask the same show of hand of anybody working with MCP before connecting one using one. Yeah. Okay.
15:58
Much better. So uh I'm not going to redo the explanation. MCP through a server way of exposing tools. Um one neat thing
16:07
of MCP that uh a lot of people miss compared to other surfaces in the agentic world is standardization of
16:14
authentication. There is only a single way to do authentication on MCP whatever the service you're dealing with. So it's very convenient. Uh web MCP inherits the
16:23
same kind of credentials that are powered to authenticate you on the web app. But there is a wide variety of ranges of authentication services for
16:30
web application. Host 2.1 is the only standard accepted for web MCP and it makes host implementation of providing
16:38
ways for you to give access to a service to an agent standard which is very nice and very neat.
16:45
You can do very powerful things. Here for example is Gemini connected with the MCP server of Alpic trying to pull telemetry in to investigate a bug and
16:54
suggest uh based on usage statistics which change we should make to our MCP
17:01
hosted on Alpic. It's NCP server to get logs of an MCP server hosted. So it's a bit deep but uh you get the idea. Um
17:09
another way of consuming our services another agent consuming it with MCP.
17:15
Last but not least, um CLI and here is the last surface um on on the on the
17:22
authentication part of thing, it's even a messier than the web application uh landscape. But um one of the neat thing
17:31
of the CLI is the ability for agents to write CLA commands which is very good and the ability to pipe them. So uh
17:38
having chaining 20 different inputs and outputs from one tool to another so that in a oneliner you're able to do what you
17:46
would take 20 actions to do in MCP or web MCP world. Um pipes are very powerful but they also come with their
17:54
uh issues that you have much wider access to a wide set of uh ability directly uh inside the shell. So um
18:03
better use them inside a sandboxed environment. Here for example you see cloud code performing a deploy of an MCP server on Alpic using our CLI. All three
18:13
demonstration that I showed are interaction with the Alpic ecosystem using three different tools, three different surfaces.
18:21
Um what's important is guiding the agent when it lands when it decided to work with Alpic on those tool so that it can
18:29
choose which one it wants to pick. If it lands on Alpic.ai, I what am I going to show there so that it goes to my MCP
18:37
server that is hosted on mcp.alpic.ai and um try to get the user to sign in so that it can perform everything with the
18:45
MCP. If it lands on my website or do I direct him to the npm registries to download the CLI? If it lands on my
18:52
website, how do I let him know that it has better chances of interacting with a web page starting a browser because there are a lot of webc tools available
19:01
for him down there. There are multiple standards that are starting to gain traction. One of the latest one I'd like
19:08
to talk about is um the one we call Poppy or um protocol personal agent protocol pap which is quite recent has
19:16
been introduced by um the team at meta for muse plus uh I don't remember who else s I think was inside the standard
19:24
which basically say from a domain where to go look for in terms of mcp server to start interacting with the server um
19:32
there are a bunch of standards that helps direct traffic from your domain to the specific tool that ends. And what's important is providing the information
19:40
on all the standards so that any agents at lands on your domain decide to work with you will get uh the right the direction to the right door to use.
19:50
um to help you understand where are uh different part of your um uh surface
19:58
lacking in usability for agents because even if you ship an AI an MCP server, even if you ship a CLI, even if you ship
20:05
um web MCP tools on your web page, you might have made mistakes in how you design them and what you provide in
20:12
terms of tooling. So again we built some other tooling in ALPIC to help us uh understand better what agents are doing
20:19
and where they fail when they use the tool set at end. Here you see a small report of 210 uh runs simulations that
20:27
we made with various combination of CLI, MCP server, WebMCP tools available on our surfaces with various harnesses,
20:34
cursor and codex mostly and see where they succeed and where they don't and when they don't we can uh dive deep dive a bit more and ah not working anymore.
20:46
So you can end up with some nice recommendation on changes to change on your surface because it lacks for example feedback information on uh my uh
20:55
MCP tooling my CLI tooling when deploying a project because it's lacked some information at some point to be able to self recover and this is what
21:03
feeds our development in alpic to make sure that our surfaces are more and more usable by agents. If we can go to next
21:10
slide. A quick sum up of everything I've been talking about about webcm CP and CLI and where they shine the most and where they perform the best. Um each of
21:19
those surfaces should be implemented. Uh it's important that you implement all of them because depending on the RS that comes and lands on your site. Uh chances
21:28
are it will not use all of all of them and will use one preferably to the other. So important that you provide all those three doors with the exact same
21:37
set of capabilities. At the end of the day, that's just doors to the business that you provide is the same value and same tools that you provide. It's just doors to the to those tools.
21:47
Just quick getting started stuff. Um I'm running a little bit out of time, am I?
21:52
Yeah. One minute. Okay. Um if you design your MCP server, don't try to do one-on-one with your existing API
21:59
endpoints. Uh think about uh stories. do polymorphic tooling to reduce the quantity of tool. Um always output error message that are very verbose so that
22:08
the agent has a self to uh self-reover and u um don't put unnecessary value
22:15
like null and define that takes up context for nothing. Um, if you're developing web MCP, try to go first with the forms. That is the way easiest way
22:24
to start working on WebMCP. Just a few attributes to to fill in on your web application and you will have forms that
22:30
are webmc enabled. Um, if you're working with CLI, try to do non-interactive interaction. Always name argument, long
22:39
name for your argument to make sure it's u very clear and not positional arguments.
22:47
One message from this presentation, open as many door as you can on your business. It will make the life of uh a agents much easier. And if you have any
22:55
additional questions, feel free to come and find me. Happy to discuss your specific use case. Thanks for your attention.