Every B2B CEO we talk to right now has some version of the same question. “How do we become more agentic? What’s the first move? Do we need a Chief AI Officer? A forward-deployed engineering team? An MCP strategy offsite?”
The answer is simpler than any of that, and most vendors are skipping it.
Make sure your API is actually, truly agent-friendly. At the cutting edge here. It’s not that hard. And it probably … isn’t.
That sounds obvious. It isn’t. “Agent-friendly” in 2026 means something very specific, and the bar moved hard in the last 12 months. Most B2B vendors think because their REST API returns JSON, they’re fine. They aren’t. The companies pulling away right now all ship the same set of things. The companies getting quietly drained by agent-era churn ship almost none of them.
Here’s what “truly agent-friendly” actually means today, how to grade yourself against it, and what shipping it looks like in April.
The Shift: Your API Is No Longer a Developer Interface. It’s Incredibly Important to Embrace This
The core thing to internalize, before any checklist makes sense:
Your API’s primary consumer is no longer a human developer writing deterministic code. It’s an AI agent, reasoning probabilistically, reading your docs at runtime, retrying on failure, and deciding which endpoint to call based on inference. Automated bot traffic surpassed human traffic for the first time in 2024. RAG-based agent traffic grew 49% in early 2025. It’s only accelerated since.
That changes everything downstream. Human-first APIs optimize for flexibility and expressiveness. Agents punish both. Overloaded endpoints that handle five intents force agents to guess. Vague errors force agents to retry. Hidden side effects force agents to grope around. Every guess adds cost, latency, and failure probability. (techbytes.app)
Agent-first design means removing ambiguity from the contract. Make capabilities explicit. Make state resumable. Make mutations idempotent. Make errors executable.
The Real Checklist: What’s on a Modern Agent-First API
What follows is what the leading companies now ship. Use it as the bar.
1. An MCP Server That Wraps Your REST API
This is the single biggest shift. MCP doesn’t replace your REST API. It’s a protocol layer on top of it, purpose-built for AI agents. Think of it as USB-C for agents: one port, many compatible tools. (workos.com)
Every major API company now hosts one. Stripe hosts a remote MCP server at mcp.stripe.com with OAuth. GitHub, Supabase, Shopify, and Twilio did the same. The agent connects, discovers what tools exist at runtime through tools/list, and calls them through tools/call. No bespoke integration code per model. No feeding 500 pages of API docs into a context window. (stripe.com)
If you don’t have an MCP server in 2026, you are effectively invisible to the agent layer.
2. An Agent Toolkit / SDK for the Major Agent Frameworks
MCP alone isn’t enough. Serious API companies now ship agent SDKs for the frameworks agents are actually built in. Stripe’s Agent Toolkit works with OpenAI’s Agents SDK, LangChain, Vercel’s AI SDK, and CrewAI. Python and TypeScript. Pre-built functions like create_payment_link or create_subscription that LLMs can invoke directly through function calling. (stripe.com)
If a founder building an agent can install your SDK, paste one import, and have their agent take meaningful action in 10 lines of code, you win. If they have to read docs for an hour, you lose.
3. Machine-Readable Discovery at /.well-known/ and /llms.txt
Agents need to discover your capabilities without a human in the loop. The pattern that’s emerging:
/llms.txt— a short Markdown map of your site and docs/llms-full.txt— the full documentation as a single Markdown file an agent can ingest in one fetch/.well-known/skills/index.json— a catalog of “skills” (Markdown instruction packages) for how to correctly use your API- A current, validated OpenAPI spec that matches reality
That last one is the hidden killer. 75% of production APIs have endpoints that don’t match their OpenAPI spec. (musketeerstech.com) When agents read a spec and the API doesn’t behave the way the spec says, you burn their tokens and their trust.
4. Executable Errors, Not Cryptic Ones
This one is deceptively important. The difference between human-friendly and agent-friendly error responses, from a real example:
Traditional error:
{"error": {"message": "Model not found"}}
Agent-first error:
{
"error": {
"code": "model_not_found",
"message": "Model 'gpt5' not found",
"did_you_mean": "gpt-4o",
"suggestions": [{"id": "gpt-4o"}, {"id": "gpt-4o-mini"}],
"hint": "Use GET /v1/models to list all available models."
}
}
One vendor reported their users’ wasted tokens dropped 60%+ after shipping this pattern. Agent-first error responses include structured, machine-readable hints that let the agent self-correct without human intervention. did_you_mean, suggestions, hint. Additive fields. Human clients ignore them. Agents use them to recover on the next call instead of failing the whole workflow. (lemondata.cc)
5. Auth That Agents Can Actually Complete
Authentication is the biggest single friction point for agents consuming APIs today. Humans can click through OAuth consent screens, solve CAPTCHAs, and complete MFA prompts. Agents can’t do any of that. (apideck.com)
What works for agents:
- API keys and bearer tokens. Simple, no interactive flow, no browser redirects.
- OAuth 2.0/2.1 client credentials grant. Machine-to-machine. Client ID and secret exchanged for a token. No consent screens.
- Restricted API keys with granular per-tool permissions. Stripe’s
rk_*keys let you scope exactly which tools an agent can call. If the agent only needs to read data, it can’t write.
What does not work:
- Auth that requires a browser redirect
- MFA with a human in the loop
- Silent auth failures (whitespace breaking credentials with no useful error, for example)
- No refresh tokens
6. Idempotent, Resumable, Safe-to-Retry Mutations
Agents retry. Constantly. It’s how they recover from context loss and partial failure. If your POST /orders creates duplicate orders when called twice with the same payload, an agent will eventually cost your customer real money.
The fix:
- Every mutation endpoint accepts an idempotency key
- Long-running operations expose resumable state
- Side effects are precisely documented in the response schema
- Read operations are clearly marked as read-only so agents know it’s safe to retry without checking
7. Webhooks for Every State Change That Matters
This is table stakes and yet half the B2B tools in the average stack still poll. Agents can compensate for missing features. They can’t compensate for being blind to state changes. If the only way to know something happened is to poll every 30 seconds, every agent workflow on top of your API is slower, more expensive, and less reliable than it should be.
8. Generous, Observable Rate Limits
Agents make more calls than humans. A single user task might trigger 10-50 API calls as the agent plans, retries, and verifies. If your rate limits were sized for 2020 traffic patterns, you’re throttling every agent workflow before it starts.
The modern pattern:
- Generous default limits (think order of magnitude, not 20%)
- Response headers on every call showing remaining quota and reset time
- Separate Bulk / Export API for big reads that doesn’t count against interactive limits
- Clear, actionable 429 responses that tell the agent when to retry
9. Behavior-First Docs, Not Structure-First Docs
Traditional API docs tell you what an endpoint does. Agent-first docs tell you when to use it, how to interpret its response, and what to do when something goes wrong. (musketeerstech.com)
Concrete components:
- Every doc page has a “Copy for LLM” button and a Markdown-rendered version (Stripe’s pattern, now widespread)
- Short, consistent examples in Python, TypeScript, and at least one curl
- Explicit “when to use this vs. that” decision guidance
- A changelog that’s actually maintained
10. An Agent Skills Catalog
This is the newest piece and the one most teams haven’t heard of yet. “Skills” are Markdown instruction packages that teach an agent exactly how to handle a specific task with your API. Stripe maintains a public catalog at docs.stripe.com/.well-known/skills/index.json. (stripe.com)
When an agent encounters work relevant to a skill, it loads that skill’s context and operates with your opinionated best practices instead of general-purpose guesswork. Simon Willison has called Skills “maybe a bigger deal than MCP.” (apideck.com)
The practical effect: your API stops being a menu of endpoints and starts being a set of opinionated workflows. That’s the level of legibility agents need.
The Single Test That Tells You Where You Stand: Ask Your Agent
Put all of this together and there’s a simple, honest test for your API in 2026:
Open Claude Code or Cursor. Point it at your docs URL. Say: “Build a working integration that does X end-to-end, using only the public docs.”
Watch what happens.
- If the agent completes the task in one or two tries, your API is agent-ready.
- If the agent retries five times, hits undocumented edge cases, can’t figure out auth, or gives up, you have work to do.
That’s the bar. It’s not “can a determined senior engineer eventually make this work.” It’s “can a frontier model, given only your docs, make this work on the first try.”
Because that’s increasingly how buying decisions get made. The first “developer” evaluating your product isn’t a human. It’s an agent, on behalf of a human, deciding whether your API is worth integrating against or whether the competitor one tab over is easier.
Three Live Vendors in Our Stack. One Pass, One Barely, One Fail.
Theory is fine. Let me walk through what the checklist looks like applied to three real products our three-humans-and-20-agents team uses every day.
Salesforce. Pass.
We run Salesforce headless. Nobody at SaaStr logs in. The agents do. 10K (our AI VP of Marketing) pulls real-time pipeline, campaign data, sponsor status, revenue, and lead flow continuously. Qbee (our AI VP of Customer Success) manages 100+ sponsors through the same API. Qualified, Agentforce, Momentum, Artisan, Monaco, every agent we run, reads and writes Salesforce records without a browser.
Why it works:
- The REST API is mature, well-documented, and consistent. Objects queryable the same way they’ve been for 15 years.
- Webhooks actually work for every meaningful state change.
- Rate limits are generous enough that continuous polling by half a dozen agents doesn’t trigger throttling.
- Salesforce Headless 360 launched at TDX this month. 100+ new agent tools, $50M partner fund, MCP integration. The platform’s biggest architectural shift in 27 years.
- Agentforce gives you native agent runtime inside the platform.
Marc built the API-first company before API-first was a thing. Salesforce is aging into its strength in the agent era, not out of it. Against our 10-point checklist, Salesforce hits 8 or 9. Pass.
Bizzabo. Barely.
Bizzabo runs the logistics for SaaStr Annual, Europa, and our AI events. Registration. Attendee data. Badge scanning. Schedules. 10K pulls registration and attendee data from Bizzabo via API to run campaigns.
Barely.
The API works. It hasn’t been meaningfully updated in years. Rate limits designed for a world where maybe three developers would ever touch the platform. Incomplete docs. Stale endpoints. No MCP server. No llms.txt. No agent toolkit. Webhook coverage is spotty. Error responses are generic.
But it returns the data. The calls don’t silently fail. Auth works. Enough of the API is legible that we can feed it to Claude and get a working integration out the other side, if we’re patient.
That’s what “barely passes” looks like in 2026. The API is a relic, but it’s a functional relic. Against the checklist, Bizzabo hits maybe 3 of 10. C-minus. The only reason we haven’t churned is that switching event platforms mid-year is painful, and honestly, most of the alternatives aren’t meaningfully better. But every quarter that goes by without modernization, the cost of staying gets higher.
Marketo. Fail.
Now we get to the one that’s been breaking us for months.
Adobe charges us $60K a year for Marketo. In 2026. Here’s what that API actually does against the checklist:
- MCP server: no.
- Agent toolkit / SDK: no.
- llms.txt: no.
- Webhooks: effectively no. Everything is poll-based.
- Rate limits: hostile. Single-digit bulk exports per day. Hit that ceiling and you’re done until tomorrow.
- Log retention: 90 days. Anything older is gone.
- Auth: broken. No refresh tokens. Whitespace in credentials silently breaks authentication with no useful error.
- Aggregates: unusable. The Counts API can’t answer the basic question “how many people are on this list right now.”
- History: 6 months maximum. Full sync of our own data takes multiple days because of rate caps.
- Docs: stale, human-first, no LLM-optimized view.
Against the checklist, Marketo hits 0 of 10. Fail.
The Marketo Story Is the Story of So Many Legacy B2B Vendors Right Now. It Might Even Be You, At Least Partially.
Here’s a moment it got especiallu real for us.
Marketo’s unsubscribe link had been broken on our sends for over two weeks. That’s a CAN-SPAM violation on the single most core piece of functionality email marketing platforms exist to provide.
What we wanted was for our agent to diagnose it, file the ticket, push Marketo support, and implement the fix. Standard 2026 agent workflow.
What actually happened: we got on the phone with their engineering team, who blamed Salesforce, then blamed us, then never committed to a fix. We gave up and built a replacement unsubscribe flow on Replit in an afternoon.
The lesson isn’t “Marketo is bad.” Plenty of products are bad. The lesson is that the agent couldn’t help us because Marketo’s API isn’t agent-operable. No usable API path for the diagnosis. No webhook to trigger on. No way for 10K or Qbee to even see the problem, let alone route it. No MCP server the agent could call. No skills catalog to tell the agent how to handle the escalation.
Adobe is still pricing and selling Marketo like it’s 2019. The product is built for a world where humans with large ops teams slowly click through dashboards and escalate to humans at the vendor. That world is ending. It’s already ended at SaaStr.
The reason we’ve migrated almost all of Marketo’s functionality to Salesforce isn’t that Salesforce has better features. It’s that Salesforce has a far better, and agent-friendly, API. Once you rebuild the workflows on the platform your agents can actually operate, you look up one day and realize you’re paying $60K a year for a product you no longer need.
That’s the new B2B churn motion. It’s not a feature comparison. It’s an agent-operability comparison. And legacy vendors are losing it quietly, one workflow migration at a time, before they even show up on the churn report.
Do All 10. Make Your API Truly, Fully Agent-First. This Month.
No, you don’t get to sprint-plan this across two quarters. It’s Q2 2026.
MCP has been a public standard for 17 months. Anthropic donated it to the Linux Foundation in December. OpenAI deprecated its Assistants API. Salesforce just shipped Headless 360. Stripe has a skills catalog, an MCP server, an agent toolkit for four different frameworks, and llms.txt live at the root. 5,000+ MCP servers are in production. 844,000+ sites have shipped llms.txt.
Every one of your customers who runs agents in production is already grading your API against this checklist, whether they tell you or not. The ones who are grading you poorly aren’t going to file a support ticket. They’re going to rebuild your workflows on a platform they can actually agent-operate, and churn you six months later, the same way we’re churning Marketo.
