Phase 12ADLC course

Phase 12. Operations: the agent on call

Vitrina is in production and taking money. Now it has to be operated: watch its health, catch incidents, respond, review afterward. On-call.

Of all the phases in the course, this is the one where the human constraint is crudest and most obvious: a human can't watch production around the clock without degrading at three in the morning. On-call exists precisely because a live engineer is finite — and an incident doesn't ask whether the person on duty got enough sleep. This article argues that an agent removes exactly this constraint, entirely, and leaves the human a narrow class of incidents the system hasn't seen before.

The human role today

An SRE, on-call engineer, DevOps: monitoring, alerts, the on-call schedule, incident detection and diagnosis, response, postmortems. Classically this is a pager going off at night, manual diagnosis under stress and fatigue, review afterward.

Break it down by the weaknesses this role compensates for. A human can't watch continuously — you need a schedule and rotation. A human under stress at night reasons worse — response time and error cost both rise. A human forgets the context of past incidents — you need runbooks and postmortems as external memory. Nearly the entire organization of on-call is a fight against the finiteness and degradation of a live on-duty person.

What we hand to the agent

The ops agent holds the on-call role. It watches metrics, logs, and traces, detects anomalies, diagnoses, fixes known issues per the runbook, escalates the unknown, writes the postmortem. And here the advantage isn't quantitative, it's qualitative: the agent is available 24/7 with no fatigue, no degradation on the night shift, no context loss between incidents. Three a.m. is no different from three p.m. for it.

The constraint itself changes shape. Human on-call is management of a finite attention resource. The agent has no such constraint at all. On-call stops being about "who isn't asleep" and becomes about "what to do with an incident we haven't seen before."

Agent architecture

Phase state-machine

Inputs

live production (phase 11), metrics/logs/traces, architecture + ADR (phase 5), the runbook.

The agent holds the role

Tools: observability (metrics, logs, traces); anomaly correlation; runbook-driven auto-remediation; rollback and scaling; a postmortem generator; an escalation mechanism.

Artifact

handled incidents + postmortems + change requests back into the backlog.

Handoff: postmortems and fix requests → Maintenance and Planning (phase 13 / phase 7). The postmortem artifact particularly benefits from an agent. Humans write it reluctantly, after the fact, and incompletely, weighed down by post-incident fatigue. The agent writes it in the moment, with full context of what happened, and immediately files a fix request into the backlog. The incident doesn't dissolve into "well, we put it out" — it turns into a task and an addition to the runbook.

Inputs: live production (phase 11), metrics/logs/traces, architecture + ADR (phase 5), the runbook.
Tools: observability (metrics, logs, traces); anomaly correlation; runbook-driven auto-remediation; rollback and scaling; a postmortem generator; an escalation mechanism.
Artifact: handled incidents + postmortems + change requests back into the backlog.
Trigger: an alert or an anomaly in production.
Handoff: postmortems and fix requests → Maintenance and Planning (phase 13 / phase 7).

The postmortem artifact particularly benefits from an agent. Humans write it reluctantly, after the fact, and incompletely, weighed down by post-incident fatigue. The agent writes it in the moment, with full context of what happened, and immediately files a fix request into the backlog. The incident doesn't dissolve into "well, we put it out" — it turns into a task and an addition to the runbook.

Where it breaks

Novel incidents outside the runbook. The agent is strong on known patterns — what's in the runbook, it handles faster and more precisely than a human. It's weaker on "we haven't seen this before": an incident with no precedent, where you need to understand a new cause rather than apply a ready recipe. Worse — autonomous remediation against a misidentified pattern can make things worse: the agent will confidently apply the wrong cure.

Blast radius of autonomous action. An agent that acts in production on its own and fast does damage faster than a human when the diagnosis is wrong. Response speed is both a strength and a damage multiplier. You need hard limits on what the agent can do on its own versus what requires escalation.

Accountability for production under load. Downtime that touches live users' money and data is a question of accountability. The agent responds; a person answers for the consequences.

What stays human

Escalation for novel incidents and the "big red button." A candidate for compression: the richer the runbook and the higher the trust in auto-remediation, the less often a human is needed — every novel incident that gets worked through enriches the runbook and gets handled autonomously next time. The durable core is the unprecedented incident and the authority to stop, and it's woven into governance (phase 14).

human remainder ≈ 19%

Provocation / thesis

On-call is a stand against a single constraint: a human can't watch production continuously and doesn't degrade at night. The agent removes exactly that constraint — entirely, not partially. The on-call schedule, the rotation, "who isn't asleep" — the whole organization of on-call was a protocol for managing the finiteness of a live engineer, and there's nothing left for it to manage. What's left is a narrow class of unprecedented incidents — the only thing that still justifies a live human in the operations loop, and only until the runbook absorbs them too.

Running case

Vitrina in this phase

At night, Vitrina's payment provider starts degrading — payment-confirmation latency climbs. The ops agent catches the anomaly by metric, correlates it with the provider's external status, recognizes a known pattern (it's in the runbook, added after the ADR in phase 5 about the payment flow's fragility), and switches to a backup provider via auto-remediation. It writes a postmortem and files a backlog task for retries with exponential backoff. All of this — at three in the morning, with no human woken up.

Now the boundary. If the degradation had been something other than a "known runbook pattern" — say, the provider silently processed payments twice while latency metrics stayed normal — the ops agent wouldn't have a ready recipe, and autonomous action on a wrong hypothesis would touch real user money. That's where escalation to the founder and the red button come in. The agent takes the known entirely; the unprecedented, when it touches money, is the sole human remainder. Artifact → Vitrina's incident + postmortem, a backlog task for phase 13.

In practice

How it actually works — engineering breakdowns

Standalone howto from practice, showing this phase on real code and a working artifact.

Event-tracker Two Ways: The Durability TradeoffTelemetry two ways: UDP fire-and-forget versus HTTP+PostgreSQL.
Async MCP Server with Job Queue: Why Polling, Not BlockingA job queue for long operations — operational resilience.

Building AI-driven delivery in-house?

Designing the ADLC loop: where the agent holds the role and where the human principal remains — for your team and product.

Email me

The transition engine

Next Move Engine — the system that takes a team to an autonomous delivery loop.

Next Move Engine →