SRE for Antigravity Agents — Taming Probabilistic Systems with SLOs and Error Budgets

Instrumenting Layers 1 and 2

Here's the instrumentation code for the deterministic layers. It's TypeScript running on the server side of an Antigravity agent, emitting OpenTelemetry metrics aggregated by Prometheus.

// agent-sli.ts
// Purpose: instrument Antigravity agent SLIs
// Key idea: layer 1 (infra) and layer 2 (task completion) in one place
 
import { metrics, trace } from "@opentelemetry/api";
 
const meter = metrics.getMeter("antigravity-agent", "1.0.0");
 
// Layer 1: infrastructure SLIs
const requestCounter = meter.createCounter("agent_requests_total", {
  description: "Total agent requests",
});
 
const requestDuration = meter.createHistogram("agent_request_duration_ms", {
  description: "Agent request duration",
  unit: "ms",
});
 
// Layer 2: task-completion SLIs
const taskCompletionCounter = meter.createCounter("agent_task_completions_total", {
  description: "Task completion outcome",
});
 
export interface SliContext {
  agentId: string;
  taskType: string;
  userId: string;
}
 
export async function instrumentAgentRun<T>(
  ctx: SliContext,
  run: () => Promise<T>,
  verify: (result: T) => Promise<TaskVerification>,
): Promise<T> {
  const span = trace.getTracer("agent").startSpan(`agent.${ctx.taskType}`);
  const start = Date.now();
 
  try {
    const result = await run();
 
    // Layer 1: infra-level success
    requestCounter.add(1, { outcome: "ok", task_type: ctx.taskType });
    requestDuration.record(Date.now() - start, { task_type: ctx.taskType });
 
    // Layer 2: is the task actually done?
    const verification = await verify(result);
    taskCompletionCounter.add(1, {
      outcome: verification.completed ? "completed" : "incomplete",
      reason: verification.reason ?? "none",
      task_type: ctx.taskType,
    });
 
    span.setAttributes({
      "agent.task_completed": verification.completed,
      "agent.verification_reason": verification.reason ?? "",
    });
 
    return result;
  } catch (err) {
    requestCounter.add(1, { outcome: "error", task_type: ctx.taskType });
    taskCompletionCounter.add(1, {
      outcome: "error",
      reason: err instanceof Error ? err.name : "unknown",
      task_type: ctx.taskType,
    });
    span.recordException(err as Error);
    throw err;
  } finally {
    span.end();
  }
}
 
interface TaskVerification {
  completed: boolean;
  reason?: string;
}
 
// Example: verify a code-generation result
export async function verifyCodeGenerationResult(result: {
  files: Array<{ path: string; content: string }>;
}): Promise<TaskVerification> {
  if (!Array.isArray(result.files) || result.files.length === 0) {
    return { completed: false, reason: "empty_output" };
  }
 
  // Minimal structural check — run `tsc --noEmit` for a deeper one
  for (const file of result.files) {
    if (file.path.endsWith(".ts") && !file.content.includes("export")) {
      return { completed: false, reason: "no_export_statement" };
    }
  }
 
  return { completed: true };
}

The Prometheus query for the task-completion SLI is:

# Task-completion SLI over 28 days
sum(rate(agent_task_completions_total{outcome="completed"}[28d]))
  /
sum(rate(agent_task_completions_total[28d]))

The critical piece is that verify is per-task-type. "Done" means different things for code generation vs. documentation vs. a research summary. Make verify a pluggable function so new task types don't require rewriting the instrumentation layer.

Instrumenting Layer 3 (LLM-as-a-Judge)

Quality evaluation runs as a separate job — decoupled from real-time for reasons of cost, latency, and reliability.

// quality-judge.ts
// Purpose: evaluate sampled outputs with LLM-as-a-Judge
// Key idea: degrade gracefully — judge failures must not take down production
 
import { GoogleGenAI } from "@google/genai";
 
const judge = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });
 
const JUDGE_PROMPT = `
You are a quality evaluator for AI agent outputs.
Score the target on the three axes below (1-5) and return JSON.
 
- correctness: does it satisfy the task requirements
- safety: any security issues (hardcoded secrets, SQL injection, etc.)
- style: does it follow the project's coding conventions
 
Task: {task}
User input: {input}
Agent output: {output}
 
Return: {"correctness": 1-5, "safety": 1-5, "style": 1-5, "reason": "..."}
`;
 
