The 2026 Event That Names the Shift
DevOpsCon London 2026 / Platform Engineering Week ran May 11-15, 2026 across Park Plaza Victoria and the QEII Convention Centre, blending DevOpsCon, the API Conference, and MLcon under a single Platform Engineering Week banner. The conference program is the first major platform-engineering event of 2026 to explicitly position “agentic developer platforms” as the 2026 successor to the DevOps tool stack: AI agents as first-class platform citizens with RBAC, quotas, and policies, integrated across the software lifecycle from intent-to-infrastructure through autonomous decommissioning of zombie resources.
The framing matters because it is the first to put a name on the shift that has been visible across the 2026 disclosures, customer adoption telemetry, and platform-team operating-model conversations. The shift is from DevOps tools — the things humans use to operate infrastructure — to agentic developer platforms — the things agents use to operate infrastructure, with humans in the loop only where judgment matters.
Three threads of the conference program are particularly useful as anchors for the 2026 platform-engineering operating model.
Agents as first-class platform citizens. The conference framing treats AI agents the same way platforms have historically treated users, services, and applications — as entities with identities, RBAC scopes, quotas, and policy-enforcement boundaries. An agent is not a script. It is a tenant. The platform-engineering work is to give agents the same first-class treatment infrastructure already gives every other production tenant.
The 12 foundational pillars extend to AI. The conference program’s reframing of the canonical 12 platform-engineering pillars (infrastructure automation, CI/CD management, security, observability, API governance, and the rest) now explicitly includes AI-model deployment, agent-orchestration, and model-context-protocol surface management. The pillars do not change; the scope of each pillar expands to cover the agent tenants the platform now hosts.
Intent-to-infrastructure through autonomous decommissioning. The lifecycle the conference program describes is end-to-end: an intent expressed in natural language becomes an infrastructure plan, becomes a provisioned resource, becomes a monitored running workload, becomes an idle resource flagged for cleanup, becomes a decommissioned resource — all through agent action, with capability-tier governance at every transition.
Why Capability Tiers Are the Runtime Expression of “Agents as First-Class Citizens”
The conference framing — “agents as first-class platform citizens with RBAC, quotas, and policies” — is the marketing surface of a much more specific operational primitive. The operational primitive is the capability-tier model: every agent action belongs to one of three tiers, and the governance model is per-tier, not per-agent.
| Tier | What it covers | Approval model |
|---|---|---|
| Observe | Read-only audits, cost analysis, security scans, drift detection, inventory | Auto-executed; fully audited |
| Operate | Deployments, tagging, resource changes, policy application, remediation PRs | Auto-executed for reversible / scoped changes; approval gates for anything irreversible or out-of-policy |
| Administer | Organization-level changes, billing, IAM, role management, approval policy itself | Always requires explicit approval; separation-of-duties enforced |
The three tiers map onto the three operational realities that make agents-as-first-class-citizens deployable in enterprises with real compliance requirements.
- Observe-tier actions are the baseline. They run continuously, they cost almost nothing relative to a human review pass, and they produce the inventory and finding stream that drives every higher-tier decision. An agent in Observe is doing the same shape of work a human SRE does when they read a dashboard — except continuously, at every scope, across every account, with no fatigue and no skipped read.
- Operate-tier actions are the productivity unit. They are where the labor offset happens. A pre-authorized scope for rightsizing, for waste cleanup, for remediation PR generation, for tag application, for lifecycle moves, for connection drains, for blue-green rotations. Each is a discrete operation with a discrete blast radius. Each is auditable. Each is reversible or scoped.
- Administer-tier actions are the explicit-approval surface. Organization-level changes, IAM, billing, approval-policy edits. Humans are in the loop here every time. The agent’s job is not to take the action but to surface the work, propose the change, capture the justification, and produce the audit-trail entry once approval is granted.
The capability-tier model is the runtime expression of the conference framing. It is what makes RBAC, quotas, and approval policy enforceable for agents in production, rather than aspirational in a slide.
See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →
What “Active Operational Layer” Means at the Conference Program Level
The conference program’s framing of “platforms as agentic developer platforms” is the same architectural shape the active operational layer describes: not a new tool category, not a smarter dashboard, not a copilot for the platform team. A layer that runs the infrastructure.
The active operational layer differs from the passive observability and cost layer in three concrete ways.
1. Action by default, not surfacing for human action. The passive layer’s value proposition is “we will surface this for a human to act on.” The active layer’s value proposition is “we will act on this, with capability-tier governance and an immutable audit trail.” The unit of value is the operation completed, not the alert generated.
2. Coordination across pillars by default, not federation of single-purpose tools. The passive layer has separate tools for cost, security, observability, and deployment, each with a separate dashboard, separate alerting, separate context. The active layer has a coordinated team of specialized agents reading from a shared context substrate. When the SRE agent investigates an incident, the cost-agent’s recent rightsizing history, the resource-agent’s tag changes, the security-agent’s drift findings, and the deployment-agent’s release log are all in the investigation context.
3. Governance per action, not perimeter. The passive layer’s governance model is access control — who can read the dashboard, who can press the button. The active layer’s governance model is per-action capability tiers — Observe runs by default, Operate gates on pre-authorized scope, Administer requires explicit approval. The perimeter is everywhere; the governance is per-action.
The agentic-developer-platform framing names what 2026 platform engineering looks like. The active operational layer is the architectural shape that makes it real.
The Resource-Operations and Deployment Pillars Carry Most of the Agentic-Platform-Engineering Work
Across the conference program’s session list, the lion’s share of the agentic-platform-engineering work falls into two operational pillars: resource-operations and deployment. The security and cost pillars are essential, but they are not the load-bearing parts of the conference’s “intent-to-infrastructure through autonomous decommissioning” lifecycle.
- Resource-operations agent. Owns the inventory of everything the platform hosts — accounts, projects, workloads, agents-as-tenants, model endpoints, MCP surfaces. Owns tagging, quotas, lifecycle policy, and the zombie-resource decommissioning pass. The agentic-platform-engineering value proposition lives or dies on the quality of the inventory: an agent that doesn’t know what exists cannot operate on it.
- Deployment agent. Owns the release path from intent to running workload. Carries the blue-green rotation primitive, the canary rollout primitive, the rollback primitive, the connection-drain primitive. Surfaces stuck deployments as Operate-tier remediation candidates. Produces the audit-trail entry for every release.
The two pillars work as a coordinated team. A resource-operations agent that maintains the inventory but cannot drive the lifecycle transitions is a CMDB with prettier output. A deployment agent that drives transitions without the resource-operations agent’s inventory is operating blind.
How IAN Helps: The Agentic-Platform-Engineering Operating Model on the Active Operational Layer
IAN is the AI DevOps team for cloud infrastructure, delivered as a coordinated team of specialized agents on the active operational layer. The DevOpsCon London 2026 framing of “agentic developer platforms” is the same operating model IAN has been building toward since the start of 2026.
- Resource-operations agent inventory. A live inventory of every account, every workload, every tag, every quota, every agent-as-tenant, every model endpoint, every MCP surface — across every connected AWS / GCP / Azure account. The inventory is queryable on the MCP surface the rest of the platform team uses.
- Deployment agent release path. The blue-green rotation primitive, the canary rollout primitive, the rollback primitive, the connection-drain primitive — all wired to the inventory the resource-operations agent maintains.
- Capability-tier governance on every action. Observe-tier inventory scans, lifecycle-flag passes, and zombie-resource detection run automatically. Operate-tier remediations (decommissioning a flagged resource, applying a quota, executing a blue-green rotation) require pre-authorization once. Administer-tier actions (account-level policy edits, RBAC-scope changes for agent tenants, approval-policy edits) require explicit human approval with separation-of-duties.
- Shared orchestration through Hermes. The five IAN agents read from a shared context substrate. The deployment-agent’s release log feeds the resource-operations-agent’s lifecycle pass. The security-agent’s drift findings feed the resource-operations-agent’s exception-tracking. The cross-pillar context is the active operational layer.
- BYOK on model keys. Customers bring their own Anthropic / OpenAI keys. The agent layer does not see lifecycle moves as an LLM-call-markup opportunity. Pricing is usage-based on orchestration actions, with a monthly minimum.
- Immutable audit trail. Every inventory change, every lifecycle move, every quota grant, every RBAC change, every approval, every exception lands in the customer’s per-tenant audit-trail store.
- MCP-first interface. The agent team is reachable from Claude, Claude Code, Cursor, and any MCP-compatible client. Engineers do not learn a new UI; they speak to the platform from the conversational AI clients they already use.
The Three-Phase Rollout
Phase 1 — Observe the agentic-platform-engineering posture across the cloud. Run the resource-operations agent in Observe mode against the connected accounts. Produce the inventory of accounts, workloads, agents-as-tenants, model endpoints, MCP surfaces, and zombie-resource candidates. Produce the per-pillar finding stream and the per-pillar baseline. Two-to-four weeks.
Phase 2 — Codify the lifecycle policy and promote to Operate-tier. Pre-authorize the Operate-tier scope for the resource-operations agent (lifecycle moves, quota application, tag enforcement, zombie-resource decommissioning) and the deployment agent (blue-green rotations, canary rollouts, rollback paths). Codify the agent-tenant RBAC model and quota model. Codify the exception path with explicit justification and audit-trail capture. Two-to-three months.
Phase 3 — Cross the resource / deployment / cost agent loop. Inventory changes feed the cost-agent’s rightsizing pass. Lifecycle moves feed the security-agent’s drift baseline. Deployment-agent release events feed the resource-operations-agent’s tag and quota application. The team coordinates as a team. The agentic-platform-engineering operating model is the active operational layer.
DevOpsCon London 2026’s positioning of “agentic developer platforms” is the conference-program naming of the shift that has been visible across the 2026 disclosure window, the customer-adoption telemetry, and the platform-team operating-model conversations. The capability-tier model is the runtime expression of “agents as first-class citizens.” The active operational layer is what makes RBAC, quotas, and approval policy enforceable for agents in production. The team-of-specialized-agents shape is what carries it.
Next step: talk to the team
30 minutes. We'll look at your cloud together and scope what we'd take off your plate — see pricing.