The promise of AI agents falls apart at the login screen. They choke on two-factor authentication, trigger anti-bot alarms, and collapse when a website decides to move a button. A small Boston team thinks the solution isn't better browsers—it's getting rid of them entirely.
Rindler, a two-person startup from Y Combinator's Summer 2026 batch, has built what it calls a "translation layer" between AI agents and the web. The idea: turn messy, human-facing websites into clean, structured data feeds that agents can call like any other API. No browser automation. No pixel-chasing. Just predictable inputs and outputs, even when the underlying site redesigns its interface or throws up a CAPTCHA.
It's an ambitious bet on abstraction over control. And it arrives at a moment when the gap between what AI agents promise and what they can actually do on the web has never been more obvious.
Why Agents Keep Breaking
The current approach to web automation hands developers a browser and wishes them luck. Most agent frameworks—tools that let AI navigate websites—essentially give you Selenium with a language model attached. You get programmatic access to Chrome or Firefox, then watch your agent attempt to parse login forms, dodge pop-ups, and guess which button actually submits the checkout form.
The results, frankly, aren't great. Research from the REAL benchmark last year clocked frontier language models at under 41% success on website interactions that should be deterministic. BrowserArena, another evaluation suite, documented the failure modes in detail: authentication walls that agents can't navigate, unexpected pop-ups that derail task flows, bot detection systems that shut down automation attempts before they start.
Each company building agents ends up solving identical problems. They map out login sequences. They handle cookie banners. They write brittle code that breaks when an e-commerce site A/B tests a new checkout button.
Rindler's pitch is to absorb all of that pain centrally. Rather than exposing a managed browser session—the model companies like Browserbase or Kernel have pursued—it exposes websites through the Model Context Protocol as structured JSON endpoints. Same input every time. Same output shape. If the website shifts its layout or injects a regional compliance banner, Rindler's middleware catches it. The agent never knows anything changed.
How It Works (In Theory)
The technical approach centers on MCP, a standardization effort that gained traction through 2025 and into this year. Think of it as a common interface specification—agents can discover and call tools through MCP the way mobile apps call platform APIs. Anthropic's Claude Code and several other agent runtimes support it natively.
Rindler's implementation, laid out in the llms.txt file that's become the standard way for agents to read documentation, works something like this: An agent calls start_session to connect to a website that Rindler has already onboarded. Authentication happens once, using OAuth 2.0 PKCE flows—no API keys to rotate or leak. Then the agent uses dispatch_action to interact with the site and extract_content to pull back data. All of it returns as structured JSON, not raw HTML.
The determinism claim matters for anyone trying to put agents into production. If that e-commerce site redesigns its checkout flow next Thursday, a traditional browser-based agent breaks. With Rindler's layer in between, the JSON schema stays constant. "We're the translation layer between AI agents and the web," CEO Michael Serrano told me when I asked him to distill the pitch. He's a former machine learning engineer at Roblox with research work at MIT CSAIL; his cofounder Arthur De Los Santos finished his computer science degree at MIT this year.
Token efficiency is the other half of the value proposition. Parsing raw HTML can burn upwards of 50,000 tokens per page—sometimes more if there's a lot of JavaScript-rendered content. Rindler claims its structured responses typically land in the hundreds of tokens. For applications making repeated web calls, that delta compounds into meaningful cost and latency savings. Maybe more than the founders initially expected.
The Catalog Constraint
There's a catch, and it's not a small one. Rindler doesn't work with arbitrary URLs. The company maintains a catalog of pre-onboarded sites—websites where the authentication flows, navigation patterns, and extraction schemas have already been mapped. If the site isn't in the catalog, an agent can't use it through Rindler.
That constraint trades flexibility for reliability. It also creates a scaling challenge: the product's value grows with the size of the catalog, but each site requires upfront integration work. The company frames some of its supported sites as having a "sanctioned channel" for agent access—suggesting that for certain bot-protected or JavaScript-heavy sites, Rindler's MCP route might be the officially supported way for agents to get in. Whether that's a partnership claim or positioning remains unclear; the company hasn't published customer names or case studies yet.
As of early July, there's no public pricing page. No testimonial quotes. No press coverage outside the Y Combinator directory. The company has migrated its MCP endpoint from a Railway-hosted development URL to a branded mcp.rindler.ai address—the kind of infrastructure cleanup that suggests a team moving from prototype to something they're ready to show customers.
A Crowded Starting Line
Rindler enters a space that's gotten noisy fast. Browserbase raised a $40 million Series B in mid-2025 and has since launched managed browser agents. Unbrowse positions itself as helping agents tap into websites' internal API routes. Browse AI offers web scraping packaged as REST endpoints. Kampala, another recent YC company, reverse-engineers mobile apps into APIs. Each takes a different cut at the same underlying problem.
The distinction Rindler emphasizes is abstraction level. Instead of handing the agent a browser to control or scraping tools to configure, it hides the entire web interaction behind stable MCP tools. The agent never sees HTML, never worries about selectors, never handles authentication. Just: here's the action you want to take, here's the structured data back.
Whether that model wins depends on execution details the company hasn't made public yet. How many sites can they realistically onboard? How quickly can they respond when a site changes its flow? What happens when a supported site introduces a new feature or workflow that wasn't in the original schema?
And perhaps the bigger question: do agent builders prefer this level of abstraction, or do they want the flexibility—and mess—of lower-level access?
Infrastructure for Software That Configures Itself
For now, the product exists mostly as documentation aimed at developers building agent applications. Interestingly, Rindler's integration guides seem written for AI agents themselves—part of a broader pattern where companies assume software will discover and configure its own infrastructure. Whether that future actually arrives at scale is anyone's guess.
But for teams building agent applications today, the core promise resonates. Authentication is annoying. Bot detection is annoying. Fragile selectors that break every time a marketing team runs an A/B test are really annoying. If someone else wants to handle all of that and just give you a stable JSON endpoint, that has obvious appeal.
The question is whether Rindler can build the catalog fast enough, and whether the abstraction holds up when agents start doing truly complex multi-step workflows across dozens of sites. The company is small—two technical founders, fresh out of YC—and the competitive landscape includes companies with significantly more capital and engineering resources.
Still. If AI agents are going to move beyond demos and into production systems that actually work reliably, someone needs to solve the web access problem. Rindler thinks the answer isn't better browser automation. It's not needing a browser at all.
