The Three Persona Platform User — Human Developer, AI Agent, Hybrid Collaborator

TL;DR. Team Topologies, the CNCF maturity model, DORA, and SPACE were all built on one assumption: the platform serves a human developer. Platforms in 2026 serve three users — the Human Developer, the AI Agent operating semi-autonomously, and the Hybrid Collaborator. The AI Agent persona needs different platform design because it does not navigate a portal or read a golden path the way a human does.

Every major platform engineering framework was designed for a single type of user: the human developer. Team Topologies. The CNCF Platform Engineering Maturity Model. The DORA research program. The SPACE framework. Each was built on the assumption that the platform serves people — engineers making decisions, writing code, responding to incidents, evaluating tradeoffs.

That assumption was accurate when those frameworks were written. It is not accurate now.

Platforms in 2026 serve three distinct user types: the Human Developer who works alone, the AI Agent that operates semi-autonomously on the platform, and the Hybrid Collaborator who is a human and AI working together in real time. Designing for only one of these is designing for a user population that no longer represents the full load on the platform.

Why every existing platform framework was built for exactly one user — and why that is now a gap

The assumption of a single human user is not a mistake in the existing frameworks. It was accurate when they were written.

Team Topologies (2019) was written before AI coding assistants had significant adoption. The cognitive load model describes human mental effort because the users it was designed for were human. The CNCF Platform Engineering Maturity Model describes internal developer platforms in terms of developer experience: the portal, the catalog, the golden paths, the self-service capabilities. Each of these is designed around human navigability — what a developer can find, understand, and use independently.

The DORA research program measures deployment frequency, lead time, change failure rate, and mean time to restore based on the assumption that changes flow through the system because humans initiate and verify them. The research definitions were calibrated to human-paced development cycles.

None of these frameworks were wrong for their time. They are incomplete for the current time.

The Foundations Framework v3.0 observed this incompleteness as the third of three motivating observations: "The platform's user is no longer only human. AI agents act semi-autonomously on the platform. Hybrid human-AI pairs work in patterns that neither pure automation nor pure human work describes well. Frameworks that assume a single user type are designing for a population that no longer exists at scale."

The Human Developer: the user all existing frameworks describe well

The Human Developer works alone, in an editor, with the cognitive limitations and cognitive capabilities of human biological attention.

This is the user the existing frameworks describe well. Human Developers need discoverable interfaces — the golden path has to be findable, documentation has to be written for someone who has not encountered the system before. They need cognitive load management: the platform should absorb extraneous concerns so the developer's attention is on the business domain, not on infrastructure boilerplate. This is the Cognitive Absorption design discipline. They need recoverable failure modes: when something goes wrong, the human developer needs to understand what happened and what to do. Error messages need to be readable. Rollback procedures need to be documented.

Human Developers also need trust signals. Humans evaluate quality through social and contextual cues. A golden path that has been used by many engineers in many contexts is more trustworthy than one that appears newly built. Documentation that shows real examples from real production use is more trusted than documentation that shows only happy paths. The platform's track record of reliability becomes part of the Human Developer's trust model.

The Human Developer is the user type that existing frameworks handle. The gaps appear when the other two personas enter the system.

The AI Agent: what changes when the platform user does not navigate a portal or read documentation

The AI Agent operates semi-autonomously on the platform. It executes tasks — code generation, test runs, dependency updates, deployment verification, incident investigation — without continuous human oversight. It may be a coding assistant running in an automated pipeline, a CI/CD integration that generates code based on specifications, an automated security scanner that proposes and implements remediation, or an agentic workflow that chains multiple operations together.

The AI Agent needs fundamentally different things from the platform than the Human Developer does.

It needs machine-readable API surfaces, not human-readable documentation. The Human Developer reads the portal. The AI Agent calls the API. A golden path that requires navigating a web UI is not accessible to an agent. A capability documented in Confluence is not consumable by an automated workflow. Platform capabilities that Human Developers use need documentation. Platform capabilities that AI Agents use need clean API surfaces with predictable contracts.

This is not a theoretical future need. Microsoft's work on platform engineering for the agentic era describes how "modern agents can ingest natural language intent, reason over API schemas, generate and validate IaC, and apply changes directly via provider APIs." Source: Platform Engineering for the Agentic AI Era, Microsoft Azure DevBlogs. If your platform's API surface is not clean enough for an agent to reason over, the agent cannot use it reliably. The agent falls back to less reliable methods, which is the AI equivalent of the human developer routing around the platform under deadline pressure.

AI Agents also need constrained permission scopes with explicit blast radius limits. Human Developers have judgment — they can evaluate whether an action is appropriate for the context. AI Agents operating semi-autonomously do not have the same judgment. A platform that gives AI Agents the same permission scope as senior engineers has designed for the wrong threat model. The platform needs to provide capability-scoped tokens, read-only access to production environments by default, and explicit guardrails that prevent agents from taking actions whose blast radius exceeds the task specification.

