Service Level Objective (SLO)

An SLI is the raw, measurable metric that quantifies a specific aspect of service performance from the user's perspective. It is the foundational measurement upon which an SLO is built.

For tool call instrumentation, common SLIs include:

• Tool Call Latency: The time from request initiation to complete response receipt.
• Success Rate: The percentage of tool calls that complete without error (e.g., HTTP 2xx/3xx).
• Availability: The proportion of time a tool or API endpoint is reachable and operational.

An SLI must be precisely defined, including its measurement method, aggregation window (e.g., over 1 minute), and calculation formula (e.g., successful_requests / total_requests * 100).

The Target Threshold is the specific numerical value or range that the SLI must meet to satisfy the SLO. It transforms a measurement into a binary objective: met or missed.

Examples in agentic contexts:

• Latency SLO: "P95 tool call latency must be ≤ 500ms over a 28-day rolling window."
• Success Rate SLO: "99.9% of tool calls must succeed over a 7-day rolling window."
• Composite SLO: "99% of agent sessions must have a success rate ≥ 99.5% and a P99 latency ≤ 2s."

The threshold must be realistic, informed by historical performance, and aligned with user experience expectations. It is the core of the service contract.

The Measurement Window is the time period over which the SLI is evaluated against the target threshold. It defines the scope of compliance and is critical for meaningful trend analysis and error budget calculation.

Common windows include:

• Rolling Windows: A continuously moving period (e.g., 28 days). This is the most common and responsive method.
• Calendar-Aligned Windows: Fixed periods like a month or quarter.

For agentic SLOs, the window must be long enough to smooth over transient blips but short enough to detect meaningful degradation. A 28-day rolling window is a standard baseline, balancing statistical significance with operational responsiveness.

An Error Budget is the allowable amount of unreliability, explicitly derived from the SLO. It quantifies the risk a team can afford to take.

Calculation: If your SLO is 99.9% success rate over 28 days, your error budget is 0.1% of that time.

• 28 days = 40,320 minutes
• 0.1% of 40,320 = 40.32 minutes of allowed failure time.

This budget is consumed by any period where the SLI falls below its target. It serves as a crucial management tool:

• Spending Budget: Releasing new features or performing risky migrations.
• Preserving Budget: Halting releases to focus on stability and remediation.
• It creates a shared, objective language between development, product, and business stakeholders.

Burn Rate measures how quickly the error budget is being consumed. It is the primary signal for intelligent, actionable alerting on SLO violations.

• Fast Burn: A high burn rate (e.g., consuming 10% of the budget per hour) indicates a severe, ongoing incident requiring immediate paging.
• Slow Burn: A low burn rate (e.g., 2% per day) indicates a chronic degradation that requires investigation but not an immediate page.

Multi-Window, Multi-Burn-Rate Alerting is a best practice:

• Alert 1 (Page): Burn rate > 10% per hour for 1 hour. (Urgent fire).
• Alert 2 (Ticket): Burn rate > 2% per hour for 6 hours. (Smoldering issue).

This approach prevents alert fatigue by only waking engineers when budget consumption is urgent, tying alerts directly to business-impacting reliability.

Agentic systems rely on chains of dependencies. Their overall SLO is a function of the SLOs of their constituent parts.

• Dependency SLOs: Each external tool or API an agent calls should have its own SLO (e.g., 99.95% availability). The agent's ability to function is constrained by its weakest dependency.
• Composite SLOs: The end-to-end reliability of an agent completing a multi-step task is a composite of the SLOs for each step (planning, tool calls, synthesis).

Calculating Composite Reliability: For a simple serial chain, multiply the success probabilities. If an agent's task requires three tool calls in sequence, each with a 99.9% SLO, the composite probability of success is 0.999 * 0.999 * 0.999 ≈ 99.7%.

This highlights the need for defense in depth: designing for graceful degradation, fallbacks, and circuit breakers when dependencies fail.

A Service Level Indicator (SLI) is the raw, quantitative measurement of a specific aspect of a service's performance from the user's perspective. It is the foundational metric upon which an SLO is set.

• Examples for Tool Calls: Latency (P95), success rate (%), availability (uptime %), throughput (calls/second).
• Key Property: An SLI must be measurable, well-defined, and directly tied to user experience. For an agent, a critical SLI is tool call success rate, measuring the percentage of external API calls that complete without error.

An Error Budget is the calculated, allowable amount of unreliability a service can incur over a period (e.g., a month) before violating its SLO. It is derived directly from the SLO (e.g., 99.9% success rate implies a 0.1% error budget).

• Function: It quantifies risk and drives engineering decisions. Consuming the budget on new features may require a focus on stability next cycle.
• Agentic Context: For an autonomous agent with an SLO of 99.9% successful tool calls per day, the error budget is the permissible number of failed calls. Exhausting it triggers a reliability-focused response.

A Service Level Agreement (SLA) is a formal, often contractual, commitment between a service provider and a customer that specifies consequences (e.g., financial penalties) if defined SLOs are not met. An SLO is the internal target; an SLA is the external promise.

• Hierarchy: SLIs measure performance → SLOs define internal targets → SLAs define external commitments with remedies.
• Tool Call Example: An internal agent team may have an SLO for dependency API latency. The provider of that external API may have an SLA with the company guaranteeing that latency.

P95 Latency, or the 95th Percentile Latency, is a specific statistical measure used as a common Service Level Indicator (SLI). It indicates that 95% of all observed requests (e.g., tool calls) were completed at or below this time value.

• Purpose: It focuses on the experience of the majority while highlighting tail-end performance, which is more user-representative than average latency.
• SLO Example: A critical SLO for an agent's tool-calling subsystem could be 'P95 tool call latency < 500ms'. This ensures that 95% of users experience fast responses, even under load.

A Synthetic Transaction (or Synthetic Probe) is an automated, scripted test that simulates a user or agent's interaction with a system from outside the production environment. It is used to proactively validate that SLOs are being met.

• Mechanism: These tests execute predefined workflows, such as an agent making a sequence of tool calls, and measure resulting SLIs like latency and success rate.
• Role in SLOs: They provide constant, controlled validation of SLO compliance, especially for availability and correctness, independent of real user traffic.

A Canary Deployment is a release strategy where a new version of a service (e.g., an agent's tool-calling logic) is deployed to a small, representative subset of production traffic. Its performance is instrumented and compared against the stable version's SLOs.

• SLO Integration: The canary's key SLIs (error rate, latency) are monitored in real-time. If they deviate negatively from the baseline and threaten the SLO/error budget, the deployment is automatically rolled back.
• Value: It allows for safe, data-driven releases by using SLO compliance as the primary gate for full deployment.