Diagnose, plan, implement and review with bounded context.
Operating model · reference architecture
Agentic SRE
AI in the delivery loop — without losing control of it.
I help Platform Engineering and SRE teams adopt AI-assisted operations without losing control of risk, quality or accountability. The hard part is never getting an agent to write a change — it is what an organization has to sign off: what the agent may touch, which checks are deterministic, who owns the merge, and how you prove the service actually improved.
This reference implementation is exercised in a private multi-service environment and demonstrates an adaptable operating model rather than a customer-specific deployment.
Reduce operational toilConvert recurring signals and manual handoffs into structured engineering work.
Keep delivery safeKeep agent-generated changes bounded by CI, policy, review and human approval.
Govern AI adoptionMake access, evidence, decisions and outcomes visible and accountable.
Issues, contracts, CI and policy gates bound the work.
High-impact changes stay reviewable and explicitly approved.
The operational problem
Monitoring detects symptoms. It does not automatically create a safe path to resolution.
The hard problem is the manual handoff between alert, context, owner, change, review, deployment and proof that the service actually improved.
Alert
Investigate manually
Search docs
Find owner
Implement
Test
Deploy
Verify
Context switching, tribal knowledge, inconsistent quality and slow feedback loops.
The operating model
Signal → verified change
One work item travels from an operational signal to a reviewed, approved and measured engineering outcome — through a defined, governed path.
Representative example
A recurring integration error becomes one governed remediation loop.
Telemetry and repository context are correlated into a structured issue, a change is prepared, validation and review run against it, and service indicators are checked to see whether they move back toward target.
- Signal
Alerts, metrics, logs, traces and scheduled checks.
- Evidence
Telemetry, repository context and runbook hints are correlated.
- Structured Issue
Ambiguous signal becomes scoped work with constraints.
- Agent Plan
Remediation plan and verification path are proposed.
- Pull Request
Change is prepared as reviewable code and evidence.
- CI
Static checks, tests and policy gates run deterministically.
- AI Review
Specialist reviewers critique technical, business and risk impact.
- Human Approval
Engineer reviews evidence and owns the decision.
- SLO Verified
Observability confirms whether the outcome improved.
Probabilistic intelligence
Agents propose the best next actions.
- Diagnoseunderstand what is happening
- Planpropose safe and effective steps
- Implementgenerate code and configuration changes
- Reviewcritique quality, risks and tests
Deterministic platform rails
Guardrails make every change reviewable.
- Issue contractsstructured scope and acceptance criteria
- Testsautomated verification before merge
- Policy gatessecurity, compliance and quality checks
- Audit trailissue, PR, commit and review history
- Observabilitymeasure impact and close the loop
Adoption path
Adapting this to a platform that already has users, on-call and a change process.
The architecture below shows how the controls are implemented and exercised. The real decision is which controls your organization needs, and in what order.
Candidate workflows, prioritized, with the risk of each made explicit.
What agents may touch, which gates are deterministic and which advisory, where human approval sits, and what happens on rollback.
A single use case in your stack, with an agreed measure of whether it worked.
Reusable rails other teams can adopt, operated by your engineers.
Design principles: agents propose changes as pull requests, while the merge decision remains explicitly human-owned; deterministic checks stay separate from advisory AI review; and tool access is scoped explicitly rather than inherited.
Technical deep dive
A governed AI delivery graph, not a disconnected set of tools.
The graph shows how triggers, orchestration, scoped tools, coding agents, CI gates, human approval and runtime feedback connect into one auditable control loop.
Triggers
Orchestration
MCP boundary
Context / agents
Delivery
Feedback
Event remediation pathMobile view of the selected graph route.
- 1Observability signalSignal starts triage, not an automatic change.
- 2Orchestration runtimeNormalizes work and creates run context.
- 3MCP scoped accessConstrains tool access through explicit boundaries.
- 4Specialized agentsPlan, implement or review within the governed loop.
- 5Pull requestChange becomes reviewable code and evidence.
- 6CI Control PlaneDeterministic checks bound probabilistic output.
- 7Human approvalHuman owns risk and merge decision.
- 8Runtime feedbackObservability closes the loop after change.
- 1Cron / schedulerScheduled audit starts proactive improvement.
- 5Structured issueFinding becomes scoped backlog.
- 1LiteLLM routerRoutes model calls through profiles and status.
- 2Provider fallback chainFallback keeps review execution available when providers degrade.
- 3Specialized agentsAgent work continues after routing decision.
Trigger · Observability
Observability signal
A monitored signal from the documented observability stack and reporting workflows.
SRE reporting flows use observability surfaces and read-only tools. The signal starts analysis; it does not automatically authorize production changes.
Remediation is tied to measurable system behaviour rather than to a hunch about what changed.
Operating layers
The machinery behind the graph.
Select a layer to see what it is, how it works, why it matters, and what the implementation covers.
Selected layer explained
The reference environment
Operational Scale
A multi-service reference environment of approximately 70 services, spanning ingress, observability, automation, AI tooling, storage, backup, developer tooling and runtime applications.
Services are grouped by operational responsibility rather than by team. The observability stack covers the environment, and engineering changes to its configuration and automation are governed through the auditable delivery workflow described on this page.
It shows the operating model applied across a heterogeneous, multi-service platform rather than to a single agent workflow or an isolated automation script.
Stack overview, per-service documentation, runtime configuration and monitoring coverage.
The material above describes what the implementation covers. I walk through the architecture, the code and the failure modes directly in a technical conversation.
Architecture by responsibility
The Agentic SRE platform loop
Telemetry, logs, metrics, scheduled checks and user feedback.
Runtime, dispatcher, worker roles, task state and handoff.
Issues, branches, PRs, evidence and reviewable changes.
Right agent, right tool, right context and provider fallback.
CI, policies, specialist reviews and human approval.
SLI/SLO feedback, DORA signals, dashboards and auditability.
Representative workflow view
Agentic Delivery Control Plane
Compact view of the governed delivery model. Values below are representative workflow states, not production metrics.
1 Backlog & Issues
Improve recurring integration error triageP1 · structured issue · owner required
Document deployment verification loopP2 · docs · DocGuard
Reduce flaky review rerunsP2 · CI · router evidence
2 Agent execution
Code AgentRUNpreparing PR
Test AgentRUNexpanding checks
DocGuardREUSEdocs unchanged
Risk ReviewerRUNchallenging assumptions
Visual ReviewSKIPno image delta
3 Quality gates
- Lint & static analysis PASS
- Unit / script checks PASS
- Policy validation PASS
- Review thread gate PENDING
- Human approval REQUIRED
4 Reliability signals
SLO statuswithin targetError budgethealthyPost-change checkpending verification
Reviewer routing matrix
| Change type | Technical | Business | Risk | DocGuard | Visual |
|---|---|---|---|---|---|
| Code | RUN | RUN | RUN | SKIP | SKIP |
| Docs | REUSE | REUSE | REUSE | RUN | SKIP |
| Workflow | RUN | RUN | RUN | RUN | SKIP |
| Diagram | SKIP | SKIP | SKIP | RUN | RUN |
Representative example. Exact routing is implementation-specific and can evolve over time.
Provider fallback chain
PrimaryFallback 1Fallback 2Fallback 3Break-glass
Reviewer routing decides who should review a change. Provider fallback decides which model/provider can execute that reviewer reliably.
What changes for the engineer
The judgment moves from writing the change to governing it
When agents can produce a plausible change in minutes, the scarce skill is no longer typing it. It is defining intent and constraints, deciding which checks are non-negotiable, and proving the result.
Where the effort used to go
Moving information between disconnected systems.
- Find the contextdashboards, docs, tribal knowledge
- Find the ownerwho is allowed to change this?
- Write the changethe part that felt like the job
- Chase the verificationdid it actually help?
Most of the engineer's energy is spent on handoffs, not on the decision.
Where the effort goes now
Defining intent, constraints and the evidence of success.
- Define intentthe outcome and its constraints
- Structured issuecontext, scope and guardrails
- Agents plan and implementwithin a bounded context
- Deterministic validationtests, policies and checks
- Human approvalthe engineer stays accountable
- Measured feedbackconfirm the result, or reopen
Capabilities
What it takes to make agent output trustworthy.
The disciplines below are what turn uncertain AI output into governed engineering work a team can inspect, challenge and improve.
Frame the operational pain, users, constraints and success signals before choosing models or tools.
Split responsibilities across agents, deterministic rails, integrations, observability and governance.
Use issues, branches, PRs, tests and specialist reviews to make agent output auditable and reversible.
Keep approval, escalation and destructive-action boundaries explicit instead of assuming full autonomy.
Make the workflow reusable across services, providers and agent roles rather than building a one-off demo.
Close the loop with SLI/SLO feedback, review evidence and follow-up work when the result is not good enough.
Every control in this system can be examined before you decide whether you want any of them. That is the point of building it end to end rather than describing it.
Contact
Considering AI-assisted operations, and want the guardrails right the first time?
Useful conversations usually start with the part you are most worried about — blast radius, data boundaries, cost, or convincing your own reviewers. Happy to walk through the architecture and where it would and would not fit.