# The Agentic PDLC for DevOps and Platform Teams
Some of what this workload needs bills for existing, the model version is part of the environment, and the prompt is a deployable artefact.
6 min read · Intermediate · Lesson 7 of 9 in By role · Updated 2026-10-02 · By Akash Das
Canonical: https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/agentic-pdlc-for-devops/
> **In short.** In the agentic PDLC DevOps and platform make the system repeatable,
> observable and reversible. That means a landing zone with cost attributable per feature, one model
> gateway every call passes through, and environments with the model version pinned. It also means the
> evaluation harness as a check the merge cannot bypass, one flag per action, traces that redact, and
> rollbacks timed before anyone needs them.
**In this lesson** you'll learn:
- the platform team's eight steps, and why several of them must start in week one;
- the three things a normal operations stack does not watch, and how to add them;
- what "enforced" means for a platform, as distinct from "requested".
## Sound familiar?
- A test collection was stood up in week two, never wired in, and never switched off, until the bill.
- The same model call exists in four codebases, each with its own retry logic and none with a log.
- Nobody has ever timed how long it takes to switch the agent off.
What changes for an agentic workload is **when** the platform question has to be answered:
several of the costs and delays arrive before a single line of the feature is written.
*Some services bill for existing, not for use. The meter starts before a single line of the feature is written.*
## What changes for DevOps and platform?
**You stop treating a prompt as configuration, and start treating it as a deployable artefact.** An
agentic system has three things to deploy and roll back (the code, the prompt and the model version)
and three signals ordinary monitoring lacks: what a case costs, what the system did and why, and whether
its behaviour is drifting.
## Your eight steps
### P0 · Frame: the platform, first
**1 · Baseline.** The account, isolation and a tag scheme that makes cost attributable per feature, plus
a budget alarm, before any resource exists, because some services this workload uses bill for
existing rather than for use.
### P1 · Design & Spec
**2 · Access.** Model access is granted per model and **per region**, on request: a lead-time item for
day one. SkyWays lost six days because access existed in one region and the data had to stay in
another. Then put every call behind **one gateway** with a per-call log. **3 · Environments.** Make them
comparable, with the **model version pinned** in each manifest: for a probabilistic system the model is
part of the environment.
### P2 · Build & Prove
**4 · Pipeline.** The evaluation harness as a **required status check**, not a comment that can be clicked
past. **5 · Deploy.** One flag per action with four states (shadow, 5%, wider, all) and every trace
recording which flag state and prompt version produced it. [Shadow and cut-over](https://akash-coded.github.io/aws-bedrock-agentcore-strands/learn/shadow-mode-and-cutover/)
### P3 · Run & Learn: the phase you lead
**6 · Observe** the three signals: cost per case, a trace per consequential action, the output mix.
**7 · Protect**: the smallest identity that can do the job, an egress allowlist, and the injection suite on
every pull request. **8 · Recover**: throw every switch with a stopwatch before cut-over (SkyWays measured
40 seconds, 2 minutes, 3 minutes and 11 minutes) and cap loops and cost per case.
## What is yours, and what is not
| Yours to own | Not yours |
| --- | --- |
| The landing zone and the per-feature cost tags | The acceptance bar: you make the gate unarguable; you do not set it |
| The model gateway and its per-call log | Prompt content: you version, deploy and roll it back; you do not write it |
| The pipeline, with the harness as a required check | Which slices exist and what a mistake costs: the business's input to your caps |
| Three deployable artefacts and three rollback paths | The behaviour, release and expansion gates: you supply the evidence |
| The enforced controls: role scope, egress, caps in signatures; the kill switch | |
## How to use a model in this role
Use a model where there is **a schema to be right against and a cheap way to check**. It is strong at
infrastructure templates, workflow files, policy shapes and first drafts of scripts, and confidently
wrong about your account boundaries, your regions, your quotas and what a permission actually reaches.
Let the model write the change and a machine judge it (a linter, a diff, a plan output, an access
analyser), then read the diff rather than the prose.
## Where you'll use it
- **In week one**: the account, the tags, the budget alarm and the access requests.
- **Before the first feature branch**: the gateway and the harness as a required check.
- **Before cut-over, and after every incident**: the rollback rehearsal.
## Why it matters
Most of the surprises in an agentic programme land on the platform: the bill with no traffic change,
the quality drop with no deploy, the access that takes a week, the rollback nobody has tried. Each has a
platform control, and each control is cheapest before it is needed.
## Try it
Quality dropped on Tuesday. Nobody deployed. **What should the platform already be able to tell you,
and from where?**
Show the answer
**Which model and prompt version answered every call, and when that changed.** The gateway's per-call
log should show whether calls were routed to a different model (a failover to a smaller one, say) or
whether the provider updated the model behind an alias; the pinned version in the environment manifest
shows what *should* be answering. If neither changed, look at the inputs and retrieved data for drift.
Without the per-call log, the only evidence is the complaint.