A real signal, not just a failed agent run.
→Day 2 is not
“the agent ran.”
Day 1 produces a branch, image, deployment or PR. Day 2 is the long loop after that: observe the real system, find the cause, make a bounded repair, prove the effect, and survive the next change.
Can it keep a real service healthy when the world changes?
We give Day 2 credit only when the evidence reaches beyond the factory’s own status page. A green job, healthy pod, passing canary or “fixed” ticket is only one signal. The user journey, data correctness, security boundary and recovery path still need their own oracle.
This is what “operations” means here.
Which service, dependency, tenant or data slice?
→A causal hypothesis plus a discriminating test.
→A bounded change with identity, approval and rollback.
→Independent technical, user and data postconditions.
→Prevent recurrence, or deliberately escalate.
Every change must
carry its own proof.
Don’t let the agent grade its own homework. Agents can investigate and propose; deterministic policy bounds the action; a separate witness checks the real target. This is an architecture proposal, not a claim that a reviewed product already closes the entire loop.
The problem: A rollout looks healthy, but an employee’s notebook can no longer obtain the expected Okta-backed API access.
Pin the target
Name exactly what is changing and what must remain true.
Artifact digest, cluster and namespace, affected notebook cohort, current identity mapping, and observation time.
If target, population or pre-state is ambiguous, stop before a write.
Which factories actually reach Day 2?
These labels describe the public evidence for the named factory—not what a sufficiently capable model might do with a custom integration.
Day 2 evidenced
The public record connects live signals to an operational action loop. This is still bounded—not a claim of whole-IT autonomy.
No public candidate is currently classified in this band.
Restarting a pod.
That may be a valid mitigation. It is not root-cause repair, and it does not prove the user journey or data stayed correct.
Deploying a rollback.
Code can revert while irreversible data, identity, queues, vendor calls or external side effects remain changed.
Independent closure.
The incident is understood, the bounded fix is authorized, the service is healthy, and recurrence risk is reduced or consciously accepted.