How Yutori Stopped Fighting Browsers and Started Shipping Models

‍A conversation with Lawrence, Founding Engineer at Yutori

The short version:

• Yutori builds proprietary computer-use models and trains them on the real, live web rather than synthetic environments.
• That created a hard dependency on browser infrastructure that kept failing in ways that had nothing to do with their models.
• Engineers were triaging proxy errors and dropped sessions instead of improving the AI.
• They offloaded a sizable portion of the browser layer to Anchor, which cleaned up their training data, reduced wasted compute, and freed their team to focus on what actually differentiates them.
• For a 14-person company competing against well-resourced labs, that trade-off was obvious and they made it early.

Yutori is a 14-person AI company building proprietary computer-use agents. Their Navigator series of models powers products that let users and enterprises hand off digital tasks to an AI that can actually browse, click, and act on their behalf. Lawrence, one of the founding engineers, came over from Meta where he worked on large language models. Getting the model right is what he thinks about. Browser infrastructure is not.

Leaning into that division of labor is what lets Yutori move fast.

The problem nobody wants to debug

Pre-launch, Yutori's agents were failing on some of the most important websites in their test suite: home search platforms, general search engines, the kinds of sites that show up in nearly every user task. The failures felt random. And crucially, they didn't feel like model errors.

"We ended up spending so many cycles just trying to triage these," Lawrence said, "and they always tended to be browser instability issues."

For a 14-person team doing cutting-edge applied research, that's a brutal trade-off. Every hour spent debugging a dropped session is an hour not spent improving the model. Running browser infrastructure at scale means managing remote fleets, proxy IP health, and the boundary failures that happen when a headless browser looks too much like a bot. Some websites block you before the agent can take a single action. The agent is ready to go, and as Lawrence put it, “that’s like showing up to play basketball without a court.”

"We'd rather our team focus on what we think is our expertise and what helps us differentiate, which is the agents themselves."

What the split looks like

The division between Anchor and Yutori is clean. Anchor sets up and manages the browser environment. Yutori's Navigator model automates it, perceiving what's on screen and deciding what action to take next.

That "pixels to actions" architecture means the model takes a screenshot as input and outputs the next action, the way a human would look at a screen and decide what to click. Navigator n1.5 can also write custom JavaScript when it chooses to, so no one has to maintain brittle DOM processing scripts. But the approach only works when the browser environment underneath it is stable. A model reasoning well about a page it can't load isn't useful to anyone.

In production, when a user runs a task through Yutori's APIs (finding flights, filling forms, research tasks), Yutori spins up an Anchor browser session to execute it. Anchor handles access, rendering, and proxy. The Navigator model handles intelligence and action.

The RL training angle

The production case is intuitive. The training case is more technically interesting.

Yutori trains using reinforcement learning on the live web, not synthetic environments. Models trained on fake sites encounter a reality gap when they hit the real thing. But training on the real web creates a hard dependency on browser infrastructure quality.

In RL, the model explores the environment and learns from the outcomes of its actions. These explorations are called rollouts, and they're expensive: in compute, in time, and in training signal quality. Every dropped browser session is a lost rollout. At scale, unreliable browser infrastructure degrades the entire training process.

There's a subtler version of this in async RL, where rollouts run in parallel with training updates. If browser sessions are slow, rollouts take longer, the model being trained diverges further from the one that generated the data, and the training signal gets noisier. It's not dramatic. It's just compounding friction that makes every run harder to trust.

Anchor's error logging adds another layer: when a session drops due to an infra issue, it's labeled. Yutori can exclude those trajectories from evals, which means their performance metrics reflect actual model behavior. And when there's no error log, they can confidently treat a failure as a model issue and go debug it. Clean failure attribution sounds like a nice-to-have. At the pace Yutori ships, it's a prerequisite.

The business case

Yutori's Navigator models now support enterprise customers at some of the largest companies in the world. When you're pricing an enterprise API that bundles model inference, orchestration, and browser sessions, you need to forecast costs across all three layers.

"If browser pricing is unpredictable, then we have to start baking that unpredictability into our price," Lawrence said. "The reason we can be very competitive with our pricing is because we know what our infrastructure costs are going to be and we can actually project that."

For a team that's chosen to focus entirely on what makes their models better, predictable infrastructure is what makes the rest of the business legible. That's still the bet they're running.

The broader pattern

Any team building in the computer use or browser automation space hits the same forcing function eventually: the browser is not the product, but it determines whether the product works.

The teams that treat browser infrastructure as a solved problem early get to spend their engineering hours on what actually creates differentiation. The teams that build it themselves tend to discover, after a few months, that they've taken on a second job with its own maintenance burden, failure modes, and on-call surface area — none of which compounds toward their core thesis.

This matters more as the space matures. Evals are getting more rigorous. Enterprise customers have higher expectations around reliability and observability. The models themselves are improving rapidly, which means the browser layer becomes more visible as a source of variance when things go wrong — not less. Clean failure attribution, stable rollout environments, and predictable infrastructure costs aren't nice-to-haves at that stage. They're prerequisites for knowing whether your model is actually getting better.

The underlying principle is straightforward: the further a problem is from your core differentiation, the more it costs to own it yourself. For teams building computer-use agents, browser infrastructure sits at the far end of that spectrum. Yutori recognized that early. Most teams reach the same conclusion — the question is usually just how long it takes.

Yutori builds computer-use AI agents and the Navigator series of models. Learn more at yutori.ai. Anchor Browser provides managed browser infrastructure for AI agents and automation teams. Chat with Anchor here.

‍