Agents should express the outcome they want, while a separate tool-selection layer chooses an allowed tool and records why it was selected.
2
WebMCP can expose workflow-specific tools that appear as an agent moves through a site, including tools made for debugging and QA.
3
AI-generated code needs verifiers that test business outcomes and inspect the whole application before a pull request reaches human review.
Summary
The episode examines how AI agents can take on more work without losing accountability. The speakers discuss using Jev to classify an agent's intent and select tools, which can make tool access narrower and the reason for each call easier to audit. They connect this idea to MCP and WebMCP, where a website can expose workflow-specific tools such as buying dog food, choosing a product, or adding it to a basket. WebMCP can also expose a private debugging server for a QA agent. The conversation then turns to personal assistants, including travel agents and household managers, and why simple subscriptions do not handle changing context well. In the final section, the speakers argue that AI-written code needs stronger verification. Cucumber-style tests can capture the business outcome behind a feature, while a QA subagent can test an entire application, take screenshots, and explain what broke before a pull request is submitted.
Agents can select tools from intent instead of seeing every available tool
The proposed design gives the agent one tool for finding tools. The agent sends its desired action, the effect it wants, and the reason for the request. Jev then selects an available tool or reports that no tool can perform the task. This limits the agent's knowledge of the tool set, so it cannot recommend a tool it is not allowed to call. It also creates an audit trail for why a tool was selected, alongside the usual record of which tool was called and when. The speakers say this makes tool descriptions and intent definitions possible targets for evaluation and fine-tuning.
The reported computer-use results make the cheap-and-accurate promise less convincing
The speakers discuss benchmarks run by Steve from builder.io on Jev's computer-use capabilities. They describe results of about 33 percent accuracy after retries, with the first attempt closer to 18 percent. That challenges the claim that Jev is both inexpensive and as accurate as a larger model. A blended approach may work better: use Jev first, then fall back to a smaller model such as Haiku when the classifier cannot handle the input. The restriction on inputs is part of the problem, since a classifier may not be able to use a screenshot in the way a computer-use model can.
WebMCP can turn a website's workflows into a staged tool tree
WebMCP lets a website expose tools to an agent that is interacting with it. The speakers describe a pet store that presents high-level options such as buying dog food, buying cat food, or searching. After the agent chooses dog food, the next page can expose tools for selecting size or type and adding the item to a basket. Each stage provides a smaller set of relevant actions instead of exposing every possible tool at once. They compare this to a video game skill tree, where one choice unlocks the next set of choices. Jev can classify the user's intent against the tools available at each stage.
Workflow-based tools describe the outcome a person wants
The discussion contrasts raw APIs with tools designed around a workflow. Raw create, retrieve, and update operations leave the caller to assemble the steps, like LEGO without instructions. A workflow-based design starts with what the user is trying to achieve. The speakers use clean floors as an example: the user wants the outcome, while a vacuum cleaner is only one possible tool. The same idea applies to agents. Someone asking for dog food to arrive tomorrow may care about the delivery deadline more than the cheapest product. The agent needs the goal and its constraints so it can choose an appropriate path.
Personal assistants need context that fixed subscriptions do not provide
The speakers imagine agents that manage household supplies, travel, and tutoring. A coffee subscription fails when someone travels for several weeks or changes how much coffee they drink, because it sends a fixed amount on a fixed schedule. A useful assistant would remember the desired amount, notice changing circumstances, and order at the right time. The travel-agent example goes further than suggesting destinations. It includes booking, handling delayed flights, and replanning the trip. The broader idea is to give ordinary people some of the support associated with a house manager or personal travel agent, while keeping the assistant inside a chat workspace where information can be edited and organized.
The speakers return to Cucumber-style testing, where tests describe business outcomes rather than only checking method or feature behavior. Setting up a user might include creating an account, assigning permissions, sending an activation email, and adding the person to a team. Encoding that workflow in tests preserves the reason the code was written. It lets a team ask what problem the code solves and whether the intended result still happens. This is especially useful in large codebases where the purpose of an AI-generated change may be hard to infer from the implementation alone. Writing these tests also requires understanding the business, not only the programming details.
A QA subagent can verify an entire change before human review
One proposed verifier runs before a pull request is submitted. A subagent tests the new changes across the application, checks that expected behavior still works, and writes a document with screenshots. It can record that a button led to the correct page or report that a link, page, or visual element is broken. This gives the coding agent direct evidence about what failed. The speakers connect this with reducing the amount of human review for checks that can be automated. They also point out that people regularly open pull requests that already fail existing linting or tests, so automated checks alone do not guarantee that someone will act on a failure.
"Build the verifier that will explain to the agent why this code is going to automatically be rejected if you submit it as a pull request."Demetrios Brinkmann45:40
Who should watch
You are designing agents that can call tools and need a clearer record of what they intended to do and why a tool was selected.
Your product exposes APIs or WebMCP tools, and you are deciding whether to model raw operations or complete user workflows.
Your team is reviewing AI-generated code and wants tests or QA agents that check business behavior before a pull request reaches a person.
