Spinning up Chromium and scripting clicks is the easy part of running a web agent in production. The developer Harsehaj laid out, in a post on X, five additional infrastructure layers that separate a demo from something that survives real traffic: pools of browsers kept warm, isolation enforced at the VM level, identity coherence paired with residential IP routing, a unified system for replay and tracing, and gateways spanning multiple models.

Each layer exists to solve a failure mode that only shows up at scale. A cold Chromium instance takes real time to launch, load extensions, and warm its cache, and an agent that spins one up per task eats that latency on every single request. A pool of pre-warmed browsers removes the startup tax, at the cost of managing a fleet instead of a single process.

Isolation matters because a web agent executes code it did not write. Every page it visits can run arbitrary JavaScript, and an agent clicking through untrusted sites without a hard boundary between tasks is one malicious redirect away from leaking credentials or corrupting a session. VM-level isolation contains that risk per task rather than trusting the page to behave.

Identity and routing address a subtler problem: getting treated like a bot. Sites fingerprint browsers, sessions, and IP ranges, and an agent that looks coherent across requests, then routes through residential IP space instead of a data center block, survives checks that would otherwise block or shadow-ban it. This is the layer that decides whether the agent can reliably reach the page at all.

Replay and tracing exist because agent runs are not deterministic. The same task can click a different button on two attempts depending on what the page renders, and without a unified trace, a failure is nearly impossible to reproduce or debug after the fact. This is the layer most demos skip and the one production teams cannot.

The multi-model gateway layer is about not depending on one vendor’s uptime or price. Routing a task across models lets a team fail over when one provider degrades and shop for cost on tasks that do not need the strongest model available.

Harsehaj’s real argument is a build-versus-buy line. That stack is worth owning in-house only in narrow cases: when it functions as the company’s strategic edge, when regulation or scale makes self-hosting a requirement, or when the infrastructure is the product being sold, not a background utility. That is the same question companies asked in the 1990s about running their own data centers, and most answered it by renting instead. Teams evaluating agent infrastructure now should ask whether reliability at this layer is actually their differentiator before committing engineering time to rebuild what a vendor already runs at scale.

Posted by Harsehaj, on X, July 21, 2026.