The agentic PDLC for DevOps and platform teams

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.

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

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#

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.

Key takeaways#

1. Start the platform in week one: tags, budget, access requests, then one gateway with a per-call log.
2. Three artefacts, three rollbacks (code, prompt, model version) and a flag per action.
3. Three new signals (cost per case, trace, output mix) and rollbacks timed before cut-over.

FAQ#

What is LLMOps?#

The operational practice of running applications built on large language models: managing model access and versions, routing and caching calls, deploying prompts as artefacts, evaluating changes before they ship, tracing what the system did, monitoring cost and drift, and rolling back quickly.

Why do AI agents need a model gateway?#

Because without one, model calls scatter across codebases with different retries, no shared log and no single place to set routing, budgets or fallbacks. A gateway makes every call visible per case, which is what turns a surprise bill or a quality drop into a diagnosis.

Should prompts be version-controlled?#

Yes. A prompt changes behaviour as much as code does, so it is versioned, reviewed, evaluated by the harness, deployed behind a flag and rolled back like code, and every trace records which version produced each response.

What is the difference between MLOps and LLMOps?#

MLOps grew up around training and serving your own models: data pipelines, training runs, model registries. LLMOps is mostly about operating applications on top of models someone else trains: prompts, routing, caching, evaluation, cost and drift.

Apply it in your role#

Across the enterprise. A platform team provides the gateway, the landing zone, the harness template and the trace for every AI product, and teams keep the freedom to choose their own editors.

The ten-minute workflow. A platform plan, as infrastructure as code:

Write an infrastructure-as-code plan (CDK or CloudFormation) for an AI feature's platform: a cost tag
per feature, a budget alarm, model access in <regions>, a gateway that logs every call (model, tokens,
latency, feature, prompt version) and a feature flag per action with four states. List everything that
needs an access request with a lead time, and who it goes to.

Sources and credits#