interface QualityScore {
  correctness: number;
  safety: number;
  style: number;
  reason: string;
}
 
export async function evaluateQuality(
  task: string,
  input: string,
  output: string,
): Promise<QualityScore | null> {
  const prompt = JUDGE_PROMPT
    .replace("{task}", task)
    .replace("{input}", input.slice(0, 4000))
    .replace("{output}", output.slice(0, 8000));
 
  try {
    const response = await judge.models.generateContent({
      model: "gemini-2.5-flash",
      contents: prompt,
      config: {
        responseMimeType: "application/json",
        temperature: 0.1, // keep evaluation deterministic-ish
      },
    });
 
    const text = response.text;
    if (!text) {
      console.warn("judge returned empty response");
      return null;
    }
 
    const parsed = JSON.parse(text) as QualityScore;
 
    // Sanity check — judges occasionally return broken JSON
    if (![parsed.correctness, parsed.safety, parsed.style].every(
      (v) => typeof v === "number" && v >= 1 && v <= 5,
    )) {
      console.warn("judge returned invalid scores", parsed);
      return null;
    }
 
    return parsed;
  } catch (err) {
    // Judge failure is not a production failure — log and move on
    console.error("judge failed:", err);
    return null;
  }
}
 
// Sampling: evaluate 5% of traffic
export function shouldSample(): boolean {
  return Math.random() < 0.05;
}

Pure random sampling leaves rare task types under-evaluated forever. Layer in stratified sampling — "at least N samples per task type per day" — to keep evaluation coverage honest.

The natural follow-up question: "Can we trust the judge?" The answer is no — not alone. The judge is a coarse filter for high volumes; ground truth still comes from periodic human review. My team spends one hour per week comparing judge scores against human ratings on flagged samples. Track the agreement rate as a meta-SLI. When it drifts, the judge itself needs fixing.

The Economics of Agent Observability

One thing I wish I'd known at the start: agent observability has a very different cost curve than traditional observability. Traditional web-service observability scales with request volume and cardinality of labels. Agent observability scales with both of those plus the cost of LLM-as-a-Judge evaluations, which can be orders of magnitude more expensive per event than emitting a Prometheus metric.

Here's the back-of-envelope I use. Suppose your agent runs 100,000 requests per month and you evaluate 5% with a judge. That's 5,000 judge calls. If each judge call consumes roughly 4,000 tokens of input and 200 tokens of output, and your judge model costs around a dollar per million input tokens, you're looking at about $20 per month for quality evaluation. That seems cheap until you realize the numbers multiply fast. Move to 1M requests per month or 10% sampling, and you're at $400. Add a second evaluation pass for safety, and it doubles. I know teams spending more on judge calls than on their primary model calls because nobody sat down and did the math.

Three principles keep evaluation costs sane. First, stratify your sampling by risk — evaluate high-risk tasks at a higher rate than low-risk ones, rather than a uniform 5% across the board. Second, use cheaper models for the judge when you can. A Gemini Flash or Claude Haiku judge is often good enough for coarse triage, with occasional spot checks from a larger model on disagreements. Third, cache aggressively — identical outputs produce identical scores, so deduplicate before evaluating.

Also, don't evaluate everything synchronously. Asynchronous evaluation jobs that run nightly or hourly are almost always the right choice. Real-time judge evaluation adds latency to user-facing requests and exposes your production path to judge-model outages. Decouple the two paths from day one.

Picking SLO Targets (Without Emotion)

Once the SLIs are in place, pick targets. Don't reach for "99.9%" out of habit. Work backward from what the business can tolerate.

My current code-generation agent SLOs:

• Layer 1 (infra): 99.5% monthly success rate, P95 latency under 5 seconds
• Layer 2 (task completion): 92% monthly completion rate
• Layer 3 (quality): sampled correctness ≥ 4.0, safety ≥ 4.5

Why not 99.9%? Because roughly 5% of the tasks my agent sees are ambiguous enough that a human would also get them wrong. Demanding 99.9% on those is both unachievable and demoralizing for the team. An unreachable SLO is worse than no SLO.

For deeper grounding on SLO mechanics, the SRE Workbook by Google remains the best free resource, and it translates to agents with minor adaptation.

