On a recent episode of the How I AI podcast, Brian Scanlan, a senior principal engineer at Intercom, demoed something that should make every SaaS founder pay attention. He kicked off an experimental Intercom command-line tool, handed it to an AI agent, and watched the agent sign up for a fresh Intercom account, install the chat widget on a website, and configure the basics — without a human touching a sign-up form, a settings page, or a docs site. The whole thing happened the way a developer might have done it five years ago, except no developer was in the loop.

Most of us will remember the demo itself. The philosophy behind it deserves more attention. Intercom is openly rebuilding its product on the assumption that its primary customer is no longer a human reading documentation in a browser tab. It’s an AI agent reading the same surfaces and deciding, on a user’s behalf, how to use the product. CLIs, MCP servers, ephemeral APIs — these are the new front door. Everything you spent the last decade polishing for human eyes is now the back door.

Most SaaS roadmaps still assume a person is holding the remote. That’s the assumption worth questioning right now. If you’re building software that an agent can’t use comfortably, you’re building software for a market that’s already shrinking under your feet.

What “agent-first” actually changes

It’s tempting to read “agents are the new users” and translate it as “we’ll add an MCP server and call it done.” That misses the scale of the rebuild. When the assumed reader of your product changes from a human to an agent, almost every interface decision needs revisiting. A few worth thinking about:
  • Documentation. Human docs trade off completeness against scannability. Agents don’t scan — they read everything. Suddenly the half-finished sentence buried under “Advanced configuration” becomes load-bearing. Intercom’s approach, from what Scanlan described, is to treat docs as a programmatic surface in their own right, machine-readable and exhaustively structured, with the human-friendly version as a derivative.
  • Error messages. A human seeing 400 Bad Request: invalid payload shrugs, checks the docs, fiddles with the payload, and tries again. An agent seeing the same error needs enough structured information to diagnose and recover on its own. Agent-friendly errors look more like compiler diagnostics than HTTP responses.
  • Authentication. OAuth was built around browser redirects and human consent screens. Agents need to identify themselves, scope their permissions, prove they’re acting for a known user, and handle credential rotation without anyone being summoned. Agent identity is still being worked out across the industry.
  • Pricing. Per-seat pricing assumes a seat is a person. When one user is directing a swarm of agents, all calling your API on their behalf, what does a seat even mean? Nobody has a clean model for this yet, and whoever finds one first will reshape SaaS economics for the next decade.
  • Telemetry. Product analytics built around human behaviour say almost nothing about agents. You need a different lens — which tools the agent reached for, which failures it recovered from, where it gave up.
  • Distribution. Intercom isn’t shipping its skills via a marketplace or a plugin store. They’re deploying through IT, the way internal tooling has always been deployed. That’s a procurement and control-plane shift, not just a packaging choice — it puts agent capabilities behind the same review process as anything else inside the firewall, and gives administrators a single seam to govern.
None of this is a thin layer on top of an existing product. It’s a redesign of the surfaces customers actually interact with, and the customer in question doesn’t think anything like a human user.

Why this is a bigger shift than “AI as copilot”

For the past two years, the dominant story has been AI as copilot — a clever assistant sitting alongside the human user, suggesting next actions, autocompleting forms, summarising meetings. The human is still in charge; the AI just makes them faster.

Agent-first is different. The human briefs the agent, the agent talks to your product, and your product never sees the human at all. Your job as a software vendor is to make that conversation a good one. An API that forces the agent to guess and retry tends to lose its workloads, over time, to whoever made the same job easier.

I covered the runtime side of this shift recently in the piece on Claude Managed Agents — Anthropic taking on the sandboxing, credential management, and tracing that used to sit with the developer. What’s changing on the SaaS side is the mirror image: the friction of an agent talking to your product. Both have to land before agents are doing useful work at scale, and they’re landing roughly together.

It’s worth saying that the agent-first bet isn’t just a product philosophy. Intercom’s own engineering team has reportedly roughly doubled merged-PRs-per-engineer in the months since they leaned hard into Claude Code, MCP servers, and an internal skills repository. I’m not sure I’d take a self-reported doubling at face value yet — the methodology behind those numbers will need scrutiny once it’s externally checked — but the direction of travel is clear enough. The same instinct reshaping their product surface is reshaping how they build the product, and that internal discipline is what makes the external bet plausible. A company that hasn’t internalised agent-first ways of working is unlikely to ship an agent-first product that actually works.

If you’ve already read the piece on the application layer being eaten from below, this is the natural next move on that board. If agents are bypassing UIs and going directly to APIs, then the API surface becomes the product. The button you spent three sprints designing exists to translate intent into an API call; if the agent can make the call directly from intent, the button is decoration. Some products will adapt and become genuinely better as agent surfaces. Others will keep building dashboards nobody opens because their pricing depends on people opening them.

