A widely discussed post from Thariq Shihipar (Claude Code, Anthropic) argues there's a straightforward, underexploited business move sitting in plain sight: "take your SaaS, make it headless, let agents use it, charge per interaction esp for enterprises." It's a genuinely interesting thesis worth taking seriously on its own terms — not because of who reposted it or what side businesses sprang up around the tweet, but because it names a real structural gap in how most SaaS companies price and expose their products today.
TL;DR
| Question | Answer |
|---|---|
| What's the idea? | Build a genuinely complete agent-facing interface to your product (not a token MCP server), price it per interaction |
| Why does this create new revenue? | Seat-based pricing assumes one human clicking around; agent call volume doesn't fit that model |
| Why hasn't everyone done it? | Fear of agents (or competitors) disintermediating the human-facing product they've built their business around |
| What does "headless" mean here? | Every capability of your product reachable programmatically — via MCP, API, or CLI — with real feature parity to the UI |
| Is this proven at scale? | No — it's a compelling, testable thesis, not an established playbook yet |
What "headless" and "charge per interaction" actually mean
Two distinct moves are being proposed here, and it's worth separating them.
"Headless" means real feature parity for agents, not a demo integration. A lot of companies already ship an MCP server or a public API. The distinction being drawn is between a token gesture — a handful of read-only endpoints wrapped in an MCP server mostly for marketing — and a genuinely complete interface where an agent can do everything a human could do in the product's UI. Most companies today ship the former, largely because building and maintaining full parity is real, ongoing engineering work, and because a half-hearted interface is a way to look agent-friendly without actually enabling agents to route around the product entirely.
"Charge per interaction" means metering value the way agent usage actually happens, not the way human usage happens. Seat-based SaaS pricing assumes a human logs in, does some work, logs out — usage is naturally bounded by how many hours a person can spend clicking. An agent has no such bound. If an enterprise customer's agents are calling your product hundreds or thousands of times a day on the customer's behalf, seat-based pricing either massively undercharges for that value or, more commonly, simply doesn't have a mechanism to capture it at all, because the product was never built to be used that way.
Why most companies aren't doing this
The honest reason, and the one worth sitting with rather than dismissing: a genuinely complete agent interface makes disintermediation easier, not just agent adoption easier. If your product is fully and cleanly usable by an agent, that same interface makes it easier for a competitor to build a wrapper on top of your API, for a customer to automate around your UI entirely and stop noticing your brand, or for a general-purpose agent to route a task to whichever backend is cheapest without the user ever seeing your product's interface at all. Building a genuinely open, complete surface is a real strategic risk for companies whose moat has historically been UI polish, workflow lock-in, or simply being where the human's attention already is.
That's a legitimate tension, not paranoia. The interesting strategic question — one the original thesis doesn't fully resolve — is whether the revenue captured from agent traffic at scale outweighs the risk of enabling that disintermediation. For companies whose value is genuinely in the underlying data, workflow logic, or integration surface (not just UI convenience), the math likely favors going headless. For companies whose entire value proposition is the UI experience itself, it likely doesn't.
What people are asking
“Isn't this just an API with MCP branding?” No — most public APIs were designed for human developers writing integration code, not for an agent choosing tools mid-task. MCP adds schema discovery, tool descriptions, and host-side orchestration, but the gap the thesis names is feature parity: can an agent complete a full workflow without a human filling gaps in the UI?
“Won't agents just scrape the UI anyway?” Some will, badly. Fragile browser automation breaks on every redesign, cannot authenticate cleanly at scale, and violates most ToS. A deliberate headless surface is cheaper to maintain than fighting agent scrapers you never intended to support.
“Who pays — the end customer or the agent operator?” That is the open pricing question. Seat-based billing assumes a human identity; agent traffic needs either per-call metering, outcome-based pricing, or prepaid agent wallets. Cloudflare Wallets is one infrastructure bet on the wallet side; the SaaS product still has to decide what an “interaction” is worth.
“Does Anthropic or OpenAI doing connectors prove the model?” Partially. Claude's Gmail and Drive connectors show big platforms exposing read/write surfaces for agents — but they are not charging third-party developers per interaction through those connectors. The monetization layer for independent SaaS is still largely untested.
MCP completeness checklist: is your product actually headless?
Use this as an audit before claiming agent readiness. Score each row honestly — “partial” means an agent cannot finish a real customer workflow without human intervention.
| Capability area | Token MCP (demo) | Headless-ready |
|---|---|---|
| Read core objects | List/search only | Full object graph with stable IDs |
| Create / update / delete | Read-only or create-only | Parity with UI for all CRUD the product supports |
| Workflow state | Single-shot tool calls | Multi-step flows (draft → review → publish) exposed as composable tools |
| Permissions | Single API key | Scoped credentials per agent, per tenant, per action |
| Error surfaces | Generic 500s | Actionable errors an agent can retry or escalate |
| Rate limits | Undocumented | Published quotas with headers an agent can read |
| Billing hook | Seat license only | Metered per call, per outcome, or per token with idempotency keys |
| Observability | None | Request IDs, audit logs tying agent identity to actions |
| Documentation | Three example tools | Complete tool catalog matching UI feature map |
If more than two rows are still in the “token MCP” column, you have marketing coverage, not a headless product.
Pricing model examples: what “charge per interaction” could look like
The thesis stays abstract until you attach numbers. Below are illustrative structures — not confirmed pricing from any vendor — showing how agent-native billing differs from seat-based SaaS.
| Product shape | Seat-based today | Agent-native alternative | Why it might work |
|---|---|---|---|
| CRM | $150/user/month | $0.02 per record enriched + $0.10 per outbound sequence step | Agents enrich thousands of records overnight; no human sits in a seat |
| Support desk | $79/agent/month | $0.25 per ticket triaged + $1.50 per resolved ticket | Volume scales with automation, not headcount |
| DevOps / CI | Per-seat + build minutes | $0.005 per API call + $0.50 per deploy orchestrated | Agent opens PRs, runs checks, merges — call volume dwarfs human clicks |
| Payments / fintech | Platform fee + seats | Pre-funded agent wallet with per-transaction cap | Agent spends autonomously within owner-set limits |
| Email / workspace | Per mailbox | $0.001 per message classified + $0.05 per draft sent | Gmail-class connectors imply read/write volume, not seat time |
Common implementation requirements across all of these: idempotency keys (agents retry), usage webhooks (customer dashboards), and hard spend caps (enterprise procurement will demand them before allowing autonomous agents).
What this looks like for builders reading explainx.ai
If you're building or maintaining a product that agents might reasonably want to call — internal tools, a SaaS product, an API-first service — the practical version of this idea is:
- Audit whether your MCP server (if you have one) has real feature parity with your product, or whether it's a handful of read-only tools that don't actually let an agent complete meaningful work end to end.
- Separate your pricing model's assumptions from your product's actual usage pattern. If agent-driven usage is growing, seat-based pricing built around human session length is measuring the wrong thing.
- Decide deliberately, not by default, whether disintermediation risk outweighs agent-traffic revenue for your specific product — this is a real strategic call, not a universally correct move for every SaaS company.
Builder takeaways
- Parity first, MCP second. Ship tools that mirror UI workflows end-to-end; a thin MCP wrapper is worse than no MCP — it trains agents to fail and users to distrust the integration.
- Meter what agents actually consume — calls, outcomes, or dollars moved — not human session time.
- Study connector launches as architecture references, not as proof of your pricing model: Claude Gmail/Drive connectors for OAuth-scoped read/write, Cloudflare Wallets for autonomous spend caps.
- Publish agent-specific rate limits and error codes before launch — agent hosts cannot retry intelligently against opaque failures.
Summary
The core claim — that most SaaS companies are leaving money on the table by shipping half-hearted agent interfaces instead of genuinely complete, priced-per-interaction ones — is a real, testable business idea, not a settled fact. The reason it's underexplored isn't that companies haven't thought of it; it's that a fully complete agent interface is also a fully complete disintermediation risk, and most companies have reasonably chosen to protect the human-facing product they already have rather than bet on an unproven agent-native pricing model. Whether that's the right call depends entirely on where a given product's actual moat lives.
Related on explainx.ai
- Claude Gmail and Drive workspace connectors
- Cloudflare Wallets: AI agent payments with spend caps
- What is MCP? Model Context Protocol guide
- LangSmith tuned evaluators: 82% cost reduction
- Cursor Origin vs Block Buzz Projects — Git hosting for agents
- Anthropic's "Mind Viruses" multi-agent research
- OpenAI pauses frontier RL over Astra cyber risk
- What are agent skills? Complete guide
Source: Thariq Shihipar (@trq212) on X, August 19, 2026.
This is an analysis of a strategic idea circulating publicly, not a report on any specific company's confirmed results implementing it. Treat the thesis as a framework to evaluate, not a proven outcome.