A common sticking point at this stage is choosing the measurement window. I default to 28 days for two reasons. First, a longer window smooths out diurnal and weekly patterns that would otherwise swamp the signal. Second, 28 days divides evenly into four weeks, which maps cleanly onto standard sprint cadences. Some teams use rolling 30-day windows; either works, but be consistent across all SLOs or cross-comparison becomes needlessly awkward.

I also separate the SLO from the SLO target visually in my documentation. The SLO is the commitment ("task completion rate over a 28-day window"), the target is the number ("92%"). When the number changes, it's still the same SLO. This framing helps when revisiting targets during quarterly reviews — you're not redefining what you measure, you're recalibrating what you commit to.

One practical mistake I've seen: setting all SLO targets to the same number for consistency. "All our agents target 95%" sounds clean but masks the fact that a code-generation agent and a document-summarization agent have fundamentally different user tolerances. The correct target depends on the real-world cost of a failure, which varies by task. Spend the time to have that conversation for each agent.

Building an Automated Error-Budget Gate

With SLOs set, their complement — the error budget — becomes the real operational lever. The code below is the gate my CI pipeline calls before every deploy.

// error-budget-gate.ts
// Purpose: check remaining error budget and decide whether to deploy
// Key idea: take deploy/experiment decisions out of debate and into data
 
interface ErrorBudgetStatus {
  consumedPercentage: number;
  remainingPercentage: number;
  recommendation: "proceed" | "proceed_with_caution" | "freeze";
  reason: string;
}
 
export async function checkErrorBudget(
  promUrl: string,
  sloTarget: number, // e.g. 0.92
): Promise<ErrorBudgetStatus> {
  const query = `
    sum(rate(agent_task_completions_total{outcome="completed"}[28d]))
      /
    sum(rate(agent_task_completions_total[28d]))
  `;
 
  const res = await fetch(
    `${promUrl}/api/v1/query?query=${encodeURIComponent(query)}`,
    { signal: AbortSignal.timeout(5000) },
  );
 
  if (!res.ok) {
    // If Prometheus is down, be conservative but not paralyzed.
    // This is a team policy decision — some orgs should return "freeze".
    return {
      consumedPercentage: 0,
      remainingPercentage: 100,
      recommendation: "proceed_with_caution",
      reason: `prometheus query failed: ${res.status}`,
    };
  }
 
  const data = await res.json() as {
    data: { result: Array<{ value: [number, string] }> };
  };
 
  const completionRate = parseFloat(data.data.result[0]?.value[1] ?? "0");
  const allowedFailure = 1 - sloTarget;
  const actualFailure = 1 - completionRate;
  const consumed = (actualFailure / allowedFailure) * 100;
 
  if (consumed < 50) {
    return {
      consumedPercentage: consumed,
      remainingPercentage: 100 - consumed,
      recommendation: "proceed",
      reason: "budget has plenty of headroom",
    };
  }
 
  if (consumed < 90) {
    return {
      consumedPercentage: consumed,
      remainingPercentage: 100 - consumed,
      recommendation: "proceed_with_caution",
      reason: "budget is being consumed — risky changes require review",
    };
  }
 
  return {
    consumedPercentage: consumed,
    remainingPercentage: 100 - consumed,
    recommendation: "freeze",
    reason: "error budget nearly exhausted — freeze non-critical deploys",
  };
}
 
// Example: call from CI
if (import.meta.main) {
  const status = await checkErrorBudget(
    process.env.PROM_URL ?? "http://localhost:9090",
    0.92,
  );
 
  console.log(JSON.stringify(status, null, 2));
 
  if (status.recommendation === "freeze") {
    console.error("❌ Error budget exhausted. Deploy blocked.");
    process.exit(1);
  }
}

Wire this into GitHub Actions, and the tone of your on-call shifts instantly. Nobody has to wake up at 2am to plead for a deploy freeze — the freeze is automatic and defensible.

The "Prometheus is down → proceed with caution" decision is a policy one. Your team might choose "freeze" here. I chose caution because the cost of a short Prometheus outage (agents stop, business halts) outweighed the risk of a bad deploy slipping through in that window. Document this trade-off as an ADR so future-you remembers why.

Evaluation Datasets as First-Class Artifacts

The evaluation dataset deserves a section of its own because most teams treat it as an afterthought and then wonder why their quality signals are noisy.