The long tail of integrations is the prize

There’s a commercial argument for taking this seriously, and it’s the one most SaaS founders should be staring at. Most companies have a handful of high-value integrations they’ve built by hand — Salesforce, Slack, HubSpot, the obvious ones — and a vast long tail of integrations they’d love to have but can’t justify. The cost of building, maintaining, and supporting a custom integration with a niche tool has always been the gating factor.

If your product is genuinely agent-friendly, that gating factor changes. An agent can read your API surface, work out how to talk to it, and stitch it into a workflow with a tool you’ve never heard of, all without your engineering team writing a line of glue code. The long tail stops being a wishlist and becomes addressable. The companies that build for this first will eat workloads that nobody — including them — currently sees as theirs.

The bar matters too. Agents are pickier consumers than humans, in a particular way. A human will tolerate a clunky API because they’ve already decided to use your product. An agent has no such loyalty. If your tool is harder to use than the alternative, the agent simply routes around you, and whoever the agent picks ends up owning the workflow.

Two things to be careful about

Neither of these is solved, and both deserve thinking time before you commit a roadmap to this direction.

Reliability. Agents calling production APIs in a loop are unforgiving of intermittent failures. As I’ve covered in the march of nines piece, every additional nine of reliability costs roughly as much engineering work as the one before it. A product that works 95% of the time for a human can be unusable for an agent that needs to chain twenty calls without intervention — at 95% per call, the chain succeeds barely a third of the time. Designing for the agent means designing for that chain not breaking.

Security. When the customer is an agent acting on someone’s behalf, the question of who really authorised a given action becomes genuinely hard. A recent SoK paper on agentic commerce security from arXiv catalogues twelve cross-layer attack vectors that traditional auth flows weren’t designed for — covering everything from how an agent proves a transaction was sanctioned, to whether two agents can trust each other’s claims about a user. Building agent-first without thinking about this is asking for an incident.

Neither of these is a reason to wait. They’re reasons to build deliberately, with these constraints in mind from day one rather than retrofitted in year three.

What to ask of your own product

If you’re running, building, or buying SaaS right now, the useful question isn’t “should we add an MCP server?” It’s something more like: if I assume my next ten thousand customers are going to use my product through an agent rather than a browser, what would I change?

Some of the answers will be obvious. Better-structured docs. Errors that include enough context to recover from. An auth model that an agent can navigate. Pricing that doesn’t fall apart when the same user runs ten parallel sessions. Distribution channels that reach IT rather than individual end-users.

Others will be uncomfortable. Some of your most-used features may exist only because the human workflow is awkward; an agent doesn’t have that problem and won’t need them. Slabs of your pricing may evaporate. Some of your premium tier value may turn out to be friction the agent simply routes around. The companies that redesign their products before the market forces them to are the ones who get to set the terms; everyone else ends up explaining to a board, in eighteen months’ time, why their numbers stopped making sense.

A useful boundary condition to apply, because not every product is going the same way at the same speed: where the human is mostly translating intent into clicks, agents will compress that workflow fast. Where the human relationship is itself the product — a coaching tool, a high-touch consulting platform, anything where trust between people sits at the centre — adoption will be slower and the redesign less total. Founders who can name which side of that line their product sits on will make better calls than those who treat agent-first as a single uniform wave.

The shift is real and the early movers are already moving. The comfortable assumption that there’s still a human at the keyboard is becoming an expensive thing to keep. Ask the question now, while you still get to choose the answer.

Quick answers

What does “agent-first” SaaS actually mean, and isn’t it just having an MCP server?

Agent-first means designing the product so an AI agent — not a human — is the primary user of your APIs, docs, and integrations. The human briefs the agent on what they want; the agent does the work against your product. An MCP server is part of that, but only the easy part. The harder work, as the article above sets out, is rebuilding documentation, error messages, authentication, pricing, telemetry, and distribution for a non-human reader. A polished MCP server bolted onto a product designed for humans mostly hides the problem rather than fixing it.

Does this kill per-seat pricing?

It puts serious pressure on it. When one user is running multiple agents in parallel, each calling your API, the question of what counts as a seat gets fuzzy. Outcome-based and consumption-based pricing look more sensible, but the industry hasn’t settled on a winner yet — expect a messy few years.

Should small teams care about this now or wait?

Small teams have the advantage here. There’s less product to redesign, and baking in agent-friendly surfaces from day one is much cheaper than retrofitting under deadline pressure later.

How will you know if your product is genuinely agent-ready?

A useful test: hand your published API and docs to an off-the-shelf agent with no human in the loop, and ask it to complete one of your common workflows end-to-end. If it succeeds without a human helping it parse an error or pick the right endpoint, you’re in good shape. If it doesn’t, the gaps you find are your roadmap.