Warning: Naive.
A couple weeks ago I AI-wrote to myself about the "SaaS is dead" panic — $285 billion wiped, everyone freaking out. The reality: SaaS isn't dead, but value is getting sucked upward into the agent layer and downward into the data layer. The thin UI middle is getting crushed.
Then MCP and WebMCP show up as the buoy. MCP standardizes how agents talk to servers. WebMCP lets websites publish "tool contracts" for agents. Together they tell SaaS vendors: "expose a structured interface and agents can still use you."
APIs, REST, GraphQL, webhooks — those aren't going anywhere. That's backend-to-frontend, system-to-system. No human needed. Fine.
But there's a layer above all of that. Where you're logged into 12 SaaS tabs copying data between them like an animal. That layer is about to get a new runtime.
Chrome as MCP
Here's the thought.
MCP lets agents talk to servers. WebMCP lets agents talk to websites. But what if Chrome itself becomes an MCP? Not one website. Not one server. The whole browser — every tab, every session, every logged-in SaaS tool — as one unified agent surface.
Today you tell an agent "send Q1 numbers to finance." It needs an MCP server/connection for your spreadsheet, another for email, OAuth for both, someone to wire it together. CFFBRW somehow support this.
Tomorrow: the spreadsheet is tab 3, Gmail is tab 7. You're already logged in. The agent reads the DOM, grabs the data, switches tabs, composes the email. Done. No API. No OAuth. No integration. Because the human already did all the integration work — by logging in.
This isn't Selenium with extra steps. Old automation works outside-in — an external program guessing at buttons. This works inside-out — the agent lives in the page, reads structured DOM text, inherits your session. And the LLM closes the gap — "click submit" works whether the button says "Submit", "Send", or "Confirm."
Is it as reliable as a typed API? No. But it covers a surface APIs never will — the millions of internal tools, admin panels, government portals that will never get an API.
SaaS Gets a New User
SaaS doesn't die. It just gets a non-human user.
The agent doesn't need the vendor's cooperation. It needs the UI to exist. If a human can do it in a browser, an agent can do it in a browser. Your SaaS stays in the loop — not as a tool the human clicks, but as a tool surface the agent operates.
Counterpoint to myself: this only works if the UI is agent-friendly. Poorly structured DOMs, no semantic HTML, aggressive bot detection — those break it. So there's a new competitive advantage: agent-friendliness. SaaS tools that make their UI easy for agents win. The rest get routed around. I even tried to build a skill called Retrofit SaaS for Agent; I make sure CFFBRW support BYOModel.
Where CFFBRW Fits
This is where I get hopeful. Because CFFBRW is built for exactly this future, or at least as I see it.
CFFBRW compiles markdown workflows into execution plans. Today those plans run steps against MCP servers (this is the hard part) and typed connectors — structured, reliable, deterministic. That handles the backend layer. APIs, data, system-to-system.
But the Chrome-as-agent layer? That's a new connector type waiting to happen. Imagine a CFFBRW workflow step that doesn't call an API — it instructs an agent in the user's browser. "Fill in the expense report." "Approve the PR." "Download the invoice from that vendor portal that hasn't had an API since 2019."
The workflow orchestrates. Chrome executes. The user's logged-in state is the auth layer.
Markdown workflow (CFFBRW)
↓ compiles to
Execution plan
↓ steps run against
┌─────────────────────────────────────┐
│ MCP servers → structured APIs │
│ Connectors → typed integrations│
│ Chrome agent → browser UI layer │ ← new
└─────────────────────────────────────┘
Three tiers of reach. MCP for structured tools. Connectors for typed APIs. Chrome agent for everything else — the long tail nobody will ever build an integration for. CFFBRW becomes the orchestration layer that ties them all together.
That's the vision. Markdown in, results out, regardless of whether the step hits an API or clicks a button in tab 4.
Or maybe CFFBRW is worth no more than a AI-touch-grass.
What Happens Next
Chrome ships an agent API. Not "if" but "when." WebMCP is already in Chrome Canary. Someone will build a Chrome-native MCP that exposes all open tabs as tools.
SaaS vendors adapt or get routed around. Smart ones go agent-friendly. Stubborn ones add CAPTCHAs. Market decides.
Orchestration becomes the real product. Individual tools matter less. The thing that coordinates across all of them — across APIs AND browser UIs — that's where the value concentrates. That's CFFBRW's bet.
I could be wrong about the timeline. But MCP gave agents hands for servers. WebMCP gave agents hands for websites. Chrome-as-agent gives agents hands for everything.
SaaS was drowning. MCP threw it a buoy. Chrome-as-agent rebuilds the boat. And CFFBRW wants to be, just, a... I don't know yet.
Signal: PageAgent (github.com/alibaba/page-agent) — MIT, Alibaba
Top comments (0)