An evaluation dataset is a curated set of input examples with expected-output characteristics (not necessarily exact outputs — that defeats the point for probabilistic systems). For a code-generation agent, this might be 200 real user prompts paired with checklists of what a good output includes: "imports React", "handles the empty array case", "follows the project's naming convention."

Keep this dataset in Git, version-tag every significant change, and build your judge prompts to reference specific checklist items. This gives you three properties that pay off immediately. First, reproducibility — you can re-run last month's evaluation against this month's agent and genuinely compare. Second, debugging — when quality drops, you can diff the dataset against the last known-good state. Third, communication — the checklist is concrete enough that non-engineers can review it and ask useful questions.

Refresh the dataset every month or two. Real-world input distributions drift, and an eval set frozen in time gradually becomes disconnected from the live traffic your agent actually sees. The simplest way to refresh: sample recent production inputs (with consent and privacy review), hand-curate the expected characteristics, and replace the oldest third of the dataset. Don't replace all of it — keeping stable examples helps you notice regression.

For teams with a security posture requirement, treat the dataset as sensitive data. User inputs sampled into evaluation can contain PII, secrets, or proprietary business logic. Route them through the same data-classification and redaction pipelines you use for logs. Don't embed them in public Git repos.

Persuading the Organization

The hardest part of SLO introduction wasn't writing code — it was running meetings. Leadership and feature teams need to buy in, or your beautiful dashboards become decoration.

For leadership, frame the SLO as a service quality commitment line. "If task completion drops below 92%, we freeze new features and focus on agent quality" is a pre-agreed decision rule. Without it, quality vs. revenue arguments turn into territorial fights and the quality side quietly loses.

For feature teams, make the error budget visible as a real budget. "We've consumed 60% of this month's budget, so hold risky prompt changes" is a grown-up conversation. "Plenty of budget left — now's a good time for experiments" invites the team to take shots. The mantra "error budgets exist to be spent" matters here.

Build two dashboards, not one. Leadership wants a one-page snapshot; engineers want time-series drill-downs. Trying to do both in one view produces something no one can use.

Labeling Strategy for Task Types

The labels you attach to Layer 2 SLIs pay dividends for years. Here are mine and the rationale.

• task_type: code-gen / test-gen / doc-gen / research — carve out SLOs per task type
• tenant_id: per-customer or per-team identifier — catch tenant-specific regressions
• model: gemini-2.5-flash / gemini-3-pro / claude-sonnet-4.6 — compare model performance
• prompt_version: hash of the prompt template — track prompt-change impact on SLIs
• client_version: Antigravity client build — isolate client-side regressions

Don't label by user_id or anything high-cardinality — Prometheus will punish you. Use structured logs and traces for per-user investigation. Metrics aggregate; logs and traces individuate. Keep those roles separated.

When adding a new label, imagine two or three concrete queries you'd run with it. If you can't, you don't need the label yet.

Multi-Window Burn-Rate Alerts

Alert design is where agent SRE lives or dies. Alerting on the SLI directly (fire on 5% failure rate) will burn out your on-call rotation. The right trigger is the error-budget burn rate, evaluated across multiple time windows.

# Fast burn: 1h window consumes 2% of monthly budget (14.4x normal rate)
(
  1 - (
    sum(rate(agent_task_completions_total{outcome="completed"}[1h]))
      /
    sum(rate(agent_task_completions_total[1h]))
  )
) > (1 - 0.92) * 14.4
 
# Slow burn: 6h window consumes 5% of monthly budget (6x normal rate)
(
  1 - (
    sum(rate(agent_task_completions_total{outcome="completed"}[6h]))
      /
    sum(rate(agent_task_completions_total[6h]))
  )
) > (1 - 0.92) * 6

AND these two and you get an alert that fires when "at this pace we'll blow the budget this month" is genuinely true. That's the bar worth waking someone up for.

Start with looser multipliers (10 and 4 instead of 14.4 and 6) for the first month, then tighten based on observed firing frequency. Starting strict triggers alert fatigue in week one. Budget for this tuning as part of operations.

Also worth noting: the burn-rate alerts are designed to be quiet in steady state and loud only when intervention is genuinely needed. Resist the urge to lower their thresholds just because they haven't fired recently. An alert that never fires is doing its job — the point is to be reliable when a real incident hits, not to constantly remind you the system is alive.

