Term FF-002
Three persona platform user
The platform user is no longer one thing.
The three persona platform user taxonomy formalizes who uses your Internal Developer Platform in 2026: human developers, AI agents, and hybrid collaborators. Every Foundations Framework pillar designs for all three from day one.
What it is
A taxonomy, not a metaphor
The three persona platform user is a formal taxonomy introduced in the Foundations Framework by Mat Caniglia. It names the three distinct entities that interact with an Internal Developer Platform today and defines what each entity needs from the platform, what constitutes a platform failure for each, and what observability looks like for each.
Most platform engineering frameworks assume one user: the human developer. That assumption was reasonable in 2020. It is not reasonable in 2026. AI coding assistants, autonomous deployment agents, and hybrid human-AI workflows are now standard configurations in engineering teams. A platform designed only for human developers is a platform that will create friction, observability gaps, and risk surfaces the team cannot see.
The taxonomy is not decorative. Each persona drives different design decisions at the pillar level. Security and Compliance by Default looks different when one of your platform users cannot read a policy doc. Delivery Reliability looks different when one of your deployers does not sleep. Cognitive Absorption has a different meaning for an agent that processes text rather than experiences flow states.
Authored in the Foundations Framework, this taxonomy is the first formal treatment in platform engineering of the design contract an IDP owes to non-human platform users. The practical consequence is that every Foundations engagement assesses platform readiness against all three personas, not just the human developer.
The three personas
What each persona needs, and what breaks for each
Human developer
Who they are
The engineer who reads docs, follows golden paths, attends retrospectives, and files tickets. They bring context and judgment. They get tired, distracted, and context-switched.
Their platform contract
Reduced cognitive load. Fast feedback loops. A paved road that does not require expertise to use. Onboarding that does not take weeks.
Common failure modes
Documentation debt. Broken golden paths. High context switch cost from poorly designed tooling. Long CI feedback cycles.
AI agent
Who they are
The autonomous system that opens pull requests at three in the morning, runs test suites, triggers deployments, and sometimes does all three in a single workflow no human reviewed.
Their platform contract
Machine-readable contracts. Deterministic interfaces. Observability that can distinguish agent-originated changes from human changes. Review gates appropriate to the risk of autonomous action.
Common failure modes
No observability on agent-originated changes. Review gates designed for humans that agents can bypass. Blast radius of a bad agent deploy indistinguishable from a bad human deploy.
Hybrid collaborator
Who they are
A human working alongside an AI pair on the same task: reviewing AI-generated code, directing agent workflows, or co-authoring architecture documents. The most common configuration in engineering teams today.
Their platform contract
Context engineering compatible with agent-assisted workflows. Golden paths that work for both human intuition and agent pattern matching. Observability that surfaces the provenance of each change regardless of who or what originated it.
Common failure modes
Platforms designed for pure human use that create friction when agents are involved. Context that lives in human memory but not in machine-readable form. Paved roads that agents cannot follow because they require implicit knowledge.
Why it matters
AI agent platform failure modes are invisible to human-only monitoring
When an engineering team adopts AI coding assistants and autonomous deployment agents without updating their platform design, they introduce failure modes that their existing monitoring cannot see. An AI agent that merges a pull request at three in the morning is indistinguishable from a human merge in a system not instrumented to track provenance.
State of Platform Engineering Vol 4 (2026) reports that 29.6 percent of platform teams measure nothing. That number was calculated before widespread AI agent adoption. The risk of instrumentation gaps grows proportionally with the percentage of changes originating from agents.
For a VP Engineering managing a platform that supports 50 developers, the second persona creates a specific obligation: the platform must know when an agent made a change that would otherwise require human judgment. An agent that bypasses a manual approval gate is not being clever. It is following instructions on a platform that did not design its review gates for the second persona.
The three persona taxonomy creates a forcing function. When a team acknowledges that AI agents are platform users, they must answer: what is the agent's contract with the platform? What observability do we have on agent activity? What review gates apply to agent-originated changes? The taxonomy makes those questions unavoidable.
In practice
What single-persona and three-persona platform design look like
A platform designed for persona one only has a deployment portal with a web UI, a manual approval step that sends a Slack message to the on-call engineer, and onboarding documentation written in Confluence. The golden path works for a human who can read, click, and wait. An AI agent trying to deploy must either be given credentials to click the UI (fragile, unaudited) or bypass the portal entirely via a different path (unseen, unapproved).
A platform designed for all three personas has the same deployment portal for humans, an API endpoint with a machine-readable contract for agents, and pipeline provenance tags that label every change with its origin. The approval step evaluates risk level rather than requiring a human: low-risk changes from trusted agents can proceed automatically. High-risk changes or unrecognized agent signatures surface to human review. The blast radius of an agent mistake is bounded by the same controls that bound a human mistake.
The second design is not more complex for human developers. It is the same experience with additional contract surface for the non-human users. That is what the taxonomy enforces: the third persona does not replace the first. It extends the platform's surface area to cover all the entities that actually use it.
How Clouditive uses it
Designed into every pillar from day one
The Foundations Assessment includes an AI readiness score across all three personas. The diagnostic questions differ by persona. Human developer readiness covers cognitive load, onboarding velocity, and golden path coverage. AI agent readiness covers observability instrumentation, review gate design, and blast radius controls. Hybrid collaborator readiness covers context engineering maturity and paved road compatibility with agent-assisted workflows.
During the Forge phase, every capability delivered is validated against all three personas. A CI pipeline that works well for human developers but creates a bypass surface for agents is not a complete delivery. A deployment system observable to human operators but opaque to automated incident detection is not complete observability.
The four AI metrics Clouditive instruments on every engagement (throughput quality coupling, cognitive offload, AI agent observability, decision quality preservation) each have per-persona breakdowns. Agent observability, in particular, is a signal unique to the second and third personas.
Related pillar page
The AI agent platform page covers the second persona in depth, including agent failure modes, observability requirements, and what the platform owes the agent.
Read the AI agent platform pillarCommon questions
Three persona platform user: answers to specific questions
Q: We do not have autonomous AI agents yet. Does the second persona still apply?
Yes, for two reasons. First, the timeline between "no agents" and "agents in production" is often shorter than the time needed to redesign platform contracts after the fact. Designing for the second persona now costs less than retrofitting after agents are already creating incidents. Second, AI coding assistants that push commits and open PRs are already a form of the second persona — they produce artifacts that enter your delivery system. Tracking their provenance is not a future concern.
Q: How do you give the AI agent the right level of platform access without creating a security risk?
The principle is least-privilege scoped to the agent's declared workflow, combined with blast radius controls. An agent that deploys services should have access to the deployment API for the specific services it manages, not admin access to the whole platform. Every agent action should be logged with provenance. The review gate applies to agent-originated changes as a risk-based function: low-risk changes proceed automatically, high-risk ones surface for human review. Security by Default as a Foundations Framework pillar covers this design pattern explicitly.
Q: Is the hybrid collaborator persona just the human developer persona with AI tools?
No. The hybrid collaborator produces a distinct failure mode that neither the human developer nor the AI agent produces alone: they make decisions that blend human judgment and AI-generated content in ways that are hard to audit. When a human reviews and approves AI-generated code without fully understanding it, the accountability for that code is ambiguous. The platform's contract with the hybrid collaborator must make provenance clear: what was generated, what was reviewed, and who approved. That is a different design requirement than either pure human or pure agent interactions require.
Assess your platform for all three personas
The Foundations Assessment includes AI readiness scoring across the three persona taxonomy.
Four to six weeks. Maturity radar. DORA baseline. AI readiness score. 90 day roadmap.