API strategy
Platform integration
Programmatically means something different in the agent era. Why programmatic access, API access, and control aren't synonyms, and what agents actually need.
Every SaaS product claims to offer programmatic access. Most of them mean something narrower than they let on — an API that exposes a fraction of what the UI can do, documented for human developers who read the docs, wire up a client, and handle the rough edges themselves. That worked when the caller was a person. It stops working when the caller is an agent.
Our view: programmatic access used to be a checkbox. Now it's a spectrum, and where your product sits on it decides whether agents can actually use you. The old definition — "we have an API" — collapses the moment a language model tries to reason about your surface, pick the right call, authenticate as the right user, and recover from the errors your docs never mentioned.
This piece walks through what programmatic access means in 2026, why the API-equals-access assumption breaks, how programmatic control differs from programmatic API access, and what agent-grade access actually requires. It closes on how to evaluate your own surface before agents do it for you.
For twenty years, doing something programmatically meant one thing: a human developer wrote code that called an API. The developer read documentation, understood the auth model, mapped the endpoints to their use case, and handled failures. If the docs were incomplete, they read the source. If the API didn't cover something, they filed a ticket or worked around it. If the response shape shifted, they patched the client.
The surface was static. The caller was patient. The failure modes were absorbed by a person who could reason about intent. That let SaaS vendors ship APIs that covered maybe 2% of their product's real capability and still call it programmatic access, because the humans on the other end filled in the gaps.
That model made economic sense. Building an API for every possible workflow was unfundable, and it wasn't needed. Partners integrated the endpoints that mattered to them. Internal teams reached deeper by touching the database directly. The gap between what the product could do and what the API exposed was a known cost, not a blocker.
That gap is now the blocker. The caller stopped being patient.
These three phrases get used interchangeably. They shouldn't be. The distinctions decide whether an agent can actually do work on your platform.
The first two are about mechanism. The third is about coverage. A product can offer programmatic API access and still not offer programmatic control — because the API covers list-and-fetch operations while the interesting workflows sit behind buttons, modals, and multi-step wizards that were never exposed.
This matters because agents don't care about the mechanism. They care about whether they can reach the outcome. If the product can generate a report through the UI but not through the API, an agent asked to "generate the Q3 report" fails — not because the API is broken but because the capability was never programmatic to begin with. This is the 2% problem most established SaaS platforms are running into right now.
The assumption held because humans absorbed complexity. Take that absorber out and four things break at once.
Coverage gaps become blockers, not workarounds. A human developer who hits a missing endpoint files a ticket or scripts around it. An agent hits a missing endpoint and either hallucinates the call, invents a plausible-looking payload, or gives up. There's no workaround because there's no reasoning about why the gap exists. The agent doesn't know that the reason POST /reports doesn't exist is because the report generator runs in a background job triggered by a UI-only endpoint. It just knows the tool it needs isn't there.
Contracts have to be self-describing at runtime. Human developers read the docs once. Agents read the tool definition every call. If the API's contract lives in a Notion page, a Postman collection, and three README files with inconsistent examples, the agent has nothing to reason from. This is where OpenAPI spec drift stops being a governance annoyance and starts being a production failure — the spec has to match the runtime, and it has to describe intent, not just shape.
Errors have to teach. Humans read a 500 and check the logs. Agents read a 500 and retry the same call. Programmatic access designed for humans returns errors that describe what went wrong; programmatic access designed for agents returns structured, recoverable errors that tell the caller what to do next. Most APIs still do the former.
Auth has to be delegated per user. Human developers set up an API key once and forget it. Agents act on behalf of specific users, and the runtime has to prove which user each call belongs to. Shared service accounts fail security review the moment the agent is customer-facing. The identity boundary has to hold at the tool call, not at the process.
None of these are new problems. They were tolerable when a human was in the loop. They're structural now.
Strip out the marketing framings and there's a concrete list. Agent-grade programmatic access — real programmatic control, not just an API — requires six things.
POST /orders creates two orders when the network blips, agents will make that happen every day. Idempotency keys are table stakes.Retry-After on rejections so agents can back off intelligently.Most established SaaS products hit two or three of these. Building the other three is where projects stall, because it's not a rewrite of the API — it's a rewrite of the API's contract with its callers.
Most of what we've described above is what teams discover when they try to point their own agents at their own products. The API is there, the docs are there, and the agent still can't do the work — because programmatic control was never really the goal of the API layer. It was designed for partners with patience and a support ticket queue.
Pontil is a Tools-as-a-Service platform. We scan the codebase, generate tools that reach the capabilities the API doesn't expose, and run them through a managed runtime that handles delegated auth, structured errors, idempotency, and rate limits per call. The tools stay in sync as the product changes, so the contract doesn't lie. We're not replacing the API — we're closing the gap between what the API exposes and what agents need to reach.
That's the piece most agent projects underestimate at the start and rebuild by month six. If you want to see how it works against a real surface, book a demo.
Programmatic access used to mean "there's an API." It meant that because the caller could fill in whatever the API didn't cover. The caller can't anymore, which means the burden of coverage, contract quality, and error design shifts back to the platform.
The teams treating this as an API modernisation problem are underestimating the scope. It's not that the API needs more endpoints. It's that the entire idea of "programmatic" has to include the reasoning the caller used to do — which means self-describing contracts, structured errors, delegated identity, and coverage of workflows that were never resources in the first place. That's a different discipline, and it's the one agent-ready SaaS is going to be measured on.
The question worth asking now: what would it take to prove your product is programmatically controllable, not just programmatically accessible? Point an agent at it and see what it can't reach. The gap is the answer.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
