Upcoming Workshop: Citizen Developer Agentic Software Factory on AWS
Register Here!
“An Agentic Development Platform (ADP) is a platform built and operated by the platform engineering team that enables collaborative software development between engineers and AI agents.”platformengineering.org
86%
report platform engineering is essential to realizing AI's business value (platformengineering.org)
What the agentic development platform model gets right
Internal Developer Platform
Agentic Development Platform
A human triggers work and reviews output
Supports a spectrum from human-triggered to autonomous, at levels you set
Golden paths as portals and forms
Golden paths as typed, queryable interfaces both humans and agents consume
Context lives in wikis, repos, and heads
Context is structured data: a live graph of resources, contracts, cost, ownership
Governance by review meeting
Governance as policy on the graph: schema checks, ABAC, blast radius, audit
The model keeps deterministic paths in place and keeps the platform team as the owner, and platformengineering.org advises teams to get the IDP right before they attempt an ADP. What the model leaves to you is how an agent's change reaches production through the same controls as every other change.
What changes when agents act on infrastructure
An agent that writes code leaves a pull request for a person to review. An agent that changes infrastructure needs the controls built into the path, the same ones every other source of change goes through.
Identity
Every agent acts under its own scoped Massdriver identity, never a shared or broad cloud credential, and the audit log names it like any teammate.
How agent permissions work →Policy
Schema validation and policy checks (SOC2, HIPAA, CIS) run before every change, the same checks a change from a person gets.
Blast radius
Attribute-based access control on environment, team, and blast_radius bounds what any actor can touch. Disposable environments give agents room to iterate away from shared infrastructure.
Approval
Proposing a change and deploying it are separate permissions, so an agent can propose a production change while a person with the approval role decides.
How agent changes stay safe →Deterministic execution
Agents propose. The system executes from the approved catalog the same way every time, with ephemeral pipelines and deletion protection.
Context and audit
The Context Engine is a live graph of what is deployed, connected, owned, and permitted. Deployment history and audit events are part of it, so every agent action is attributable, diffable, and reversible.
How far agents run is a policy decision.
The ADP model describes autonomy levels from human-in-the-loop assistants to self-initiating agents. In Massdriver the boundary is policy: start with agents proposing and people approving, then widen scope by changing grants and blast radius attributes. The controls stay the same as the scope widens.
- Start supervised. Agents design and propose; changes land as diffable bundle configuration for human review.
- Grant autonomy by attribute. Let agents self-serve in dev and preview environments while prod stays approval-gated.
- Contain the blast radius. Disposable, isolated environments give agents room to iterate against real feedback without reaching shared infrastructure.
- Review after the fact. Deterministic execution writes the audit trail as agents work, so every widened grant stays inspectable and every change can be traced back and rolled back.
One governed path, for agents and every other change.
Agents, developers, CI, and business workflows change your cloud through the same catalog, policy, approvals, and audit trail. Give us an hour with your platform and security leads and see it on your own infrastructure within a day.