Anthropic recently published a playbook for the AI-native SDLC, and it is the clearest description I have read of where software delivery is heading. It walks through the artifacts an agent produces at each stage, from an intent file through a spec, a plan, a pull request, and into production, with governance written as code in hooks, skills, and evals, and a human kept in the loop for the calls that need judgment. It is a genuinely good piece of work, and if you want the map of where this is going, start there.
One line in it stuck with me more than the rest. Anthropic is explicit that platform engineering owns the operational side of this shift. The playbook defines the process, and then hands the job of running that process across the organization to the platform team. I have spent the last stretch thinking about that second half, because it is the half we work on every day, and I want to walk through what it actually involves.
The way I think about it, there are two layers here that sit next to each other. Anthropic builds the agent itself: the model, the framework, the core logic for reasoning and iterating on feedback. Around that sits a second layer that takes a general agent and makes it work inside one specific organization, with that org’s context, its policies, and its orchestration. The playbook describes the first layer beautifully. The rest of this is about the second, stage by stage.
Turning any signal into an intent file #
The playbook starts from an intent file, and it can begin from an idea, a support ticket, or an alert. Producing that file consistently is an operational job. A signal like “fix the login bug” doesn’t name a service, so before an agent can do anything, the affected service and its owner have to be resolved and the signal enriched with that context. The platform layer is where a Slack request, a Zendesk ticket, a Sentry error, and a PagerDuty incident all become an intent file in the right repo through one mechanism, so the agent starts with context rather than a guess.
Routing a spec to the right owner #
In the design stage, the spec gets shaped by your security, compliance, and UX rules, and anything risky goes to the named policy owner. At scale, two things sit underneath that sentence. Knowing who the owner is comes from ownership data, and deciding whether a change is safe to hand off should run on rules the platform team wrote down rather than the model’s judgment on a given day. Something like: not a top-tier service, blast radius low, no open incidents, priority below critical, all passing or a human looks. The agent can explain the decision in plain language, and the platform is where the rule behind it lives and gets applied the same way every time.
Scoring blast radius from the dependency graph #
The playbook names blast radius as one of the conditions for running a change with less supervision, alongside a tight spec and good test coverage. Spec quality and coverage you can read inside the repo. Blast radius lives outside it, in which services depend on this one, who owns them, and what breaks if the change goes wrong. That is the platform’s map to hold, which is why scoring blast radius belongs in the layer that already knows the architecture, and it is the same score the earlier handoff decision uses.
Making the per-stage metrics visible #
The playbook names a metric for each stage, and getting those metrics in front of people is where the platform earns its keep. When every decision an agent or a person makes gets written back, you can see how much work went to agents versus people, which stage each item is sitting in, and where things stop moving. If items collect right after the agent opens a pull request, review is the bottleneck rather than coding, which is the playbook’s own premise showing up in your data. Code generation got fast, the human steps around it did not, and the platform is how you find where the slow part moved.
Two layers, next to each other #
Anthropic gave us the destination, the map, and the route through it. Running that route across a whole organization is a distinct job, and the playbook says as much when it puts platform engineering in charge of it. That layer catches signals from every tool, holds the architecture well enough to score risk, applies your policies at the moment the agent acts, routes decisions to the real owner, and shows you whether the whole thing is working. It is the same Claude agent in every company, and it behaves differently in each one because this surrounding layer differs.
That layer is what we build at Port, and I will get into the mechanics of it another time. For now the useful step is a simple one. Start with Anthropic’s guidance, get one team running the process end to end, and then ask your platform team the question the playbook is already pointing you toward: what do we need underneath to run this everywhere, not just here?