---
type: raw-transcript
title: "Your AI Coding Workflow NEEDS This New Agent Browser CLI"
youtube_id: 7aEQnTsI6zs
url: https://www.youtube.com/watch?v=7aEQnTsI6zs
slug: your-ai-coding-workflow-needs-this-new-agent-browser-cli
published: 2026-01-18
duration: "0:15:14"
fetched_at: 2026-07-21
immutable: true
---

## Transcript

**[0:00:00]** Verscell just made browser automations way more reliable and that's actually a big deal for AI coding. Let me explain. One of the most important strategies for getting reliable results with our coding agents is to give them the tools so they can validate their own work after an implementation. And most applications have a front end and so it's really important for our agent to be able to visit the site and navigate it just like a user would. If we don't have that,

**[0:00:26]** then it's up to us to do a lot of manual validation after the implementation is done and then come back to our agent with any problems that we discover. There's not much of an autonomous loop there. So, I use browser automation tools pretty much after every single feature implementation. So, in my structure plan that I give to my agent, I tell it that after you write the code and you do your other testing, spin up the website, navigate to it, and actually click around, go through it as

**[0:00:53]** a user would, even taking snapshots. So I can review those artifacts myself. And I have quite a process I laid out here. I'll show this more later, but I have it go through everything, even regression testing because it can go through all the user journeys. And this leads to a very reliable site once it comes back to me. So for the longest time, my tool of choice for browser automation was the Playright MCP server. And don't get me wrong, it's still a fantastic tool.

**[0:01:19]** They've done a lot to improve the context usage over the last year, which was definitely the main gripe that people have had, but I still find that it's not always the most reliable. It's pretty good, but not great. A lot of times my coding agent will get tripped up as it's trying to use it, and so the validation just gets a little messy. So, I've tried some alternatives like we have the Playright Skill for Cloud Code, Chrome DevTools, MCP. These are all pretty good, but they've just not been

**[0:01:46]** great in my mind. And so I've been really impressed with the Verscell agent browser. I think for the first time I've actually found something that I'd say is great for an agentic browser automation tool. Not that it's fundamentally different. In fact, it actually uses Playright under the hood, but they just have some really smart strategies for how they allow the agent to interact with their websites. I think it's really the first agenticdriven browser automation tool. And so these

**[0:02:13]** slight issues with reliability, I've just encountered them over time and gotten more and more frustrated, but I've never documented things concretely until now. So, as prep for this video, I did a ton of testing to get the exact numbers for you. So, here I calculated the first try task completion rate. And all I mean by that is how often does the agent use the browser automation tool successfully the first time for each of the individual operations that it does

**[0:02:41]** like taking a screenshot, clicking on a button, filling out a forum field, anything that it does to mimic a user using a website. And so for the Verscell agent browser CLI, it's 95%. It's insanely good because this isn't even considering that it's pretty much going to be 100% if you allow the agent to retry even just once. And so then this drops down all the way to 80 and 75% for the Playright MCP and the Chrome DevTools MCP. And so a lot closer to 100. It's significantly better. But the

**[0:03:11]** question is why? So I'll get into some examples of my testing that shows this in a little bit, but I want to talk about the smart things that Versell has done for the agent browser seal line. I think this will really click with you because old approaches like with the playright MCP, they use selectors and searching like you're matching with elements and so it's non-deterministic. The agent doesn't understand the structure of the site. They just know how to search. And so you navigate to a

**[0:03:37]** page, you get the accessibility tree, which then is deterministic, but it's a massive set of contexts. And so more often you're matching, you're searching through the elements, and that's not always going to work. So you're going to retrieve the elements and then if there aren't any matches you have to retry and this happens a good amount which is why we have these lower percentages here. But what we are doing with the versell agent browser we visit the site and we

**[0:03:59]** take a snapshot and so we are going to return the full structure of the site to the LLM but we're doing it in a really smart way because we're condensing it down into these references that point to the elements the agent can interact with. And so it gets this very consolidated version of the site structure. So now I can see like, okay, here's our button to log in. This is our reference. And so then I can tag that reference and click it with a single call to the CLI. So it's very token

**[0:04:26]** efficient. It's very fast and also reliable because we're not relying on these searches as much. Now, this might seem kind of paradoxical. If we're just taking the entire condensed structure of the site and dumping it to the LLM, there's a lot more room for error. Or so it would seem because at least with the matching and the searching, we're giving some kind of workflow for the agent to specify what it's looking for and then we return only the things that it should

