1) Intro – The provocation
We’re seeing a flood of products marketed as “SRE-powered,” “AI SRE,” or “SRE agent.” Catchy? Sure. Credible? Not really.
SRE is a discipline — not a SKU. It’s people, principles, and practices. When tools are named as if they are the SRE, trust erodes, adoption slows, and accountability blurs.
A colleague, Andrew Mallaband, challenged me to do more than critique. If “AI SRE” is the wrong direction, what’s the better one?
The answer is AI Tooling for SREs: a framing that puts people first, tools second. And at the heart of it is the SABRO Framework™ — a practical method for responsible naming and positioning.
2) The stakes – Why naming and framing matters
This isn’t semantics. Poor framing has real costs:
- Erodes trust. Practitioners tune out. Security and platform teams get skeptical. Buying committees stall.
- Confuses accountability. Tools don’t own reliability; teams do. Titles‑in‑a‑box blur ownership and undercut learning.
- Distorts priorities. If a tool claims to “be the SRE,” leaders expect silver bullets instead of investing in people, practices, and guardrails.
- Damages the craft. SRE’s credibility comes from rigor. Treating it as a tagline trivializes the work.
If you’re building or marketing tools for reliability, you need a way to frame them that earns trust and lands with practitioners. That’s what the SABRO Framework™ provides — a set of five principles to guide naming and framing responsibly.
3) The SABRO Framework™ – Five principles with examples
SABRO stands for: Specialization, Augmentation, Boundaries, Respect, Outcomes.
In one line: Choose metaphors wisely, support don’t replace, define limits, respect the craft, and tie names to outcomes.
3.1 Specialization (Professions as Metaphors)
Definition: Consider professions that have decades of cultural equity in a specific type of action.
Examples: Researcher, Detective, Teacher, Mechanic, Nurse, Analyst, Counsellor, Advisor, Guide, Sentinel.
Rule of thumb: Choose professions where the core action maps cleanly to what the tool does. Avoid professions that imply ownership or decision‑making authority (Engineer, Operator).
3.2 Explicit Augmentation (not substitution)
Definition: Describe how the tool augments SRE work. Never imply it replaces an SRE.
Questionable: “AI SRE,” “Autonomous SRE,” “SRE Agent,” “Virtual SRE Team.”
Preferred: Incident Triage Automation, Reliability Guide, SLO Policy Evaluator, Runbook Co‑Author.
Naming rules of thumb: Favor verb + object (e.g., Triage Alerts) or outcome nouns (e.g., Change Risk Score). If you use role metaphors, make them subordinate: Guide, Advisor, Sentinel, Counsellor.
3.3 Boundaries & Scope (say what it doesn’t do)
Definition: Be explicit about limits. Boundaries earn trust, reduce misuse, and reduce misinterpretation by setting clearer expectations.
Questionable: “End‑to‑end reliability platform.”
Preferred: Event Correlation and Prioritization for On‑Call.
Does: Deduplicate alerts, rank by blast radius, propose responders.
Doesn’t: Change infrastructure, auto‑close incidents, approve releases.
Implementation tip: Publish a simple Does / Doesn’t block in product docs and release notes.
3.4 Respect the Practice (use SRE terms correctly)
Definition: Align with established SRE concepts (SLIs/SLOs, error budgets, toil, incident response).
Questionable: “SLA monitoring,” “AI postmortem,” “Self‑healing SRE bot.”
Preferred: Error‑Budget‑Aware Release Guardian, Incident Chronology Builder, Toil Advisor.
Reality check: If it wouldn’t pass muster in an SRE book club, rename or rework it.
3.5 Outcomes Orientation (prove reliability impact)
Definition: Frame around measurable outcomes, not vibes.
Questionable: “AI‑powered insights,” “Intelligent observability,” “Smart SRE.”
Preferred: Degradation Forecaster, Pager Load Manager, MTTD Reducer.
Metrics to reference: MTTD/MTTR, change failure rate, error‑budget burn rate, alert volume, toil hours eliminated, availability vs. SLO.
3.6 SABRO Framework™ – Quick Reference Summary
| Principle | Focus | Quick Test |
| Specialization | Use professions with clear, recognized actions. | Does the metaphor map cleanly to the tool’s role? |
| Augmentation | Tools support SREs, never replace them. | Does the name describe support, not substitution? |
| Boundaries | Be explicit about scope. | Does your naming/messaging make limits clear? |
| Respect | Use SRE terms precisely. | Would this hold up in an SRE book club? |
| Outcomes | Name measurable impacts. | Does the name tie directly to reliability results? |
Of course, principles only matter if they’re applied. To make SABRO practical, let’s look at the SABRO Naming Compass and some illustrative archetypes that show the framework in action.
4) The SABRO Naming Compass – Quick Heuristic
Use this 30‑second test before you ship a name or tagline:
- Replace‑a‑person? If the name could be a job title, wrong direction.
- Function or outcome? If the name says what it does or improves, good.
- Plain speech at 2 a.m.? Can an ON‑CALL person say it and everyone knows what it means? Keep it.
- Three‑word default. Aim for ≤3 words, max 5. Avoid acronyms unless canonical.
- Ship with a Does / Doesn’t block. Make boundaries visible from day one.
5) Responsible naming archetypes (a starter library)
The following are illustrative patterns, not prescriptive names — inspirations to draw from.
Observability‑plus — Signal Deduper, Anomaly Ranker, Context Enricher
Incident management — Triage Sentinel, Impact Estimator, Chronology Builder
SLO management — SLO Guardrail, Objective Planner, Burn‑Rate Sentinel
Change & release — Change Risk Scorer, Release Guardian, Rollback Recommender
Capacity & performance — Capacity Forecaster, Cost‑Reliability Mapper, Latency Hotspot Finder
Toil reduction & hygiene — Toil Specialist, Environment Remediator
Resilience & chaos — Failure Drill Orchestrator, Dependency Weak‑Link Detector
GenAI augmentations — Root‑Cause Researcher, Runbook Co‑Author, Incident Debrief Counsellor
6) Reframing the conversation
When we apply this framework, we don’t just get better names — we get a healthier mental model:
- Tools amplify; teams own. Software holds the wrench; humans hold accountability.
- Practice before platform. Strong SLOs, sane alerting, disciplined change management — then tools.
- Precision builds trust. Clear boundaries, correct terminology, measured outcomes — credibility follows.
This mindset invites honest vendor–practitioner partnerships and more reliable systems.
7) Who should use SABRO?
- Product Marketers: naming, taglines, copy
- Product Managers: roadmap epics, feature framing
- Executives: positioning and strategy
- Practitioners: litmus test for vendor credibility
8) Strategic upside for vendors
- Differentiation: In a noisy market, clarity is a moat.
- Faster evaluations: Buying committees move quicker when scope is explicit.
- Adoption that sticks: Tools framed around outcomes land with SREs, devs, and leadership.
- Trust dividends: Respecting the craft pays off long‑term.
- Operationalize it tomorrow: Rename features to function/outcome terms. Add Does/Doesn’t sections. Tie claims to reliability metrics. Purge “AI SRE.”
9) Outro – The challenge & invitation
I still remember the first time a leader asked me if a tool we were evaluating could save us from hiring an additonal SRE “be one of our SRE.”
They weren’t being careless — they were hopeful. The vendor pitch had framed it that way, and in the heat of trying to move faster, it sounded plausible.
But that moment crystallized something for me: reliability isn’t something you outsource to software or AI. Tools can reduce toil, highlight risks, and accelerate response — but the ownership, judgment, and learning stay with the team.
That’s why SABRO exists. It’s a way to keep the language honest, so expectations stay grounded and tools are celebrated for what they actually do.
So here’s the challenge: if you’re building AI tools for SREs, resist the temptation to market them as job titles. Instead, tell the story of how they amplify human work — where they help, where they stop, and what outcomes they make possible.
And the invitation: try the SABRO Naming Compass on your next feature name, slide deck, or product page. See if it changes the conversation with your own engineers, or with the customers you’re trying to win.
If it works — share it back. I’d love to see how this framework evolves in the wild. Let’s raise the bar together.
If you’d like more tailored guidance on applying this framework in your own context, SRE Insights(sreinsights.io) is here as a resource and collaborator.
👉 One‑line pledge: We don’t name tools as job titles. We name them by what they do.
Hi, this is a comment.
To get started with moderating, editing, and deleting comments, please visit the Comments screen in the dashboard.
Commenter avatars come from Gravatar.