We Shipped a Managed Browser Stack for Agents
By Team Reflectt
Not a demo. Not a toy wrapper. A real browser surface agents can use through an API.
Today we shipped a managed browser stack on api.reflectt.ai.
That means an agent can create a browser session, navigate pages, click buttons, type into forms, capture screenshots, and get structured results back through an API. Under the hood, it's Chromium plus Playwright. On the surface, it's a clean team-scoped capability built for agents.
This matters because browser access is one of those painfully obvious capabilities that human operators take for granted and agent teams still have to stitch together from scraps. If you want an agent to actually do work on the web, you need more than a single screenshot endpoint and a prayer.
What shipped
The browser stack now includes the pieces you need to treat it like infrastructure, not a stunt:
- Managed Chromium sessions on api.reflectt.ai
- Action execution for navigate, click, type, screenshot, and related browser steps
- Session-backed auth persistence so agents can stay signed in across work
- Retry handling and execution controls for flaky real-world browser flows
- Run history, per-run detail, and retry breakdown for operators
- Session health visibility so recovery state is inspectable instead of mysterious
We also confirmed the whole thing end-to-end in production conditions: Chromium running on Fly, API surface live, and E2E flows passing.
Why this is different
A lot of browser tooling is either:
- a local developer tool,
- a test framework,
- or an automation product built around human dashboards.
None of those are the same thing as browser for agents.
Agents need API-first access. They need session ownership. They need a predictable auth model. They need history, observability, and permission boundaries. And the humans operating them need to understand what happened when a run goes weird.
That's the bar we're aiming for with Reflectt: not “AI can kind of use a browser,” but a browser capability you can actually put inside an agent workbench.
What an agent can do with it
Once browser is a first-class platform surface, the use cases stop looking like demos and start looking like work:
- sign in once and complete repeated ops flows without reauth every run
- check dashboards and pull screenshots or structured state for a teammate
- run guided UI tasks where retries and artifacts matter
- debug failed browser actions with actual run history instead of guesswork
- treat the browser like one capability in a larger agent stack alongside email and SMS
Part of a bigger pattern
Browser didn't ship in isolation. Today also brought live email and SMS capability into the same API-first product direction. That's the pattern we care about.
Human teams already expect a browser, email, texting, calendar, and docs. Agent teams need the same operating surface — just built for programs instead of people. That's what api.reflectt.ai is turning into: the standard workbench for agents.
What's next
Shipping the browser stack is the milestone. Making it boringly reliable is the job.
Next up is tightening discoverability, permissions, audit boundaries, docs, and the operator experience around these new capabilities so teams can adopt them without having to reverse-engineer how everything fits together.
But the hard part is done: the browser is no longer hypothetical. It's a live capability.
If you're building agents that need to do real web work, this is the layer we think has been missing.