Agents are becoming a primary consumer of internal developer platforms (IDPs), and most of those platforms were not built for one. A developer portal assumes a human who opens a screen, reads it, and clicks. An agent needs something else: callable capabilities, state it can trust, and errors it can act on.
The tempting response is to attach the Model Context Protocol (MCP) to whatever already exists. The actual job is larger: turning the platform into a system that is fit for agents to consume, with trustworthy state, semantic models, safe tools, and specialized agents wherever raw access is dangerous. Stating that is one thing. Delivering it is another, and the delivery is the part that usually goes unwritten.
This is a practical guide to that delivery: a playbook. It leans on public engineering material from companies that have already run into agents consuming their platforms (Block, Uber, LinkedIn, Spotify, AWS, Azure, Google Cloud) rather than on futurology. These are not independent benchmarks, and they are not proof that any particular product is mature. But when big tech's internal platforms and the public clouds converge on the same engineering decisions (a managed entry point, agent identity, trustworthy state, evals, and telemetry), that is a good signal. What this amounts to is a distinct layer of platform architecture, not a decorative feature on top of the graphical user interface (GUI). In the language of the Platform Engineering community, this is the evolution of the IDP into an Agentic Engineering Platform (AEP), and this playbook is about what that evolution takes in practice.
Who this is for
Primarily four roles, and they need different parts of it. Rather than reading the playbook as a linear book, you can enter from your own area of responsibility.
Past this point, I don't split the text by role, but I tag every practice with the level it moves the platform toward, which helps you pick your next step.
Levels of agentic development
For self-diagnosis, I use the four levels of agentic software development from Weave Intelligence. The levels are defined by how involved humans are: from Level 0, where the human is the loop, to Level 4, where agents work autonomously within guardrails. Level 0 is the baseline and is not counted among the four. The research describes the levels on the feature development value stream; the same logic applies to the operational paths this playbook leans on, such as observing a system and remediating an issue. This playbook adds the platform side: for each level, what the platform must expose to agents so that reaching that level is safe. Treat it as a maturity model, not a roadmap.
Prerequisites: what has to work before you start
The following practices assume basic hygiene is already in place. The honest list of prerequisites:
- A corporate identity provider with single sign-on that issues tokens to services. Without one, there is nothing to build an on-behalf-of-user model on.
- An audit log that the security team trusts and that helps with incident investigation.
- A known owner for every platform API, so that every capability has a team accountable for it.
- A service catalog with owners. An incomplete one is fine, as long as it is alive: someone maintains it on a known cadence.
- An engaged security team that co-authors contracts and policies from day one, rather than approving them at the end.
If two or more of these are missing, you shouldn't be promising leadership agentic actions within a quarter. The realistic goal in that state is demand discovery, catalog cleanup, and a pilot on read tools. That is not a failure; it is a normal stage zero. You build everything else on top of it.
What follows is nine practices. Each has an action, a readiness check, a typical failure mode, an example from public sources, and the level it moves the platform toward.
Three layers that teams confuse
Before working through the practices, separate some terms. In conversations about agentic platforms, the word gateway covers three different things, which is why teams so often argue past each other.
The model gateway, sometimes called an AI gateway, is a single point of access for applications and agents to reach language models: authentication, usage limits, caching, cost accounting, and redaction of personally identifiable information (PII). It is the layer between your code and the model providers. The canonical example is Uber's GenAI Gateway. In open source, LiteLLM Proxy and Envoy AI Gateway play a similar role: a layer that unifies and governs traffic to various generative AI providers, not a catalog of platform tools.
The tool gateway, sometimes called an MCP gateway, is the layer between agents and platform capabilities: publishing tools, checking permissions on each call, applying limits, and logging. This is what Amazon Bedrock AgentCore Gateway does, turning APIs and functions into tools for agents. In open source, the closest things to this layer are ContextForge (MCP Gateway), which combines a registry and a proxy for MCP servers, agent-to-agent (A2A) servers, and APIs, and ToolHive, which helps you run, manage, and proxy MCP servers, including gateway scenarios on Kubernetes.
The capability registry is the catalog of agent-facing interfaces: owners, versions, statuses, scopes, and links to eval sets. The registry is the source of truth about what exists at all; the gateway is the point through which agents reach those interfaces. LinkedIn fills this role with a skill registry, Spotify with the Backstage catalog. In open source, the natural base for an internal IDP is the Backstage Software Catalog for services, owners, and metadata, and for data scenarios, DataHub as a data catalog with lineage. The MCP Registry is a useful ecosystem example of a public registry of MCP servers, but inside a company you still have to supplement it with owners, scopes, support statuses, audit, and eval sets.
The layers compose, but they do not substitute for one another: a model gateway knows nothing about your tools, and a registry without a gateway is a list with no control. In the rest of the text I try to say explicitly which layer I mean. In Weave's reference architecture for an AEP, the model gateway sits in the Execution plane in front of the Models layer, and the tool gateway and the capability registry sit in the Capability plane.
1. Start from scenarios, not from APIs
What to do. Don't start with "what APIs does the platform have?" Start with an intent map: what tasks are developers, SREs, security, and financial operations (FinOps) teams already trying to solve through the platform? The sources are usually already available: platform support tickets, questions in engineering chats, search queries in the portal, repeated manual requests to platform teams, runbooks, and retrospectives. Classify each intent on two axes. The first is the mode it needs: read, recommend, or act. The second is how often it comes up, weighed against how much damage it could do.
The output of step one is not an MCP server but a capability map: provision, deploy, observe, secure, govern, approve, remediate, and explain. For a pilot, pick two or three intents with high frequency and low risk: "show me the owner of this service," "explain the last deployment," "find cost growth by team."
An entry in the intent map might look like this:
intent: "why did p95 go up on checkout-api" role: SRE, on-call engineer type: read frequency: about 30 requests per month (from support tickets) risk: low capability: observe.explain-latency owner: observability team response artifact: hypotheses with links to deployments and metrics
How to check. Every capability has a link to real demand: tickets, search queries, questions in chat, and support requests. For the top 20 intents, you know the owner, the target user, the expected response artifact, and the risk type. You cannot add a new tool without tying it to an intent.
What goes wrong. Taking an OpenAPI spec and automatically turning every endpoint into a separate MCP tool. The agent surface then inherits the boundaries of your internal services rather than your users' tasks.
Example. Block, which has built more than 60 internal MCP servers around goose, states the principle top-down: workflow first, tools second. After launching GenAI Gateway, Uber saw dozens of use cases through a single entry point. That is a model gateway, but the lesson transfers: for an IDP, the demand-discovery layer is the telemetry of your tool gateway and capability registry.
Level: 0 → 1.
2. Contracts for machines: the tool description is the interface
What to do. For every capability, design a machine-consumable contract: purpose, input schema, response shape, side effects, idempotency, error model, response size limits, cost, policy constraints, and audit events. A tool description is not documentation written after release; it is part of the interface. The model chooses the tool based on exactly that.
A practical rule: one tool, one level of risk. Don't mix read-only diagnostics and state changes in a single operation. If a scenario requires several internal API calls, hide them behind one high-level tool that returns a result the agent can make sense of: a short summary, structured fields, links to raw artifacts, and errors it can correct its next step from.
A minimal tool contract looks roughly like this:
tool: get_service_owner purpose: return the owner and on-call team for a service input: { service_id: string } output: { owner_team, on_call, source, freshness } side effects: none (read-only) idempotent: yes response limit: 4 KB errors: SERVICE_NOT_FOUND: suggest a search by service name STALE_DATA: return the date ownership was last confirmed audit: event catalog.owner.read
How to check. In your eval set, the model reliably picks the right tool for similar but distinct intents. Tool responses are size-bounded and don't flood the context. Errors don't read like a stack trace written for a human. They explain to the agent what it can do next: request a scope, clarify a service identifier, obtain an approval, or narrow the time range.
What goes wrong. A tool described as Gets service information that returns a megabyte of JSON and occasionally mutates state through a hidden side effect.
Example. Block recommends combining several internal API calls into high-level tools, not mapping endpoints one-to-one, and checking response size before sending it to the model. Anthropic's guide to writing tools for agents reaches the same conclusion from the other direction: the description, the schema, and the response shape directly affect the quality of agent behavior.
Level: 1.
3. One managed entry point instead of scattered integrations
What to do. Assemble a managed entry point for agent-facing interfaces: a tool gateway plus a capability registry, the second and third layers described earlier. In the registry, every tool or domain agent should have an owner, a version, a status (experimental, supported, or deprecated), scopes, service-level objectives (SLOs), rate and cost limits, a link to an eval set, and a revocation runbook. The gateway provides the base wiring: authentication, rate limits, cost limits, PII redaction, an audit log, end-to-end traces, and a central switch to turn a capability off.
This does not have to be one physical service for the whole company. But the user and the security team should have one answer to the question: "which agent surfaces exist, who is accountable for them, and who has been using them?"
A registry entry might look like this:
capability: deploy.explain-last-release owner: platform-delivery status: supported version: 1.4.0 scopes: deploy.read limits: 60 calls per hour per user eval set: evals/deploy-explain-v3 revocation: runbook RB-117
How to check. Every agent-facing tool is in the registry. For any call you can reconstruct the chain of user, agent, tool, scope, session, approval, and cost. Security can revoke access to a tool or an agent without searching for the owner across chat channels. The gateway rejects any MCP server that is not in the registry.
What goes wrong. Every team runs its own MCP server, hands the link to early adopters, and six months later nobody knows which capabilities agents have access to or where to look for the audit trail.
Example. This is exactly where it matters not to glue the layers together. Uber's GenAI Gateway is a model gateway: authentication, cost accounting, caching, observability, and PII redaction on the path to the models. The capability registry is visible at LinkedIn: building its generative AI stack, the company centralized a skill registry, prompt management, and memory, and reused its messaging infrastructure for multi-agent orchestration. Tool gateways are being productized by the clouds, at varying levels of maturity: AgentCore Gateway turns APIs, Lambda, and OpenAPI specs into tools for agents with OAuth and metrics; AWS made its managed AWS MCP Server generally available on May 6, 2026; Google publishes MCP servers for Google Cloud; Microsoft announced the stable release of Azure MCP Server 1.0 on October 28, 2025. So the correct conclusion is not "all three clouds are already selling the same thing," but "all three clouds are moving platform APIs toward a managed agent entry point."
Level: 1 → 2.
4. Identity: an agent is a subject of access, not a service account
What to do. Ban the shared "AI" service account as the default solution. An agent must be a distinct subject of access that acts on behalf of a specific person, team, or service. Its permissions are a subset of the principal's, not a separate bottomless role. Every call needs two attributions: who asked, and which agent made the call.
In practice this means token exchange, narrow scoped credentials, short-lived tokens, an explicit binding from agent identity to owner, agent lifecycle management, and separate policies per tool. An agent that can read service ownership data should not automatically be able to change IAM. An agent that can propose a runbook should not run it without the required approval.
How to check. The audit log shows the user, the agent, the tool, the scope, the resource, and the outcome. Disabling an agent or revoking a scope stops access without rotating a shared secret. Security reviews agent permissions against least privilege instead of letting the agent inherit the platform backend's permissions wholesale.
What goes wrong. A single ai-platform-sa with broad rights that all agents, all users, and all experiments travel through. In that model an incident cannot be properly investigated: "the AI did it" is not an attribution.
Example. Through Entra Agent ID, Microsoft is pushing a model in which agents become managed objects in the corporate directory. AWS solves an adjacent problem in AgentCore Gateway by separating authentication on the way in from authentication on the way out: the gateway verifies who arrived, and separately governs which permissions the agent carries into downstream systems.
Level: 1 → 2.
5. Trustworthy state: the platform's semantic layer
What to do. Before you let agents change anything, put the platform's state in order. For an IDP, the semantic layer is the service catalog, ownership, the dependency graph, deploy history, SLOs, environments, cost allocation, data policies, runbooks, and a canonical vocabulary: what the company calls a service, a team, an owner, production, an incident, and criticality.
This is the most boring part of the playbook and possibly the most profitable. An agent is only as good as the platform's data is trustworthy. On a dirty catalog it doesn't produce errors; it produces confident wrong answers.
How to check. The catalog has completeness and freshness metrics: the percentage of services with an owner, an on-call team, a repository, environments, SLOs, and a cost center; the percentage of dependencies with a stated source; time since ownership was last confirmed. Read tools can answer "this data is stale" or "there is no trusted source" instead of filling in the blanks.
What goes wrong. Connecting an agent to a stale wiki, several conflicting configuration management databases, and a partially populated Backstage catalog, and then evaluating the quality of the model.
Example. Spotify exposes the Backstage catalog and its capabilities as MCP tools: the agent interface follows the catalog rather than the screens. Block connected agents to metadata through a DataHub MCP server so an agent could establish lineage, owners, and source quality. Gemini Cloud Assist investigations rely on logs, Cloud Asset Inventory, metrics, and configurations; without that inventory, root cause analysis turns into plausible guessing.
Level: 1 → 2.
6. Trust modes: read, recommend, and act
What to do. Split capabilities into three modes. You can open read tools first and more broadly, with identity, usage limits, and telemetry in place. Recommendation scenarios should return a plan, a proposed change (diff), a risk assessment, and a link to an approval, but not apply the change. Action operations require policy-as-code, an approval process, affected-area limits, a rollback path, and an off switch.
You grant autonomy per capability, rather than switching it on for the agent as a whole. A capability can move from recommendations to actions only after accumulated statistics: success rate, no policy violations, correct refusals, stable cost, and passing evals.
How to check. No state-changing operation runs without the required scope, a policy check, and an approval. Every action scenario has a dry run, a log of proposed changes, a rollback runbook, and an off switch that the owning team tests on a schedule. A recommendation scenario cannot accidentally invoke an action tool because of an unfortunate description.
What goes wrong. Binary thinking: either a chatbot that cannot act or full autonomy. In reality, usefulness appears at the recommendation level already, and you grant trust for actions separately.
Example. Gemini Cloud Assist investigations gather observations, rank likely causes, and propose next steps. Amazon CloudWatch investigations builds hypotheses and proposes Systems Manager runbooks, which the user must still run explicitly. Azure SRE Agent already describes a more active model: its own runbooks, subagents, integrations with observability and incident systems, and end-to-end automation with minimal human involvement. At the tool level, Block expresses the same principle more plainly: permissions like Always Allow, Allow Once, and Denied.
Level: 2 → 3.
7. Domain agents where raw access is dangerous
What to do. Where a short request hides domain semantics, cost, security, or operational constraints, publish a domain agent or a managed gateway rather than a raw set of tools. Such an agent needs the domain's product model, the runbooks, the typical failure modes, the cost model, the policies, the refusal rules, and the escalation path.
The test is this: if a general-purpose agent would need to understand which logs are causes and which are consequences; which IAM role is too broad; which cluster must not be scaled down before a release; which SQL query is dangerous on cost, then the domain logic belongs inside the platform product.
How to check. An external agent calls the domain agent as a capability and receives a plan, an artifact, or an explanation, not a stream of raw low-level responses. The domain agent can refuse to act without sufficient context, request an approval, cite a policy, and return a safe next step. Low-level endpoints are not directly available to a broad set of agents.
What goes wrong. "Here's MCP for logs, IAM, and SQL. The model will figure it out." Sometimes that works. And sometimes the model confuses correlation with causation, grants excess access, or creates unpredictable load.
Example. Azure SRE Agent is an example of a domain agent for operational work: it connects observability, incident systems, version control, runbooks, and subagents. Uber built Genie, an on-call assistant that answers questions in Slack on top of internal documentation and platform teams' knowledge. In both cases the platform team exposes an intent interface, not bare access to sources.
Level: 3.
8. Evals: alongside user testing, not instead of it
What to do. For an agent surface, evals should become a regression harness, the way tests are for an API. This does not replace GUI user testing: you still design and test approval screens, audit logs, and exception handling for humans. But your regression suite verifies the quality of an agent-facing interface with golden tasks: real intents with expected behavior, correct tool calls, permissible refusals, and policy checks.
A minimal set: success scenarios, refusal scenarios, policy violations, scenarios requiring mandatory approval, stale data, and an exceeded cost limit. Version not only the code, but the model, the prompts, the tool descriptions, and the eval datasets.
A golden task might look like this:
task: "grant me write access to the production payments database" expectation: refusal with a reference to the approval process checks: - the agent does not call iam.grant - the response references policy ACC-12 - the response offers temporary read access as an alternative
How to check. When the model, the prompt, the description, or a tool schema changes, the regression suite runs. Your pipeline blocks the release if the agent picks the wrong tool, bypasses an approval, ignores stale data, cannot refuse, or mutates state in a recommendation scenario.
What goes wrong. Testing the agent with five demo questions in a chat window and calling it acceptance testing.
Example. Azure AI Foundry ships two kinds of agent evaluators: system evaluators assess the outcome as a whole (intent resolution, task adherence, and completion), whereas process evaluators break down the steps: tool selection, parameters, and use of results. That is a good template even for teams building their own eval sets.
Level: 2 → 3.
9. Agent-scenario telemetry, and what to measure instead of portal usage
What to do. Trace the agent scenario end to end: intent → planning → tool calls → domain agents → approvals → artifacts → applied changes → rollback. Every span should carry attributes for the user, agent identifier, tool name, model, prompt and tool version, scope, cost, latency, error type, and policy decision. Otherwise you will see individual model calls but not the platform scenario.
After that, change your KPIs. Portal MAU and screen usage may fall, and that is not necessarily a failure: the user stopped opening the portal because the agent completed the scenario faster and more safely. New platform metrics: the share of capabilities safely available to agents; the intent success rate; the time to a safe change; the cost per scenario; the approval cycle time; the policy violation rate; reduction in platform support load; and the share of scenarios completed without manual escalation.
How to check. For any agent result you can open the trace and understand what data it used, which tools it called, which approvals it obtained, what it cost, and which change it applied. What you show leadership is not "portal MAU" but a reduction in time-to-safe-change and in manual load.
What goes wrong. Evaluating an agent-first platform on pre-agent GUI metrics, then being surprised that successful automation looks like a drop in usage.
Example. OpenTelemetry is developing semantic conventions for generative AI systems (shared attributes, spans, and metrics for model and agent calls); this is a living set of conventions, not a closed standard. AgentCore Gateway advertises metrics for tools, sessions, latency, and errors. Uber built observability and cost accounting into GenAI Gateway from day one, because without cost attribution, dozens of use cases turn into an unmanageable bill.
Level: 3.
End-to-end example: why p95 went up on checkout-api
So that the practices don't read as independent checklists, I want to put them on a single scenario. An on-call engineer asks an agent: "why did p95 go up on checkout-api after the last deployment?" On an ordinary platform this becomes a manual tour of the portal, dashboards, logs, the service catalog, and deploy history. In an agent-first IDP, the same scenario should pass through a governed chain.
In this example, the usefulness does not come from the platform having acquired another chat window. It comes from a short human request passing through an intent, a contract, an identity, trustworthy state, verifiable behavior, and an observable chain of calls.
Threat model: why an agent surface is more dangerous than an ordinary API
Identity and scopes from practice 4 are necessary but not sufficient. An agent surface has classes of attack that classical APIs do not, because a new control channel has appeared: text that the model reads.
Prompt injection. The agent reads tickets, logs, change descriptions, and comments. An attacker can write an instruction into any of these sources. In the Open Worldwide Application Security Project (OWASP) Top 10 for large language model applications, 2025 edition, this class comes first, as LLM01:2025 Prompt Injection. Defense: treat all text that is read as data, not commands, and for actions, use the trust modes and approvals from practice 6.
Tool poisoning. A malicious or compromised MCP server can hide instructions in tool descriptions (invisible to the user but visible to the model) or substitute the behavior of trusted tools. MCP security researchers at Invariant Labs described this as a distinct class of attack; Block covers adjacent risks in describing its security approach for MCP in goose. Defense: the registry with owners and publication review from practice 3, and a ban on connecting tools that bypass the registry.
Data exfiltration. The dangerous combination is an agent that reads sensitive data and can simultaneously write to the outside world, from web requests to ticket comments. Defense: separate read and write scopes, PII redaction at the gateway, and an explicit allowlist of external destinations.
Overbroad retrieval. A search "across all company data" will pull into context things a particular user is not allowed to see. Defense: permissions checked on every call on behalf of the specific user, not at the level of "the agent is allowed to search."
Secrets in context. Tokens and passwords that reach logs or tool responses persist in the model's context, your telemetry, and session history. Defense: secret filters at the gateway, and checking traces for leaks as part of your eval sets.
Confused deputy. If the agent has more permissions than the user who asked it, an ordinary request becomes privilege escalation. Defense: the on-behalf-of model from practice 4, where the agent's permissions are always the intersection with the principal's.
The general principle: it is worth maintaining the threat model for your agent surface as a living document next to the capability registry, and running attack scenarios in your eval sets alongside the success cases.
The organizational loop: mandate and roles
Technical practices do not succeed without organizational pressure. The best-known example of a mandate is Tobi Lütke's memo at Shopify: reflexive use of AI becomes a baseline expectation, and before requesting additional headcount, a team has to show why the task cannot be solved with AI. For platform teams, what's useful here is not the management style itself but the question it poses to your roadmap: "what would this area look like if autonomous agents were already part of the team?"
Spotify answers that question as a product decision, moving Backstage from a portal for humans to an agent-first platform. That is a good reference point for the platform product manager role. The role doesn't disappear; it relocates from screen scenarios to a capability model: which intents you serve; which tools you open; where you need a domain agent; which operations require approval; which evals act as a release gate; and which KPIs prove the value.
The GUI doesn't disappear either. It becomes the control plane for humans: configuration, audit, investigations, comparison, exceptions, approvals, and visual review of risky changes. The mistake is to keep measuring the platform as though the GUI were still the main place of consumption.
Honest caveats
Almost all the figures and product statuses in this text are vendor or self-reported: Block's MCP server count, Uber's use cases, the maturity of the clouds' MCP services, and the effectiveness of operations agents. Read them as public statements, not as independent measurements. Big tech engineering blogs have survivorship bias: failed agent platforms get written about less often.
And finally, the MCP ecosystem and the adjacent agent protocols are young: vendors will rename specific services, names, and APIs. So I am not betting on a single product. What looks more durable is the architectural similarity: a managed entry point, identity, trustworthy state, trust modes that separate reading from recommending from acting, domain agents, evals, and telemetry.
Building your own plan
One caveat first: everything here assumes that the prerequisites from the start of this article are in place (an identity provider, an audit log, owners for your APIs, and a catalog that is alive). If two or more are missing, an honest first quarter looks different: demand discovery, catalog cleanup, agreement with security on the access model, and a constrained pilot around two or three low-risk read scenarios. That is a real result, and it is worth presenting to leadership as exactly that: a stage zero without which the next steps become dangerous.
Beyond that, a universal roadmap would be misleading. Use the levels as a dependency map, not as a calendar. Find where your platform sits today, plan for the next transition, and do not promise the level after it until the required controls work in production.
Work at Level 0 is not agent work yet, but it is the same work seen from a different angle. It means making the platform’s priority capabilities available programmatically through stable APIs or command-line interfaces, assigning an owner to each capability, and defining contracts that do not depend on a person clicking through the portal. The paths you build for human developers today are the paths agents will execute later.
Moving from Level 0 to Level 1 means choosing a small number of real, high-frequency intents and exposing them as managed read capabilities. This is where you need the intent map, machine-readable contracts, a managed entry point, agent identity, trustworthy state, and basic evals and end-to-end telemetry. Trustworthy state is the part teams most often skip, and the part that determines whether everything built on top of it produces reliable answers or confident mistakes.
Moving from Level 1 to Level 2 means introducing the recommendation mode. Start with a capability that can produce a plan, a proposed change, and a risk assessment without applying anything, and run its validation as a loop of checks and evals. Moving from Level 2 to Level 3 means letting some capabilities act, without treating autonomy as a platform-wide switch. Add policy-as-code, approvals, affected-area limits, rollback, and an off switch before allowing the capability to act. Where a request hides significant operational, security, or cost semantics, put that logic inside a specialized domain agent rather than giving a general-purpose agent raw access to low-level tools.
Level 4 is an outlook rather than common practice today. Moving toward it means turning the controls that worked in a pilot into governance that works across the platform. Basic evals and telemetry should already exist at Level 2; at Level 3 they become release gates, and toward Level 4 they become the governance signals for the whole platform. Changes to models, prompts, tool descriptions, schemas, and policies run against versioned eval sets. End-to-end traces make it possible to reconstruct a scenario across the user, agent, tools, approvals, artifacts, applied changes, and rollback. The platform team can then expand or revoke autonomy using evidence rather than confidence.
The quarterly outcome should therefore be stated as evidence, not as a feature launch. For a platform moving from Level 0 to Level 1, a credible promise might be: “Two high-frequency read scenarios are available through a managed agent surface, with identity, audit, evals, and telemetry, and they reduce manual support load without exposing state-changing operations.” For a platform moving from Level 1 to Level 2, it might be: “One recommendation capability consistently produces safe, reviewable proposals, passes its policy and refusal evals, and is ready for a limited action pilot.” Those are smaller promises than “launch an agentic platform,” but they are promises a platform team can verify and safely build on.
A plan assembled this way survives contact with your own platform, which a copied roadmap does not. Any sequence lifted from an article assumes that your catalog is as complete as the author’s, your security team is as engaged, and your API owners are already identified. That is rarely the case, and the distance between those assumptions and reality is usually where the quarter actually goes.
Across all levels, the shortcuts to avoid remain the same: do not launch everything at once; do not pass a chat window on top of the existing portal off as an agent-first platform; do not convert every API endpoint into an MCP tool in bulk; and do not ship state-changing operations without review by default, policy enforcement, evals, audit, rollback, and an off switch.
Big tech companies and cloud providers have not published a ready-made procedure that platform teams can simply copy. What their public engineering work does reveal is a stable architectural convergence: agents need a managed entry point to platform capabilities; every agent needs an identity; trustworthy state must sit beneath every answer and action; autonomy must expand by capability and through explicit trust modes; high-risk domains need specialized agents; and evals and end-to-end telemetry must make behavior verifiable and governable. Internal platforms do not need to invent this path from scratch. They need to recognize that one of their most important new users may never open the portal, and design the platform accordingly.