**[0:04:50]** care about. But this really goes along with Verscell's philosophy, which is less is more. And this applies to a lot more than just browser automation, even more than just AI coding. So bear with me on this. This is really important. So back in December, Verscell released their research when they were building their texttosql agent called D0ero. Very very common use case and they started by giving their agent 17 specialized tools. Now this does not mean the agent has a

**[0:05:18]** lot of flexibility because the reason there are so many tools is because there are very specific ways to interact with the database that Verscell was defining for their agent. And so here they only had an 80% success rate. as in only 80% of the time did the agent properly fulfill the request from the user searching through the database. And so Verscell, they took a step back and they thought, what if we just got out of the way of the agent? Instead of defining

**[0:05:42]** all these very specific ways to work with the database, what if we just give it two tools? Primarily a tool to write whatever SQL the agent wants given the schema. And I know that seems dangerous and I'm sure they had to do a lot of building guard rails into the system, but when they did this, they got to a 100% success rate. I know it's hard to believe. I don't even know if I believe it myself, but the proof is in the pudding here. It's a lot faster, less

**[0:06:07]** tokens used, and also less steps overall because the agent doesn't have to bounce between all these different tools to get the answer for the user. And this really does follow the philosophy of less is more. just get out of the way of the agent to make it as flexible as possible. That's what they're doing with the agent browser as well. Instead of different search tools, match tools, fetching the accessibility tree, there's really just condense the site into these

**[0:06:31]** references, send that into the agent and let it decide how it's going to navigate between things. And this ends up working a lot better. The proof is right here in the testing that I did. I'll show you some of this in a little bit here. The sponsor of today's video is Leapter, best known as the trust engine for AI agents. I've been talking about agent flexibility in this video, but sometimes you don't want that. You might have really rigid business logic that you

**[0:06:56]** can't risk the agent messing up because it's going to hallucinate things if you let it define the workflow. Leapter flips the script here. Instead of allowing the agent to figure out the business logic, you create a workflow, something that is deterministic that you give as a tool for the agent to invoke. And so, for example, a lot of customer support bots, you need to be able to calculate some kind of price based on the conversation with the user with a SAS product, for example. So, I'll send

**[0:07:21]** in this request to how I want the price to be calculated. And it's going to generate this workflow that I can use as an agent tool. And in literally just seconds, I have my entire workflow defined. So, these are now all parameters that the agent can decide when it invokes. So, 20 users, I'll say 1 GB API access, premium support. And so now the agent decides the parameters but it does not determine the business logic and then we can take this flow we can turn it into an MCP server connect it to

**[0:07:47]** N8N export it to code a lot of options like I have an N8N agent that's connected to it through MCP here so I ask it to price my SAS I answer its question so it has all the parameters it needs and then it reports back the answer from invoking the workflow directly and sometimes you need this you want the agent to work with the user through natural language but you don't want it to run the entire business logic So this is the hybrid approach that leaper gives us. Leapter is pre-revenue

**[0:08:12]** right now and they're genuinely looking for feedback from people building agentic workflows like you. So I'll have a link in the description to Leapster. Definitely check them out. So this diagram I will link to in the description if you want to check out everything that I haven't covered here like the architecture, feature comparison, pros and cons. Some of this I've covered already. So, I want to get into the quick start here, showing you how you can for free, by the way, use

**[0:08:34]** the Verscell agent browser CLI, how you can incorporate it into your Agenta coding workflows for validation, and I'll show you some of the testing that I did comparing this to the Playright MCP server. And of course, I'll also link to the agent browser CLI in the description, completely free and open source. I'm not affiliated with Versell for this or anything. I really am genuinely impressed with this tool. So, please check it out. I don't think you're going to be disappointed. So you

**[0:08:58]** just have to install it with a couple of commands here. And then if you're on Linux, run this as well. I will say that this did not work well for me on Windows. So I did have to run it through Ubuntu in WSL. You shouldn't have any issues though if you're on Mac or Linux. So once you have it installed, then you can also incorporate the skill if you want. So this is one of the big tips that I have for you is they have the skill.md. If you're using Claude code, you can add this into your skills

**[0:09:24]** directory. So Claude instantly knows how to leverage all the different CLI commands for the browser agent. And so I'll show you here that I took the skill.md from the GitHub repo, what I was just showing you, and I put it in mycloud/skills folder. So I created the agent browser skill right here. I just have the skill.md. And all of this is essentially the readme that we are going through, but instructions specifically for the agent. So it knows how to use all the

**[0:09:49]** different actions and parameters and things that we have for the Versell agent browser CLI. And so I have the CLI installed. Obviously I've got the skill. That is all I need. So now in a cloud code session, I'll actually use my speech to text tool here. I'll say read the read me and analyze the codebase so you understand the structure and how to start the front end. Then I want you to start the front end, visit it using the agent browser skill, and then using the

