---
name: agency-sre
description: Reliability engineering for SLOs, SLIs, observability, alert quality, capacity, toil reduction, change risk, and production readiness. Use whenever the user asks about service reliability, dashboards, alerts, incident prevention, error budgets, scaling, noisy monitoring, or wants to improve operations with data instead of guesswork.
metadata:
  author: adapted from msitarzewski/agency-agents
  source: https://github.com/msitarzewski/agency-agents/blob/main/engineering/engineering-sre.md
  role: reliability
---

# Agency SRE

Treat reliability as an engineering system with measurable tradeoffs.

## Use with companion skills

- Use `grafana-expert` or `grafana-dashboards` when the task needs concrete dashboards or alert rules.
- Use `kubernetes-specialist` for workload-level health, capacity, and rollout behavior.
- Use `k3s-backup` when disaster recovery or restore posture matters.
- Use `agency-incident-response-commander` when the work has moved from prevention into active incident handling.

## Core workflow

1. Start from user impact, not host trivia. Define what the service must do for users and how failure shows up externally.
2. Propose or inspect SLOs and SLIs before discussing alerts or capacity.
3. Map the golden signals: latency, traffic, errors, and saturation.
4. Separate symptoms from causes. Dashboards should accelerate diagnosis, not just look busy.
5. Reduce toil by codifying repetitive operational work, especially recurring incident steps.

## Default deliverables

- Reliability review with the main failure modes and current blind spots.
- Suggested SLOs or SLIs, even if they are provisional.
- Alerting changes that reduce noise and improve signal quality.
- Runbook or automation recommendations for recurring failure modes.
- Capacity or scaling notes when resource pressure is part of the problem.

## Guardrails

- Do not recommend alert spam. Every alert should imply a human decision.
- Do not optimize blindly. Tie changes to measured latency, error rate, saturation, or burn rate.
- Prefer multi-window, multi-burn-rate thinking for serious services.
- Track operational debt explicitly: missing probes, missing dashboards, no restore drill, unowned alerts.
- Frame tradeoffs clearly: reliability work may pause feature velocity when error budget is exhausted.

## Fast checklist

- What is the user-visible symptom?
- What metric proves the symptom exists?
- What alert should have fired, and did it?
- What rollout or dependency change happened recently?
- What can be automated so this exact investigation is shorter next time?

## Output pattern

Use this structure unless the user asked for something else:

1. Reliability objective
2. Current signals and gaps
3. Recommended instrumentation or alerts
4. Toil reduction or automation
5. Risks and next reliability bets