You built a signup flow, a settings page, a checkout. You know exactly where every button lives, which is the problem. You cannot see the confusing parts anymore. A coding agent connected to your product can walk it cold, note what trips it up, and hand the results back as something a developer can act on. Here is how to set that up and what to ask for.
Connect the agent to Cobalt Capture over MCP
The agent needs two things: access to your running product, and a way to write its findings into a structured review. The second part is what the MCP server does. Follow the steps in connect your coding agent over MCP to register the server with Claude Code, Cursor, or whatever you use. Once it is wired up, the agent can create a review, add items, attach captured stills, and publish, all without you leaving your editor.
Point the agent at a local URL or a staging URL. If your reviewer link works for you but not for a teammate, that is a separate networking issue, not an agent one. The agent runs where you run it.
Write the test brief so the agent behaves like a first-time user
The quality of the study depends entirely on the instructions. A vague prompt like "test my app" gets you a vague report. Give the agent a persona and a task, not a checklist of your features.
Something like this works: "You have never seen this product. You want to create a project and invite one teammate. Start at the homepage. At each step, note what you expected to happen, what actually happened, and anything that made you hesitate. Capture the screen whenever something is confusing or broken."
The persona matters because it stops the agent from using your internal vocabulary. A real new user does not know your feature is called "Workspaces." They look for the word "team" or "invite." A well-framed persona surfaces that gap. The full method for AI usability testing covers how to write personas that produce findings you can actually use.
Give the agent one task per run. Signup is one study. Checkout is another. Bundling five journeys into one prompt produces a shallow pass on each. Narrow tasks produce detail.
What the agent captures and how each finding is recorded
As the agent moves through the flow, each captured screen becomes an item in the review. The agent crops the still to the relevant region and writes a comment: what it expected, what happened, and why the step was hard. When a specific element is the problem, it drops a numbered pin so the finding points at the exact spot rather than the whole page.
You are not getting a video. Cobalt Capture takes still frames, not recordings, which is what you want here. A screen recording of an agent clicking around is nearly useless to read; you have to scrub it to find the one moment that mattered. A cropped still with a pin and two sentences is the moment, already isolated. If you are weighing the two formats, screen capture versus screen recording lays out when each one earns its place.
A single finding might read: "Expected the invite button on the project page. It is buried in Settings, three clicks deep. Pin 1 marks where I looked first." That is a sentence a developer can fix without a meeting.
Publish the study and route it to the right reader
When the run finishes, the agent publishes the review. It gets a short public URL at /r/<slug> that anyone can open, no login and no app. That same review is available three ways, which is the point.
| Reader | Format | Why |
|---|---|---|
| You or a PM | Public link or PDF | Skim the findings, share in a doc |
| A stakeholder | Word export | Drop into a report |
| The agent doing fixes | Markdown at /r/<slug>/markdown | Feed the findings straight back as tasks |
That last row closes the loop. The same agent that found the problems can read the markdown version and start fixing them. If you want the findings turned into a work queue, turning a captured review into a task list shows the exact prompt.
Read the findings and mark what is real
Not every finding is worth acting on. An agent will sometimes flag a convention that real users understand fine. Read the study yourself. On each item, anyone with the link can post a comment, and as the review owner you can mark each one resolved as you triage. That gives you a clean record of what you decided without a separate tracker.
Watch for the findings where the agent hesitated. Hesitation is the signal. A step the agent completed instantly is fine. A step where it wrote "I was not sure whether to click here or there" is a real friction point a new user will hit too.
Run the same brief again after you ship the fixes. If the agent no longer hesitates at that step, you fixed it. This is the tight version of a usability loop, and if you are building with an agent day to day, it fits the same feedback loop for vibecoding you already use for bugs.
Start a run now. Open a new review, give your agent one task and one persona, and see where it hesitates.