In my previous article, I argued that we still need human QA because as long as humans are using software, there are aspects of the user experience that only humans can fully appreciate. But what if the user of the software is an agent?
Is This Change Really Happening?
Agents can already operate software for people. The tools are real; how much everyday software use they account for is harder to establish. I would not redesign a product around a traffic trend we have not measured. I would pay attention to tasks where an agent could plausibly save someone time: booking travel, filing expenses, or ordering supplies.
Capability is uneven. In OSWorld 2.0, the best tested setup completed about one in five of 108 long, demanding computer-use workflows under the study's rules. That is not a success rate for your app. The revealing failures were agents losing constraints, guessing instead of asking, and skipping verification. A convincing click sequence can still end at the wrong destination.
How Do Agents Use Software?
There are two main routes. With MCP tools, an application exposes actions and data directly: find an order, create a ticket, update a record. The agent calls a named tool and reads its result. It may never see the interface.
With computer use, the agent operates the interface: inspect a screenshot, click, type, scroll, inspect again. Some browser agents can also work from the page's accessibility tree and element references. In practice an agent may combine routes, using a tool for one step and a screen for the next.
For QA, these are different surfaces. A clear button does not fix an ambiguous MCP response. A well-designed tool does not fix a confusing confirmation screen.
Should We Still Care About Human UX?
Yes. If an agent books my flight, it may operate the interface, but I still need to get to Vienna on Tuesday. I may need to approve the fare, understand what happened, or take over when the agent gets stuck. A product that works only when an agent interprets it correctly leaves the person with very little control when things go wrong.
Good human UX also helps some agents. Clear labels and visible state make an interface easier to understand; accessible names help people using assistive technology and may help agents reading the accessibility tree. That overlap is useful, though agent success is no substitute for testing with people.
How Do We Make Software Usable by Agents?
Start with a task a customer might delegate: “Order one replacement charger, delivered by Friday, for no more than €40.” Define success before the agent runs. It should not invent its own pass criteria.
- Watch where it gets stuck. Try the interface and, if available, MCP. Record when the agent misreads a label, loading state, tool result, or error.
- Change the conditions. Raise the price or move the delivery date. Does the agent notice the request can no longer be met and ask for help?
- Interrupt the journey. Add a dialog or timeout after submission. Can the agent recover without placing a second order? Can a person review the purchase first?
- Check the result yourself. Inspect the order record, quantity, total, and delivery promise. A green screen and a confident summary are not proof.
If your team builds the agent, test whether untrusted page text can redirect it; computer-use guidance warns about this. For outside agents, report observed failures without claiming one run certifies them all.
Repeato's visual tests can help catch changes in what appears on screen. The agent journey adds a different check: did the software deliver what the person actually asked for?