AI-enabled and AI-native have blurred together. AI-enabled means a copilot bolted onto an existing product, like GitHub Copilot at the developer’s side. AI-native means the model is embedded such that removing it collapses the product. The question is what the third rung, agent-native, changes.
The answer: agent-native changes who the platform treats as its user. Most platforms you run today assume human-paced, per-seat use. Agents act in seconds and multiply, so those assumptions break. Shared service accounts and borrowed credentials break too, and it happens before anyone notices.
Treating agents as first-class users means giving them their own identity and accountability, the core of the agent-era rebuild. By the end, you will know how agent-native differs from AI-native, and how MCP turns the developer portal into a control plane.
What is agent-native architecture and how does it differ from AI-native?
Agent-native architecture treats AI agents as a primary workload with their own runtime, identity and contracts. AI-native concerns where the model lives; agent-native concerns which actor the platform treats as its primary user.
Each rung changes the capability model. AI-enabled adds a copilot, and the product still works without it. AI-native embeds the model so the product collapses without it. Agent-native goes further: the AI is central, and the product keeps a full human interface sharing the same actions, data and permissions as the agent. Builder.io puts it this way: agent-native needs both agent capability and a real human interface.
The test you should apply is agent UI parity: the agent works through the same shared action model as the human interface, defined fully in the next section. The point is that the unit of software shifts from a feature to an invocable capability.
Agent-native is distinct from API-first. API-first provided a surface; agent-native adds identity, contracts and a machine-speed lifecycle, which is what agent-native architecture actually means. Open-source templates for mail, analytics and calendar sit at agent-native.com. Identity is the next subject.
What does it mean to treat AI agents as first-class platform users?
A first-class user has its own identity, entitlements, rate limits, audit trail and observable behaviour. Treating agents as first-class means provisioning for them as you provision humans, but at machine-scale churn, rather than a human proxy or shared service account.
Treating an agent as a first-class user also changes the access model. Using the platform is different from calling it through a gateway. Parity means the agent operates the same capabilities through the same shared action model as the human interface: each action is defined once and exposed to the UI and the agent alike, while a thinner API path is a side door.
Agents are a third category: autonomous, non-deterministic and churning at machine speed, fitting neither the human user model nor the traditional machine identity. The PocketOS incident shows why: in April 2026, a coding agent found a token with enough permissions and deleted a production database and every backup in nine seconds. The failure was structural. System prompts are advisory, and a shared, over-broad credential gave a non-deterministic agent a blast radius no one could audit.
Each agent holds a distinct identity with scoped permissions, a lifecycle and an attributable audit trail. Provisioning, metering and deprovisioning are automated, because agents appear and disappear in seconds. OAuth 2.0 Token Exchange (RFC 8693) gives request-scoped delegation, and SPIFFE workload identity gives short-lived, verifiable credentials. This is why agents need their own identity instead of shared API keys.
Once agents hold their own identity and scoped authorisation, the next question is how they discover and invoke what the platform offers. That is where MCP changes the portal.
How does the Model Context Protocol (MCP) change what a developer portal does?
The Model Context Protocol (MCP) is the open standard that lets agents discover and call tools and context across frameworks and clients. It turns the developer portal, Backstage or Red Hat Developer Hub, from a human-only UI into a machine-readable catalogue and control plane.
The portal already holds the catalogue. MCP plug-ins in Red Hat Developer Hub let an MCP client query it and pull documentation. The tools start read-only, because write operations need the authorisation work described above. MCP came out of Anthropic and is now an open standard independent of any single vendor.
When your team selects infrastructure, the work separates into three tiers. An MCP registry handles discovery and allowlisting. An MCP gateway routes requests, often through a shared service account. An MCP runtime executes tools securely with per-user authorisation, vaulted secrets and audit logs. Arcade’s taxonomy is a clear short version.
The criteria are per-user authorisation, stateful handling of multi-turn workflows, audit trails, and standards-grounded identity such as SPIFFE. A gateway that only routes leaves identity, authorisation and proof of what was invoked and by whom open, which is why routers are not enough. The permission intersection is what matters: an agent acts only where its own policy and the human user’s permissions both allow it. That is handled by OpenFGA-style, relationship-based authorisation at the MCP gateway.
Agent-native is a structural change in the broader Platform Engineering 2.0 rebuild: it changes which actors the platform treats as first-class users, made real when the portal catalogue becomes something agents invoke as well as browse.
The litmus test is parity. Humans and agents operate the same shared actions with distinct identity and scoped authorisation instead of shared credentials. Under MCP, selection turns on per-user authorisation, audit and standards-grounded identity.
The question to carry forward is whether the platform treats agents as first-class users, and whether it can hold one accountable for what it invokes. From there, the build versus buy decision and the complete Platform Engineering 2.0 overview pick up where this leaves off.
Frequently Asked Questions
Do I have to rebuild my platform from scratch to support AI agents?
No. Agent-native is an architectural shift, not a rip-and-replace exercise. You can keep your existing copilots and embedded models while giving agents their own runtime, identity and contracts alongside them. The practical path is to add a machine-readable catalogue and per-agent authorisation incrementally, then extend parity to more capabilities. What matters is that agents become a first-class workload, not that your current product is discarded.
How do I test whether my platform is truly agent-native?
Apply the parity test. Ask whether an agent can operate the same product through the same shared actions and capabilities a human uses in the UI, with its own identity and scoped authorisation. If the agent can only call a thinner API path or must borrow a human’s credentials, you are still API-first or AI-native, not agent-native. Parity, identity and accountability are the measures.
Can I just use a service account for my AI agents?
Not if you want accountability. A service account is a static, over-broad identity with no per-agent lifecycle, so it cannot distinguish one agent from another or revoke one agent without breaking the rest. Agents churn at machine speed and need scoped entitlements, their own audit trail and automated deprovisioning. Treat each agent as a distinct non-human identity, not a borrowed service account.
What happens if AI agents share credentials?
You lose attribution and create a wide blast radius. When several autonomous agents act through one shared key, a single misbehaving agent can burn through quota, change data or call expensive services in seconds, and the audit trail cannot say which agent did it. The PocketOS incident showed exactly this failure: over-broad, shared credentials let one agent’s actions compound before a human could intervene.
Should an AI agent inherit its human operator’s permissions?
Not by default. An agent should act with the intersection of its own scoped permissions and, where relevant, the on-behalf-of authorisation of the user who triggered it. Inheriting everything a human can do gives an autonomous, non-deterministic actor too much blast radius. Compute permissions at each request so the agent can do its job without carrying the full rights of any single human.
How do I hold an AI agent accountable for what it does?
Give it a distinct identity and record every action it takes against that principal. Accountability means the platform can reconstruct what an agent invoked, when, and on whose behalf, then revoke or constrain that identity if something goes wrong. This is the same discipline you apply to human users, automated for machine speed. Without an attributable audit trail, misbehaviour becomes a mystery you cannot investigate.
Why do AI agents need their own rate limits?
Because agents act in seconds and can consume capacity far faster than a human ever could. A rate limit scoped to a specific agent stops one runaway workload from exhausting shared quotas or triggering runaway costs before anyone notices. It also gives you a control point: you can throttle, pause or deprovision a single agent without affecting the rest of the platform.
What is SPIFFE and why does it matter for agent identity?
SPIFFE is an open standard for workload identity that issues verifiable, short-lived identities to software rather than long-lived keys. It matters because agents need credentials that can be issued, rotated and revoked at machine speed without a human in the loop. Using a standards-grounded identity like SPIFFE lets you attribute every action to a specific agent and revoke that identity cleanly when it is compromised or decommissioned.
Do I need to use Claude to work with MCP?
No. Anthropic created the Model Context Protocol, but it is an open interoperability standard, not a Claude-only feature. MCP lets agents discover and call tools and context across different frameworks and clients, which is precisely what makes it useful for an enterprise control plane. You do not need to adopt Claude, or any single vendor, to benefit from standardised tool discovery.
Is MCP the only way to build an agent-native platform?
No. You can build bespoke integrations or custom APIs for each agent and tool, but that reintroduces the per-framework sprawl MCP exists to remove. MCP standardises tool manifests and context discovery so one catalogue serves every agent and client. It is the emerging standard rather than a mandate. If you skip it, you take on the integration and authorisation work it would otherwise handle.
How do I know if my platform is ready for AI agents?
Start with identity, authorisation and audit, not model features. Ask whether an agent can hold its own scoped identity, act through the same shared capabilities as your human UI, and leave an attributable audit trail. If agents would still need shared credentials or human-only interfaces to operate, the platform is not ready. Readiness is about who the platform can hold accountable, not how many models it embeds.
How do I price or license AI agents if they are not per-seat users?
Move from per-seat pricing to usage-based or workload-based metering. Agents churn in seconds and run at machine speed, so a fixed seat count cannot represent them. Meter actual invocations, tokens or capacity consumed, and attach limits to each agent’s identity. This keeps costs aligned with the work agents actually do and gives you a lever to throttle or revoke a runaway workload.