Deterministic responses to deterministic inputs matter here in ways they do not for human users. Human Developers can handle ambiguity — an unclear error message can be investigated, an undocumented behavior can be reverse-engineered. AI Agents handle ambiguity poorly: a response that varies for the same input produces inconsistent downstream behavior in automated workflows. Platform APIs used by AI Agents need to return consistent error formats, predictable response structures, and explicit status codes that map to documented outcomes.

Finally, AI Agents need audit trails by default. Human Developers create audit trails implicitly through their commit history and Slack messages. AI Agents operating semi-autonomously may not leave the same kinds of trails unless the platform explicitly instruments them. Platform teams that deploy AI Agents without explicit audit instrumentation will find themselves unable to answer the question "why did the system do that?" after an incident.

The Hybrid Collaborator: the persona existing frameworks handle least well

The Hybrid Collaborator is a human and an AI working together in real time: a developer using a coding assistant, a platform engineer using an AI agent to draft Terraform, a senior engineer supervising an automated deployment workflow. Neither the human nor the AI is working alone. The output is the product of their interaction.

The Hybrid Collaborator is the persona that existing frameworks handle least well. It does not fit the Human Developer model (one human, using the platform independently) or the AI Agent model (automated system, no continuous human oversight). It has characteristics of both.

The platform must support the human's review work, not just the AI's generation work. A Hybrid Collaborator using an AI to generate code is not doing the coding work. They are doing the review work: evaluating whether the AI output is correct, appropriate, and safe to merge. The platform's contribution to this work is different from its contribution to human development. The platform needs to surface the context that makes AI output evaluable: what the system is supposed to do, what the test coverage shows, what the deployment history looks like, what the change failure rate is for this service. A portal designed for human developers shows the developer what they need to build. A platform designed for Hybrid Collaborators also shows the reviewer what they need to evaluate AI output.

Trust calibration is different for Hybrid Collaborators than for the other two personas. Human Developers trust platform capabilities through repeated use. AI Agents do not need to trust: they call the API and handle the response. Hybrid Collaborators need to calibrate trust in the AI output, which depends partly on platform signals: does the AI have access to the right context? Is the AI's output consistent with the platform's stated constraints? Has the AI's output been validated against the same criteria as human output? Platforms that do not expose these calibration signals leave the human member of the pair with less information than they need to review confidently.

The METR 2025 study found that senior developers using AI coding assistants in unfamiliar codebases were nineteen percent slower than baseline, even when they reported feeling faster. Source: METR, Measuring the impact of early 2025 AI on experienced open source developer productivity. The cognitive cost moved from writing the code to validating the AI output. A platform designed for Hybrid Collaborators absorbs that validation work where possible: automated test coverage, clear deployment constraints, explicit contract validation, security scanning that catches AI errors before human review is required.

Three concrete platform changes when you design for all three personas, not just one

Designing for all three personas changes the platform in three concrete areas.

The first is API surface design. A platform designed for Human Developers can rely on human navigability: rich portals, detailed documentation, conversational support, contextual help. A platform that also serves AI Agents and Hybrid Collaborators needs those things plus clean machine-readable API surfaces. In practice, every platform capability needs two interfaces: a human interface (portal, documentation, golden path UI) and a machine interface (API with consistent contracts, explicit error semantics, predictable response structures). Most platforms built before 2024 have the first and lack the second. Adding the machine interface is not a rewrite — it is an instrumentation and documentation layer that the existing capability already needs.

The second is the permission model. A platform designed for Human Developers can implement role-based access control at the team or individual level. A platform that also serves AI Agents needs capability-scoped, time-bounded, blast-radius-limited permission grants. The permission model needs to answer the question: if this agent token is compromised or the agent malfunctions, what is the worst case? For a Human Developer token, the answer is bounded by what the human is likely to do. For an AI Agent token, the answer is bounded by what the agent is capable of doing in the time the token is valid.

The third is metrics and measurement. A platform designed for Human Developers measures adoption, cognitive load, deployment frequency, and lead time — all defined in terms of human-paced activity. Deployment frequency for an AI Agent running automated dependency updates is not comparable to deployment frequency for a Human Developer shipping features. Treating them as equivalent inflates the platform's apparent performance without improving human-facing outcomes. Signal Integrity requires separating the metric by persona. The Foundations Framework v3 includes per-persona scorecards (Appendix A) that track the four Signal Integrity properties separately for each user type.

What existing work covers the AI Agent persona — and where the three-persona model goes further