**[0:10:14]** agent browser CLI to navigate the site, test it as a user would, and also take a screenshot for me to reference as an artifact. So there we go. Send this in. Hit enter. This is a very informal demonstration that I'm giving you right now. Typically, I have this built in as a part of the validation process in my plan. I'll show you that in a bit, but I want to start simple. So I'll pause and come back once it's gotten to the point where it's using the CLI. All right. So

**[0:10:38]** coming back, it just loaded the skill so it understands how to use the agent browser CLI. So we got our progressive disclosure going on there. It has the website up and running and there we go. Now we've opened the browser and we can start doing things like taking snapshots. So it gets the references here. This is what I was showing in the diagram earlier. And so taking the screenshot for me too. Let me go ahead and look at that one. So this is called wordcloud app screenshot. So go to this

**[0:11:03]** one. There we go. This is the wordcloud application. I built this for a live stream that I I just did the other day. And uh then we'll navigate around as a user would. I believe that was a part of my request. Yeah. So, we're clicking on some buttons, filling out some form fields here. You get the idea. And so, in doing this, we have to do a lot less manual validation oursel because if we get the screenshots, proving that things are working as we want them to, we can

**[0:11:25]** just move on. I mean, we're still going to do validation ourselves, but the point of this is the agent can figure out all of the obvious issues, even some of the more subtle ones before control passes back to us. So, I'm not trying to promise you that it's going to be able to fix literally everything, but it sure is pretty close to all the issues that can come up after its implementation. So, the last thing I want to show you is a bit of a glimpse into the testing that

**[0:11:49]** I did to get the percentages that I shared earlier. And it's pretty rigorous what I put it through. So I'm going to give you the high level here showing you some of the slash commands that I created. I don't want to go into too much more detail than this. I don't think that would be interesting, but I think you'll be interested in my general approach here. So I created different cloud code slashcomands to build the same validation workflow for the different tools. And so for the agent

**[0:12:14]** browser CLI, I'll just show you the prompt really quickly for this one. I tell it to understand the codebase, spin up the front end, and then go through the ringer here. a lot of different phases for pretty intense validation. I want to have a good sample size for all the different actions that the agent takes with the browser automation tool. So, there's quite a bit that I ask it to do here. And if we go back to the logs for the agent browser validate, there

**[0:12:39]** are green check marks across the board. And it's very rare. I don't want to like dive too deep into the logs here, but it's very rare that it makes any kind of mistake that it has to come back from. And we see it a couple of times. Like if I scroll down, there's some red right here, and I think there's one more down here, but other than these two like glaring issues. There's nothing wrong with every single action it took, and it's able to pick itself back up immediately. And it's not always the

**[0:13:06]** same with Playright. Actually, for this test in particular, Playright did a pretty good job, but there is this one explicit issue up front. And then also playright has a lot more I guess I would call them silent failures where there's no red like no explicit error message but the agent says like oh this doesn't work I needed to go and retry a different thing and so u there's another one that's really obvious I'll get to that one in a second but I also just want to show for u I used also the

**[0:13:32]** playright um skill and so this one worked pretty well too where it has to generate the code for all the different validation that it does so this one works surprisingly well on a simple web page pages. I find that the Playright MCP and skill is just as good as the agent browser CLI. But when you get to more complicated websites, that's when the agent browser really shines. So, I did a lot of testing as well on larger websites, like go to Amazon, search for a product, scroll around, click on some

**[0:14:00]** other things. I did a lot of that very specific directions on larger websites and this is where it really shone through. So, check marks across the board here. We got like one error, a couple of errors, but besides that, everything works perfectly. But then if we go to playright with the exact same request, we can see some red. And then also just looking at some more of these silent failures as I'm calling it here. Uh, so let me go to one example of this. So like right here, it seems the second

**[0:14:28]** link was still on the same product. Let me go back and find a different product. So it has to like retry these things a lot. But I just don't see that with the Versell agent browser CLI, which is why it's so much more reliable in my experience. So, I hope that you found this interesting and maybe even found a new tool to incorporate into your agentic coding text stack because it really is important to give your agent the ability to check its own work and browser automation is critical for that.

**[0:14:52]** And so, super easy to incorporate. It is a free tool to use. There's pretty much nothing from stopping you for just trying this for 5 to 10 minutes and I think you'll fall in love with it like me. And so if you appreciated this video and you're looking forward to more things on Agentic Engineering, I would really appreciate a like and a subscribe. And with that, I will see you in the next
