Most agent projects discover platform readiness problems in production, not before. This checklist is for discovering them before.
Work through each section against your current platform. For each item, the honest answer is one of three things: ready, partial, or not ready. "Partial" is not a safe answer — treat it the same as not ready for the purposes of planning.
This checklist doesn't tell you how to fix what you find. It tells you what you're working with.
1. API coverage
The first and most important question: can an agent reach the capabilities it needs?
- Task inventory complete. You have a written list of the business tasks your agent project needs to perform, broken into atomic actions.
- Coverage mapped. For each atomic action, you know whether the current API supports it, partially supports it, or doesn't support it at all.
- Controller logic assessed. You've checked whether any required capabilities live in controller or UI layers with no API equivalent.
- Undocumented endpoints identified. Internal or undocumented endpoints that could cover gaps have been assessed for agent use — including the risk of calling them.
- Coverage gap quantified. You have an estimate of how many atomic actions are not covered or only partially covered by current API surface.
2. Authentication and authorisation
Agent auth behaves differently from human auth. Most auth systems weren't designed for it.
- Per-user token support. Agents can authenticate as individual users — not just as a shared service account.
- Token refresh handled. Long-running agent tasks don't break when access tokens expire mid-sequence.
- OAuth flows callable programmatically. The auth flow can be initiated and completed without a browser session.
- Refresh token lifecycle managed. Refresh tokens are stored, rotated, and revoked safely. You know who owns this in production.
- Scopes sufficient for agent tasks. The permission scopes available to agents cover the actions they need to take — not just read access.
- Audit trail preserved. Tool calls made through agents are logged against the authenticated user identity, not against a service account.
3. Rate limiting
Agent-scale traffic is different from human-scale traffic. APIs designed for one often break under the other.
- Rate limits documented. You know the rate limits on every endpoint the agent will call.
- Agent-scale load estimated. You have an estimate of how many API calls the agent will make per hour in production, across how many concurrent users.
- Limits compared to load. You've compared the rate limits to the estimated load and identified where throttling is likely.
- Retry and backoff strategy defined. There's a plan for what happens when rate limits are hit — not just an error, but a queuing or backoff strategy.
- Rate limit ownership clear. You know who handles rate limit incidents in production: the agent team, the platform team, or someone else.
4. Observability
Agents fail in ways that are harder to spot than human user failures. You need visibility into what ran, on whose behalf, and with what result.
- Tool invocation logging in place. Every agent tool call is logged with the inputs, outputs, and identity of the calling user.
- Failure modes classified. You've defined the difference between an expected failure (rate limit, validation error) and an unexpected one (silent wrong result, partial action).
- Alerting configured. There are alerts on failure rates and error types that would indicate the agent is operating incorrectly.
- Audit log accessible. Someone — a compliance team, a support team — can query what an agent did on behalf of a specific user during a specific time window.
- Latency tracked. You can see whether tool calls are completing within acceptable time bounds or degrading.
5. API documentation and discovery
Agents are built by engineers who need to understand the API surface. Incomplete documentation creates gaps in tooling.
- Endpoints documented. Every endpoint the agent project requires has complete, accurate documentation: parameters, response shapes, error codes.
- Internal APIs inventoried. You know what internal APIs exist, even if they're not publicly documented.
- Deprecation signals clear. There's a process for communicating API deprecations to the agent team before they break things in production.
- Versioning strategy defined. You know how breaking changes to the API will be handled and communicated.
6. Change management
APIs change. Agent tooling built against them breaks when they do. This section is about whether you have a process to catch that.
- API change notification process exists. When a product team changes an endpoint, there's a process to notify anyone who has built against it — including the agent team.
- Agent tooling in CI. Agent tool definitions are tested against the real API as part of CI, not just at build time.
- Breaking change detection. There's a way to detect when a product change has broken an agent tool before a user discovers it.
- Rollback path defined. If an API change breaks an agent tool and the tool needs to be rolled back or patched, you know how to do that without taking the agent offline.
Scoring
There's no formal scoring system here. But if you have more than two or three "not ready" items in any single section, that section is a production risk. More than five across the whole checklist and the agent project is likely to hit serious issues at launch.
The useful output of this exercise isn't a score — it's a prioritised list of what to fix before the agent hits real users. Work through the sections in order: coverage first, then auth, then rate limiting, then observability, then documentation, then change management. Each one builds on the previous.