The closest published work to this three-persona model is the Microsoft Azure DevBlogs series on platform engineering for the agentic era. The March 2026 post describes how "modern agents can ingest natural language intent, reason over API schemas, generate and validate IaC, and apply changes directly via provider APIs — all while enforcing guardrails and approvals inline." Source: Platform Engineering for the Agentic AI Era, Microsoft Azure DevBlogs. Microsoft's framing is primarily about the AI Agent persona: what it needs from the platform, how to design API surfaces for agent consumption, how to constrain agent permissions. It is valuable and specific.

The Foundations Framework goes further in two ways. First, it adds the Hybrid Collaborator as a distinct persona. Most existing work treats the Hybrid Collaborator as a Human Developer with AI assistance, which misses the structural difference: the review work that the human does in a Hybrid Collaborator context is fundamentally different from the development work the human does alone. Second, it connects the three-persona model to the full measurement stack. Knowing that you have three user types is useful. Knowing how well the platform serves each type, with separate metrics per persona, is what makes the knowledge actionable.

Where to start: audit what AI Agents are already using your platform before designing for them

Most platform teams will not build for all three personas simultaneously. Start by identifying what AI Agents are already using your platform, formally or informally. In most organizations, CI/CD pipelines already incorporate AI-generated steps, automated dependency updates, and security scanner integrations. These are AI Agents. The question is not whether you have AI Agent users. It is whether your platform was designed with them in mind.

Audit your current permission model for AI Agent tokens. Ask: if this token were compromised, what is the blast radius? If the answer is "production write access," the permission model was designed for Human Developers and is too broad for AI Agents.

Identify the three most common Hybrid Collaborator workflows in your organization — the cases where a human and AI are working together most frequently. Assess what context the platform provides to support the human's review work. The gaps are the first Hybrid Collaborator design targets.

Build the machine-readable API surface for your most-used golden paths. This is the prerequisite for reliable AI Agent usage. Until it exists, AI Agents that try to use your platform will find workarounds that bypass the golden paths, which is the AI Agent equivalent of paved road non-compliance.

Frequently asked questions

What is the AI Agent persona in platform engineering, and why does it need different platform design?

The AI Agent is any automated system that interacts with the platform without continuous human oversight: a CI/CD integration that generates steps, an automated dependency update bot, a security scanner that proposes and implements remediation, or an agentic workflow chaining multiple operations. It needs machine-readable API surfaces rather than human-navigable portals, capability-scoped permission tokens with explicit blast radius limits rather than role-based access calibrated for human judgment, deterministic responses to deterministic inputs rather than the contextual flexibility human developers handle well, and explicit audit trails by default. Most platforms built before 2024 were designed entirely for human navigability. Adding AI Agent support requires an instrumentation and permission-model layer, not a full rewrite.

What is the Hybrid Collaborator, and how does the platform serve the review work rather than the generation work?

The Hybrid Collaborator is a human and an AI working together in real time — a developer using a coding assistant, a platform engineer using an AI agent to draft infrastructure code, a senior engineer supervising an automated deployment workflow. The human's primary work is not generation; it is evaluation: deciding whether the AI output is correct, appropriate, and safe. The platform supports this by surfacing the context that makes AI output evaluable — system intent, test coverage, deployment history, change failure rate for the affected service. A platform designed only for Human Developers shows the developer what they need to build. A platform designed for Hybrid Collaborators also shows the reviewer what they need to evaluate the AI output confidently.

How should DORA metrics be adjusted to account for AI Agent deployments?

Deployment frequency for an AI Agent running automated dependency updates is not comparable to deployment frequency for a Human Developer shipping features. Treating them as the same metric inflates the platform's apparent performance without reflecting human-facing delivery improvement. Signal Integrity requires separating the deployment frequency metric by persona: AI-initiated deployments (dependency updates, automated patches, agent-generated changes) tracked separately from engineer-initiated deployments (feature changes, bug fixes, intentional releases). The same separation applies to lead time and change failure rate. Per-persona scorecards make the distinction visible and prevent automated activity from masking human delivery performance.

Related reading

• Cognitive Absorption in platform engineering — the definitive reference — the absorption model that the three-persona framework extends: Cognitive Absorption is the third Foundations Framework pillar, and each persona needs the platform to absorb differently.
• The AI mirror effect in platform engineering — the AI Agent persona's effect on platform signal integrity: AI reflects what the platform does, accurately and at volume.
• The AI amplifier — what DORA 2025 is actually telling you about your platform — Signal Integrity and Delivery Reliability are two of the three platform properties that determine whether AI Agent usage amplifies strength or failure.
• Why DORA metrics are lying to you — signal integrity in platform engineering — per-persona DORA metric separation is required once AI Agents are generating deployments: this post explains why the separation matters.

---

The Foundations Framework v3.0 includes the full three-persona specification, the per-persona scorecards, and the Appendix D definition of what the framework does not cover. The Foundations Assessment includes a three-persona readiness evaluation as part of the Horizon phase. The free Platform Score will surface your platform's readiness for multi-persona usage across five dimensions.