A real-world scenario in many teams: you have an internal portal, some Terraform scripts, and a Slack bot that creates repos. Then a senior dev plugs Claude Code into the workflow, and the agent starts calling scripts to provision staging databases. It calls it twice because the first time timed out. Now there are two databases, one of which no one knows belongs to whom, and the end-of-month cloud bill increases by a few hundred dollars. No one did anything wrong. It's just that your platform was never designed for this type of user.
That is the "N+1 developer": they don't sleep, don't read the wiki, don't ask on Slack, and call your APIs at a frequency a hundred times higher than a human. In 2026, designing an IDP while ignoring AI agents is designing for the past.
Platform teams are growing, but measurement remains the dead end.
Gartner predicts that by 2027, 80% of large technical organizations will have a platform team — a sharp increase from 45% in 2024. But the more concerning figure: less than 30% can prove measurable productivity gain, and about 30% of teams measure nothing at all.
This means most platform teams exist on faith. The portal looks beautiful, the catalog is complete, but when the CFO asks "what does this platform save?", the answer is silence.
AI agents accidentally provide the opportunity to fix this dead end. Because agents don't use a UI — they call APIs. Every agent action is a request with logs, parameters, and results. If you design it correctly, every time an agent creates a repo or deploys a preview, it becomes a data point for lead time, error rates, and cost. Measurement is no longer an extra task, but a natural byproduct of the architecture.
How agents change API design requirements.
Humans use platforms with forgiveness: if a call fails, they read the message, retry, or ask a colleague. Agents do not. They retry according to their own logic, and if your API is not idempotent, every retry consumes a new resource.
Three specific requirements when the agent is the consumer:
Idempotency is mandatory, not a nice-to-have. Every resource creation action must accept an idempotency key. The agent calls create-database Two calls with the same key return the same database, not two.
Machine-readable description. Humans read wiki to know. env what values to receive. Agent needs a schema: JSON Schema for input, structured error codes instead of the string "Something went wrong". One error returned. {"code": "QUOTA_EXCEEDED", "limit": 5, "current": 5} allow the agent to decide whether to stop or request more quota; if a 500 error is returned, the agent can only retry blindly.
Quota and audit trail based on the agent's identity. Actions initiated by the agent must be traceable to: which agent, on behalf of which user, and within what work context. Without this, you cannot answer the question "who created this database" — and you won't dare grant the agent any serious permissions.
# Một action trong service catalog, người và agent cùng gọi được
action: provision-database
input_schema:
type: object
required: [service, env, size]
properties:
size: { enum: [small, medium] } # large phải qua approval
constraints:
idempotency: required
quota: { per_agent: 3/day, per_team: 10/day }
cost_guardrail: { max_monthly_usd: 200, auto_tag: [team, requester, agent_id] }
audit:
on_behalf_of: required # agent phải khai identity người uỷ quyền
Agent version golden path: one action, two types of users
Traditional golden path is template + documentation + portal. Golden path 2026 is service catalog action: a single endpoint that both humans (via portal/CLI) and agents (via API/MCP) can call, with the same guardrail.
Key point: guardrails must reside within the action, not in the UI. If the validation "do not create large instances in staging" only exists in the portal form, an agent calling the API directly will bypass it. FinOps guardrails — budget cap, auto-tagging, TTL for temporary resources — must run during provisioning at the lowest level.
This is also why 73% of platform teams have shipped AI assistants but not every team sees the value: an assistant is only useful when it has reliable actions to call. A chatbot answering "how to create a database" is a gadget. Action provision-database quota and audit are platform features.
Lessons from MCP: what 10,000+ production servers can teach you
MCP is now the de facto standard for agents to talk to tools — 97 million SDK downloads per month as of 3/2026, with over 10,000 public servers running in production. For platform teams, exposing the service catalog via an MCP server is the shortest path to making the platform usable by agents. However, the community has paid the price for two lessons:
Stateful sessions conflict with horizontal scaling. MCP sessions hold state; if your server runs behind a load balancer, a mid-request session landing on a different instance will fail. Either use sticky sessions, push state to an external store, or design the server to be stateless from the start — decide early, because changing later is painful.
Sandboxing for servers with system privileges. An MCP server with filesystem or network access is an attack surface. 2026 production pattern: run in Docker with least privilege, or use gVisor when stronger isolation is needed. The principle is identical to letting a contractor into the office: they have a badge, restricted access areas, and camera surveillance.
Start small: one high-frequency action, done properly
Don't write a 40-page "IDP for agents" design spec. Pick 1-2 actions your team performs most frequently — typically creating a repo, provisioning a database, or deploying a preview environment — then standardize them using a checklist:
| Step | Check question |
|---|---|
| Idempotent | Does calling with the same key twice result in the same resource? |
| Schema | Can the Agent read input/error without a wiki? |
| Identity | Can we trace which agent is acting and on whose behalf? |
| Guardrail | Are budget cap, quota, and TTL included in the action? |
| Measurement | Does each call generate lead time / cost metrics? |
Once an action passes the checklist, expose it via an MCP server and let a pilot team use it with a real agent. Data from that pilot — how much lead time is reduced, the number of agent-initiated requests, and the cost per provisioning — is exactly what puts you in the bottom 30% to prove value.
A good platform has always been defined as "the easiest path is also the right path." That definition does not change. Only the entities walking the path change: your platform's most demanding user this year is not a new junior dev, but an agent calling an API at 3 AM, not reading documentation, and never reporting errors via Slack. Design for it, and humans will benefit too.
