Be Machine-Readable: Is Your SaaS Ready for AI Agents?
I've been researching the agentic internet, which I see as the next version of the internet. In "Agent Population Growth: A Funnel for Products Agents Choose", I shared how agents are changing internet use, along with my own experience and perspective. This post goes a step further and details what a SaaS product needs to do when agents interact with it.
When agents consume your SaaS product's website, they don't look at the logo or the visuals; they read the structure and metadata behind each element. So the first requirement is a machine-readable version of your website and product, with clear guidance on how to use them.
An agent doesn't deliberate for hours the way a person does; it executes. If it finds an endpoint in your REST API docs that fits the task and its constraints, it sends a request and moves on based on the response. If the response doesn't explain itself, it churns. Think of it as a machine that knows what it is looking for and decides very fast: it tries, gathers what it learns and decides. That gives it a short decision cycle. Agents are closer to homo economicus than people are: no brand feelings, hard constraints, fast decisions. But they are not perfect optimizers. With limited context and what looks like a habit of keeping the first service that works, they satisfice rather than maximize.
Agents go through a service in the five stages of the funnel from my previous post. Here is what a provider can do at each stage:
Connector directory listings, an install page per agent client and public example code.
Markdown docs, llms.txt, a pricing.md with real numbers and one recommended path.
As few human steps as possible, ideally one approval: a hosted MCP server with OAuth, a command-line login or a provisioning platform.
A sandbox that needs no setup, errors that name the fix and IDs to verify the outcome.
Quota in response headers, upgrades without the dashboard and MCP coverage of daily tasks.
Below are the five stages, with examples from two services that do them well: Resend for email and Tally for forms.
The agent first pulls the category and constraints out of the request: "Add transactional email to this Next.js app, free if possible" means an email API, Next.js and a free plan. It then recalls the services it associates with that category, because recall is instant and a search costs a tool call. It searches the web when its memory is thin, the request implies something recent, or the user asks for "the best" option. It likely keeps only two or three candidates, because reading each one's docs uses up the context window.
Memory is only one route. Installed connectors can be offered first, and an AI app builder's default, such as the email provider in Lovable or v0, can decide without consulting memory at all. A connector directory listing takes effect within days; training data only shows up with the next model generation. Hosting matters too: if the AI bot settings on Cloudflare or Vercel block search bots, the service never appears in AI search answers.
Resend keeps a separate install page for each agent client, such as resend.com/cursor, so a search for "Resend + Cursor" lands on an exact match. It is also a connector in Claude and a plugin in Codex, so the assistant can suggest it from its own catalog.
What to do:
- List in the Claude connector directory, ChatGPT apps, Cursor plugins and the official MCP Registry.
- Publish an install page for each major agent client; agents search for "service + client".
- Publish official example repos for your most common stacks; models learn usage mostly from code.
- Decide deliberately what your hosting edge lets search bots and training bots do.
The agent looks for an entry point, usually the docs index or llms.txt. Resend's AI onboarding page is a good one: it lists every way in, from the MCP server and CLI to markdown docs and agent skills, and says up front what a human must do, such as creating the account and adding the DNS records to verify a domain. Then the agent checks the user's constraints: does the free plan send enough, and is the needed feature on a plan the user can afford? Constraints like "free" or "under $25 a month" are hard rules. It compares the candidates on price and setup effort, finds the recommended integration (SDK, REST API or MCP) and writes the code.
All of this happens inside the context window. HTML pages full of menus and scripts can fill it with content the agent does not need; clean markdown gives it the same information with less noise. Many fetchers do not run JavaScript, so script-built pages can arrive empty. Agents read pages as their own user agents, such as ChatGPT-User or Claude-User, and a firewall or bot-protection rule that blocks them can cut off your docs. Tally's developer docs get this right: the same address returns markdown to assistants such as ChatGPT-User and Claude-User, and HTML to browsers.
A service whose pricing says "contact us" or "generous limits" is usually dropped here, because the agent cannot work out a budget from those words. Resend's pricing page links "Are you an AI agent? See pricing" to pricing.md, which lists every plan and marks each feature yes or no. A clear "no" stops the agent from promising a feature the plan lacks. Tally's MCP page answers "MCP or API?" just as plainly: MCP for quick work in conversation, the API for embedding and automation at scale.
What to do:
- Serve every docs page as markdown, and publish
llms.txtandllms-full.txt. - Publish a
pricing.mdthat states every plan and limit in numbers, and link it from your pricing page. - Write an "MCP or API?" page and keep one recommended path per task.
- Write each MCP tool description to answer "when should I use this?"
- Fetch your docs and pricing page as ChatGPT-User and Claude-User to test that your hosting edge lets them through.
This is the narrowest point of the path: it holds the one step the agent cannot finish alone, and every extra step asked of the user gives the agent a reason to switch. The agent picks a way in and starts the flow itself, adding an MCP server address or running a login or provisioning command. The user approves in the browser, signing up first if needed, because consent and identity have to come from them. The service issues credentials limited to the approved scopes, and the agent confirms access with a harmless call such as listing domains.
The classic path, "sign up, verify your email, open the dashboard, create an API key, copy and paste it", means four or five human steps, and this is likely where sessions stall most. A hosted MCP server with OAuth, or a command-line login with device flow, cuts this to one approval. Provisioning platforms such as Stripe Projects or the Vercel Marketplace can remove the signup and API-key steps entirely, if the user meets their prerequisites.
At Resend, stripe projects add resend/email creates a Resend account linked to the user's Stripe account and writes the API key into .env; according to the guide, the agent can run it. Tally's MCP server is free on every plan, so the agent never has to ask the user for money before the first try.
What to do:
- Host your MCP server with OAuth, and let clients without a browser pass an API key as a Bearer token.
- Offer scopes split into read, send and admin; users are more likely to approve narrow permissions.
- Keep the MCP server and API on the free plan.
- Measure the human steps from zero to working credentials, and aim for one.
This is where the habit of keeping the first service that works matters: each new service costs the agent another round of reading and setup.
The agent installs the SDK, writes the smallest possible call and tries it with sandbox values such as a test sender address. On an error, it fixes the request and retries. Error quality decides everything here: an error that says what to do often lets the agent correct itself, while a bare "Bad request" forces it to guess, and if the guess fails, the agent moves to another service.
A success code does not mean the task is done, either: an email can be accepted and never delivered. To verify the outcome, the agent needs an ID, a status it can look up and a way to read the result back. Idempotency keys are a must too, because agents retry failed calls on their own; without them, every retry sends the user one more email.
Resend's sandbox needs no setup: onboarding@resend.dev can send to the account owner's own address before any domain is verified. Every code on its errors page comes with a suggested fix; the 403 for an unverified sender, for example, says to verify a domain and change the from address, and links a guide.
What to do:
- Offer a sandbox or test mode that needs no setup.
- Give every error a code, a message, a suggested fix and a docs link.
- Return IDs and statuses, so agents can verify the outcome.
- Accept idempotency keys on every endpoint that writes data.
- On your API and MCP addresses, have the edge return JSON errors instead of an HTML challenge page.
Revenue comes from two moments here: when the user hits a limit, and when the agent moves into new uses of the product.
Once the integration is in production, the agent reuses the same connection for new questions, such as "how many emails bounced this week?". Near a limit, it sees usage in response headers or a usage tool and warns the user; at the limit, it tells the user what to buy and why, because payment is a human decision. Over time, it also moves into nearby features the connection already covers; for an email service, incoming email or newsletters.
My hypothesis is that the quota moment is a strong sales moment for accounts an agent created or recommended, because the agent can explain the need and the price in one message. For that, the upgrade has to work without the dashboard. When a limit fails silently, or upgrades only work in the dashboard, usage drops.
At Resend, the agent can upgrade from the terminal with stripe projects upgrade resend/free resend/pro --json; with no payment method on file, it returns a Checkout link. The GET /usage endpoint Resend announced on October 1, 2026 and the get-usage tool in its MCP server let the agent check its remaining quota before hitting a limit.
What to do:
- Show quota usage in response headers and in a usage endpoint or MCP tool.
- Add the required plan, its price and an upgrade address to quota errors.
- Offer pay-as-you-go so work does not stop at the quota.
- Cover your most common dashboard tasks in MCP, so the user need not go back to the dashboard.
The five stages are linked: an agent that cannot get past one never reaches the next, so the weakest stage limits the whole path. Being machine-readable keeps you on the shortlist and gets the agent through the docs, but the agent still needs access with one approval, errors that name the fix and a way to upgrade without the dashboard. Find the stage where your service loses agents, and start there.
I put together an e-book for you: How to Make Your SaaS Agent-Ready. It shows the best practices for each of the five stages, with Resend and Tally examples, measurement metrics and a scorecard, so you can design a detailed roadmap for your own product.