Use your own API before agents do

The fastest way to find out where AI agents will trip on your API is to consume it yourself first — as an agent would. No internal shortcuts. No privileged network. No service account with the rate limits turned off. Just your team, sat behind the same surface your customers get, building something real against it. Discovery beats speculation. Every roadmap review we've seen misses friction that shows up in the first hour of actual use.

The illusion of first-party API use

Most SaaS teams believe they already use their own API. They don't.

Internal tools call the API from inside the VPC. Support scripts hit an admin endpoint that bypasses tenant scoping. The engineer testing a new endpoint has a personal token that never expires and lives in an ignored rate-limit tier. The mobile team consumes a private v2 that the public docs don't mention. The billing job runs as a service principal with permissions no customer will ever be granted.

None of that is first-party API use in the sense that matters. It's privileged access to internal machinery. When an agent shows up — running as an authenticated user, over the public edge, hitting the same auth flow a customer hits — none of the shortcuts apply. The friction the internal team never felt is the friction the agent hits on turn one.

We think the test is simple. If you can't build something useful against your own API using nothing but what a paying customer gets, your API isn't ready for agents. It isn't ready for your own developer advocates either, but that's a separate conversation.

What agents actually feel that humans don't

A human developer forgives a lot. They read the error, guess what happened, retry, and move on. They open Postman, poke at the shape, close the tab. They tolerate a login flow with three redirects because they only do it once a day.

Agents don't forgive. They surface every rough edge as a failed tool call, a hallucinated retry, or a wrong branch in the trajectory. Some things you only feel when you're the caller and the caller can't improvise:

• Rate limits that hit at odd boundaries. The 60-per-minute limit is fine for a human clicking around. An agent that fans out three parallel tool calls to enrich a record hits it on the second turn. The 429 comes back with no Retry-After header, or with one in seconds (per spec) when your backoff logic wrongly assumed milliseconds.
• Auth flows with too many round-trips. Refresh token → introspect → fetch scopes → validate audience. Fine once. Painful when the agent is doing it on every third tool call because your token TTL is 15 minutes and your refresh endpoint is rate-limited on the same bucket as your reads.
• Error messages that assume human context. "Invalid request" with no field pointer. "Not found" when the resource exists but the caller lacks a scope you never documented. "Something went wrong, please try again" — the message equivalent of a shrug.
• Pagination that only works if you already know the shape. Cursor in a header on one endpoint, in the body on another, offset-based on a third. A human learns the pattern once. An agent has to be told, per tool, and gets it wrong when the docs drift.
• Idempotency that isn't. POST without an idempotency key contract. Retries create duplicates. The human noticed the duplicate in the UI and deleted it. The agent doesn't notice and doesn't delete.

None of these show up in a roadmap review. All of them show up in the first hour of building against your own edge.

What real internal use looks like

Real use of your own API means constraints, not access. Constraints your customers live with:
‍

The exercise doesn't need to be long. A week of one engineer building an internal workflow — expense categorisation, ticket triage, whatever — under those constraints will find more real API friction than a quarter of design reviews. We've watched teams find broken pagination, undocumented required headers, and an entire auth scope missing from their public docs inside three days.

And critically, do it as an agent would. Not "how would I, a senior engineer, work around this." Ask: what would a tool call see? What would the model do with this error? What happens when the same request is retried because the previous response was ambiguous? The answers will not flatter you. That's the point.

How Pontil fits

We built Pontil because the finding from that week — the specific list of what your API can't do, and where it makes the caller work too hard — is exactly what should drive your tools layer. Not gut feel. Not the spec. The actual observed friction.

Pontil is a Tools-as-a-Service platform. We scan the codebase you already have, generate tools that agents can call, and run them at the boundary where auth, rate limits, and error handling actually get exercised. The tools layer sits on top of the API you have — it's where the wrappers, retries, and idempotency guarantees get written once and maintained as your product changes.

Use your own API first. Then let the findings shape what the tools layer needs to hold. That's the sequence that works.

What to do on Monday

Pick an internal workflow your product could reasonably automate. Give one engineer a normal customer account — normal tier, normal scopes, normal token TTL, public docs only. No Slack channel with the API team. No source code. A week.

At the end of the week, three artefacts:

1. The list of every friction point encountered, tagged by whether an agent would recover, retry incorrectly, or fail loudly.
2. The list of endpoints the workflow needed that don't exist, or exist only internally.
3. The list of error messages that a model could not act on without human interpretation.

That's your tools-layer backlog. It's also your API roadmap, though the API roadmap will take years and the tools layer won't. Either way, you now know what to build — not because someone speculated, but because you consumed your own API the way agents will. Discovery beats speculation. Always has.