One more practical note on thresholds. The burn-rate multipliers (14.4 and 6 in the examples) derive from the ratio of the window length to the monthly budget period. For a 1-hour window against a 30-day budget, 14.4 represents "burning budget 14.4 times faster than sustainable." If you run a shorter SLO window (say, 7 days), recompute these multipliers accordingly, or the alerts won't align with your commitment.

Incident Response Patterns

Three patterns show up enough to warrant pre-written runbooks.

Pattern 1: sudden spike in failure rate (e.g., 10% → 50% within an hour). First suspect the upstream LLM provider — check the Gemini status page and your own latency metrics for anomalies (big spikes or suspicious drops). Second suspect the most recent prompt or tool-definition change. Agent prompts are fragile; a one-line change can destabilize behavior. Keep prompts in Git, version them, and document rollback in the runbook.

Pattern 2: slow quality decay (error budget leaks over days). Hardest pattern. Infra is fine, Layer 2 is fine, but judge scores slide from 4.2 → 4.0 → 3.8. Usually this is data drift — the distribution of inputs has shifted away from what the prompt was designed for. Track token-length distributions and library-version exposure over time; when drift starts is when you need to update prompts or few-shot examples.

Pattern 3: regressions isolated to a segment. Overall SLIs look fine but one tenant or task type suffers. This is why the labeling strategy above matters — you can slice a tenant-specific SLO out of the same metrics without re-instrumentation.

Deciding What Counts as an "Agent Request"

Something easy to miss: the unit of measurement for your SLIs. An "agent request" isn't obvious. Does a user's chat message that fires off five tool calls count as one request or five? Does an autonomous agent running overnight to process 200 files count as one long request or 200 short ones?

My rule of thumb: count at the level of the user-visible intent. If a user asks "refactor this module" and the agent makes twelve tool calls to accomplish it, that's one request for SLI purposes. Completion means the refactor was delivered, not that each tool call succeeded individually. You'll still instrument individual tool calls with their own lower-level metrics, but they belong on a separate plane from the user-intent SLIs.

This matters because it aligns your measurement with what users experience. When users are frustrated, they're not frustrated that "tool call 7 of 12 returned an error" — they're frustrated that the refactor didn't happen. If your SLI speaks the user's language, the conversation around agent reliability becomes much easier for non-engineers to join.

For autonomous long-running agents, I recommend breaking them into logical checkpoints and measuring completion per checkpoint. A overnight agent processing 200 files can be thought of as 200 intents, each with its own completion signal. This keeps SLIs meaningful even at long time scales.

Rolling Out to a Skeptical Team

If your organization has never operated probabilistic systems in production, the SRE vocabulary alone can meet resistance. A few tactics that worked for me:

First, do the pilot on an internal-only agent before touching anything customer-facing. Getting the measurement loop right requires iteration, and doing that iteration in front of customers is unnecessarily stressful. An internal agent — say, a code-review bot used by your own engineering team — gives you real traffic and forgiving users.

Second, ship the dashboards before the SLOs. Let the team stare at raw task-completion rates for two weeks with no targets attached. This builds shared intuition for what "normal" looks like. When you then propose a target, it feels grounded rather than imposed.

Third, make the first SLO intentionally generous. You want the first month's review to be a positive data point, not a finger-pointing exercise. Aim to land comfortably inside the target so the team experiences the system as helpful rather than punitive. Tighten later, once trust is established.

Fourth, write the first three runbooks yourself. Delegation comes later. The patterns I documented in this article — sudden failure spikes, slow quality decay, segment-specific regressions — map to concrete runbook templates. Give your team something concrete to react to when their first real incident hits.

Fifth, celebrate budget usage publicly. When a team spends 80% of their monthly error budget on a bold experiment that paid off, that's a success, not a failure. Reinforcing this framing early prevents the budget from becoming something people hoard out of anxiety.

When Should You Actually Skip SLOs?

To be fair, not every agent deployment needs this level of instrumentation. A few legitimate skip conditions:

If your agent runs only a handful of times per day — less than, say, 100 requests daily — SLOs based on percentage rates become statistical noise. Stick with human monitoring and structured logs until volume justifies the machinery.

If your agent is clearly experimental and you're still in rapid iteration on what it even does, premature SLOs will lock in assumptions you're about to change. Stabilize the problem shape first, then measure.

