Blog

Your Newest Customer Is an Agent. What it Means to SaaS Vendors.

Jerome Louvel ·September 2, 2026

Table of contents

An agent tried your SaaS product this morning.

It read your OpenAPI document, picked the endpoint whose name looked closest to what the user asked for, guessed a parameter, got a 400, retried, got a 200 it half-understood, and told the user your product cannot do that.

You will never hear about this. No ticket. No NPS response. No churn reason code. The user does not blame the agent, because the agent sounded confident. They blame you, quietly, and go ask about someone else.

You have run this play before — minus the hard part

For about fifteen years, adding a REST API to a SaaS product was not an engineering decision. It was business development: partners embedded you, customers extended you, switching costs rose, and a product became a platform without a salesperson in the loop.

But shipping the API was never the part that worked. The companies that won distribution treated the developer as a customer whose experience they were accountable for — documentation as product, SDKs in the languages people actually used, a key and a sandbox inside five minutes, error messages that named the fix. Developer Experience became a discipline — Jeremiah Lee coined the term in 2011 — precisely because distribution depended on it.

Being callable is becoming a distribution requirement in exactly the way being integrable was a decade ago. Same commercial logic, new consumer.

With one difference that changes the work. DX had a feedback loop. A confusing error became a Stack Overflow question, a missing SDK method became a GitHub issue, a bad onboarding flow became a thread someone screenshotted. That correction was free, fast, specific and often public — so a mediocre first version got iterated into a good one whether you planned for it or not.

Agents give you none of it. Your newest consumer is the first one that cannot tell you it had a bad time, and cannot be surveyed about it either.

Line	Then	Now
Acquisition	A developer hit a snag and asked in your Slack	An agent mis-picks and reports back that you can’t do it
Support	Bad integrations produced tickets you learned from	Bad integrations produce silent retries
Retention	Churn had a reason code	Churn has a transcript nobody reads

So the investment moves earlier — into a surface that was designed, rather than one that gets debugged into shape by the people using it.

It is not your agent

The reflex is to ship an assistant. Most vendors have. But as Anil Kumar of GEICO put it:

“I really don’t want to use your agent, I want to use my agent to use your thing.”

Your product is becoming a capability, a set of tools inside somebody else’s agent. The only question is whether those tools were designed, or scraped off your REST surface by an importer.

Three moves

Stop shipping a mirror. One tool per endpoint is not an agent surface, it is your database schema wearing a hat. An agent handed 150 near-identical CRUD tools pays a token tax on every turn before it reasons about anything, then picks the wrong one. Ship the handful that match the jobs customers hire you for — your quickstarts are already that list.

Declare behaviour instead of letting it be discovered. Safe? Idempotent? Destructive? A human finds out by trying it once and telling you. An agent finds out in production, on a customer’s data, and the postmortem is yours.

Make the surface narrowable, not forkable. Enterprises will want a subset, with their own masking and their own credentials. If that means forking your SDK they will build their own thing badly. If it is a declarative artifact, they narrow it and stay on your upstream.

None of that needs a new protocol. It needs the surface written down where someone can read it:

ikanos: "1.0.0-beta5"

capability:
  consumes:
    - import: billing
      from: ./openapi/billing.yml   # your existing spec, unchanged

  aggregates:
    - namespace: subscriptions
      flows:
        change-plan:
          description: "Move a subscription to a new plan, with proration"
          semantics: { safe: false, idempotent: true }   # declared
          steps: [ "...three upstream calls, sequenced server-side..." ]

  exposes:
    - type: mcp                      # your customer's agent
      tools:
        change-plan:
          ref: subscriptions.change-plan
    - type: rest                     # your portal, same artifact

One file, reviewed like any pull request, projected to MCP for agents and REST for humans. Ikanos is Apache 2.0, so this costs a repository and an afternoon, not a procurement cycle.

The test takes an afternoon

Kumar again, and it is the only benchmark worth running:

If a harness that knows nothing about your business can drive it correctly, the surface is right. If it needs a bespoke agent to hold its hand, you shipped an API with extra steps.

Point a stock MCP client at your product with no custom prompting and ask it to do the three things your quickstarts promise. Count the turns. Unlike NPS, you get the number before lunch.

Work it out with us

We are opening ecosystem partnerships for companies with a public or partner API who would rather agents consume it well than badly.

You know your business capabilities better than we ever will, so you design them and we help: which jobs deserve to be capabilities, what the MCP surface should look like, wiring it over the APIs you already run — no rewrite, no migration — and then operating it. The artifact is yours, in your repository, reviewed by your engineers. Free while the public corpus is still thin.

Bring one integration your customers keep getting wrong, and we will look at what an agent actually sees when it meets it.

The takeaway

Same play, new consumer. A REST API was business development; Developer Experience is what turned it into distribution. Being callable is the 2026 version of being integrable.
But the feedback loop is gone. Developers filed issues and wrote threads. Agents retry, guess, and report your product as the limitation — so the design has to be right earlier.
It is your customer’s agent, not yours. Shipping an assistant does not address the surface that agent is reading.
Three moves: task-shaped tools instead of an endpoint mirror, behaviour declared rather than discovered, a surface customers can narrow without forking.
One test: a stock harness, no prompting, your three quickstart jobs. Count the turns.

Subscribe to the Naftiko Manifest

Want to learn more and stay up to date on the latest from Naftiko? Get new posts, releases, and signals from the capability fleet in your inbox.