Platform engineering

AI agent platform engineering. The third user of your platform.

AI agents open pull requests at three in the morning. They have never read your documentation. They do not get tired, but they also do not have judgment.

They are the second persona in the three persona platform user taxonomy, and most platforms were not designed with them in mind. This page covers their failure modes, the observability your platform needs, and what the platform owes the agent.

The three persona platform user

Understanding the AI agent as a platform user

The three persona platform user taxonomy introduced by Mat Caniglia in the Foundations Framework formalizes three distinct users of an Internal Developer Platform: the human developer, the AI agent, and the hybrid collaborator. Each has different needs, different failure modes, and a different contract with the platform.

Most platforms were designed entirely around the first persona. That was reasonable in 2020. It is not reasonable in 2026, when autonomous AI agents are making production changes in a growing percentage of engineering teams.

The AI agent as platform user is not a future concern. State of Platform Engineering Vol 4 (2026) documents that autonomous coding and deployment agents are in active use in a material percentage of surveyed organizations. The question is not whether to design for the AI agent persona. It is whether to design for it deliberately or discover its failure modes through production incidents.

Persona 001

Human developer

Reads docs. Follows golden paths. Makes judgment calls. Gets tired. Needs cognitive load reduction.

Persona 002 (this page)

AI agent

Opens PRs at 3am. Never reads docs. Makes no judgment calls. Never gets tired. Needs machine-readable contracts.

Persona 003

Hybrid collaborator

Human directing an AI pair. Most common 2026 configuration. Needs golden paths that work for both.

Full three persona taxonomy definition

AI agent failure modes

What goes wrong when the platform was not designed for agents

These failure modes are observed patterns, not theoretical risks. They surface on platforms that had strong human developer design but were not updated when AI agents were introduced.

Plausible correctness at scale

High

AI agents generate code that looks correct and tests that validate it. Those tests may validate the agent's own assumptions rather than the actual system requirements. At human commit volume, a senior engineer review catches the gap. At AI agent commit volume, the review queue exceeds human capacity before the gap is caught.

Policy bypass through automation

Critical

Security and compliance gates designed for human review can be bypassed by agents that satisfy the form of the gate without its intent. An agent that generates a security review comment on its own pull request satisfies the "review required" gate. A platform that treats human review and automated approval as equivalent has a surface the agent can traverse.

Blast radius amplification

High

A human developer who deploys a bad change does so at human speed. An AI agent that deploys a bad change does so at agent speed, potentially across multiple services or environments before detection. Platforms designed around human deployment cadence do not have the rollback automation to match agent deployment cadence.

Context drift in long-running workflows

Medium

AI agents operating on multi-step workflows accumulate context that may become stale between steps. An agent that designs an architecture change in step one and implements it in step five may be implementing against a system state that has changed in the intervening steps. Human engineers notice context drift intuitively. Agents do not.

Invisible provenance in incident investigation

Medium

When an incident is traced to a recent change, the investigation assumes the change was made by a human who can be interviewed about their intent. An agent-originated change has no intent beyond its task specification. Incident investigation workflows that rely on developer memory and intent are blocked by agent-originated incidents.

Dependency pattern amplification

Medium

AI agents trained on existing codebases amplify the dependency patterns they have learned. If an existing codebase has a problematic dependency pattern, an agent contributing to it will reinforce that pattern across more of the codebase before the pattern is identified as problematic. Technical debt accumulates at agent speed.

AI agent observability

Three signals your platform must instrument

AI agent observability is one of the four AI metrics Clouditive instruments on every Foundations engagement. It addresses the most basic question about AI adoption: can you see what your agents are doing?

State of Platform Engineering Vol 4 found that 29.6 percent of platform teams measure nothing. That number predates widespread AI agent adoption. A platform that measures nothing cannot distinguish human activity from agent activity, cannot trace incidents to their origin, and cannot assess whether agent review rates match the risk of autonomous changes.

Agent deploy percentage

The percentage of production deploys that originated from AI agent commits versus human commits. A platform without this signal does not know what proportion of its production changes come from autonomous sources.

Target behavior

Track per deploy. Alert if agent percentage exceeds threshold without corresponding review rate.

Agent incident correlation rate

The percentage of production incidents traceable to agent-originated changes. Compared against the agent deploy percentage to determine whether agents have a higher or lower incident rate than humans.

Target behavior

Compare agent incident rate against human baseline. Flag statistically significant divergence.

Agent PR review rate differential

The difference between the review thoroughness on agent-opened pull requests versus human-opened pull requests. If agents receive systematically less review, the review gate is not functioning as designed.

Target behavior

Track review comment density and review time per PR. Compare agent versus human distributions.

Full AI metrics framework

What the platform owes the agent

The agent platform contract

The platform contract for human developers is well established: fast feedback loops, clear error messages, reliable CI, documented golden paths. The platform contract for AI agents is less established. Most organizations have not articulated it.

The absence of an explicit agent contract does not mean the contract does not exist. It means it is implicit, inconsistent, and unenforced. Agents find their own paths through the platform, some correct and some exploiting ambiguity in the design. The platform team discovers the result in incident reports.

The Foundations Framework defines five elements of the agent platform contract. Each addresses one of the failure modes that implicit contracts produce.

01

Machine-readable interfaces

The agent cannot read your wiki. It can read your OpenAPI spec, your Terraform module documentation, and your ADR history if it is structured. Every platform interface that humans navigate through implicit knowledge needs a machine-readable equivalent for agent use.

02

Deterministic golden paths

Golden paths designed for human intuition rely on judgment at decision points. Agents need deterministic paths: if condition X then action Y, with no ambiguous decision points. The paved road for an agent is a pipeline with explicit branching conditions, not a well-documented wiki entry.

03

Proportional review gates

Review gates calibrated to human commit volume are undersized for agent commit volume. The platform must support tiered review requirements: high-risk changes (production deploys, security-sensitive modifications) require human review regardless of origin. Low-risk changes (documentation, test additions) may accept automated review.

04

Blast radius controls

Deployment controls that limit the blast radius of a bad change need to operate at agent deployment speed, not human deployment speed. Circuit breakers, canary deployment automation, and automated rollback triggers are not optional on a platform with agent deployers.

05

Change provenance tracking

Every commit, pull request, and deployment must carry metadata identifying its origin. Human, agent, or specific agent type. That metadata must be queryable in incident investigation tools, auditable for compliance, and visible in deployment dashboards.

Sources

  • State of Platform Engineering Vol 4 2026. PlatformEngineering.org. 29.6 percent of platform teams measure nothing.
  • DORA 2026 State of DevOps Report. AI mirror effect. dora.dev
  • Foundations Framework. Mat Caniglia. Clouditive. Three persona platform user taxonomy.

Design your platform for all three users

The Foundations Assessment scores your platform across the three persona taxonomy, including AI agent readiness.

Four to six weeks. Maturity radar. DORA baseline. AI readiness score. 90 day roadmap.