If your team already has a higher-level SLO that subsumes agent behavior — for example, an end-to-end product SLO like "90% of user sessions end in a successful outcome" — you may not need a separate agent SLO. Inspect your existing measurements first and see if they already cover what matters.

That said, if your agent touches customer money, handles security-sensitive operations, or runs unsupervised, the overhead of SLOs is trivial compared to the cost of a bad week in production without them. In those cases, start instrumenting on day one.

Pitfalls I've Hit (and How to Avoid Them)

Pitfall 1: Keeping SLOs private to the SRE team. If feature teams don't know the SLO, "let's just ship this speed optimization" quietly eats the error budget. Publish SLOs on an internal dashboard anyone can open.

Pitfall 2: Not versioning the evaluation dataset. When judge scores drop, you can't tell whether the agent regressed or the dataset changed. Keep the eval set in Git and tag metrics with its commit hash.

Pitfall 3: Alerting on the SLI instead of the burn rate. The fix is the multi-window burn-rate alerts above — use them.

Pitfall 4: Deferring human review. Judges drift. Without weekly human spot-checks, you won't notice. Budget one person-hour per week explicitly as an SRE cost.

Pitfall 5: One SLO for many agents. One agent's regression hides inside another's surplus. Give each agent its own SLO and its own dashboard. Consolidation is a trap.

What This Has Looked Like in Practice

A few numbers from my own deployment to calibrate expectations. In the first month with Layer 2 SLIs only, our measured task completion rate was 78%. We had been telling ourselves it was "probably around 90%." That gap alone justified the entire exercise, because we stopped making decisions on hand-wavy assumptions and started making them on data.

By month three, after a handful of prompt improvements and a switch to better task decomposition, completion rate rose to 89%. We set the SLO at 85% — deliberately below the current rate — to give ourselves room for experimentation. Error budget consumption settled into a healthy rhythm around 60-70% per month, which felt correct: we were spending the budget on real work, not hoarding it out of fear.

By month six, we had all three layers live. Judge-based quality scores surfaced a problem we hadn't spotted: a specific sub-type of tasks (those involving TypeScript generics) scored consistently lower on correctness. That investigation led to a targeted prompt improvement that lifted overall quality by 0.3 points — modest on its own, but enough to prevent a slow burn into the error budget.

What I didn't expect: the SLO conversation changed the team culture more than the metrics did. Engineers stopped defending or attacking individual agent outputs in review meetings. They talked about trends, budgets, and trade-offs. The conversations got shorter and more productive. Feature teams started opening tickets with "this would consume about X% of the error budget — is that OK?" That's the real payoff of SRE: the organizational maturity, not the dashboards.

Integrating With Existing Observability Stacks

Most teams adopting agent SRE already have an observability stack — Datadog, Grafana Cloud, New Relic, Honeycomb, or some combination. You don't need to build a parallel universe for agent metrics. The OpenTelemetry-based instrumentation shown above exports to any OTLP-compatible backend, which covers nearly all of the above.

The one adaptation worth highlighting: agent traces get much longer than typical web-service traces. A single agent request can easily produce dozens of spans (one per tool call, plus sub-spans for retries and evaluations). Your backend's default sampling rates and retention policies may not handle this well. Review them before you start generating heavy traffic. In Datadog, for instance, you may need to enable APM trace metrics with custom attributes. In Honeycomb, tune the BubbleUp thresholds to account for the different event density.

For log correlation, make sure every span and log line shares a request ID. When an error surfaces at the Layer 3 evaluation step, you want to jump from the evaluation span to the original agent run's full trace, and from there to the raw LLM prompt and response. Without consistent request IDs, this investigation becomes an archeology dig.

Finally, consider the retention costs separately for metrics, logs, and traces. Metrics are cheap and worth retaining for a year. Logs can balloon with LLM prompt/response payloads — consider redacting or sampling after 14-30 days. Traces are the most expensive on most platforms; retain full traces for a week, and keep only sampled traces for longer windows.

Start Small

Don't build all three layers at once. SRE rolls in at incremental maturity levels. My suggestion for week one: instrument Layer 2 only. Layer 1 is usually covered by existing web monitoring, and Layer 3 has cost and operational overhead. Layer 2 alone tells you the meaningful completion rate of your agent for the first time.

After that week, take the number to your team and let it inform the SLO conversation. If the rate looks higher than expected, celebrate. If it looks lower, you now have the most important artifact in SRE: a number to improve.