4 patterns for this goal
SLA-management agents fail when they apply an incorrect SLA tier because retrieval selected a boilerplate-heavy but wrong-tier policy document, when a multi-agent handoff loses a customer-specific SLA override negotiated during support, when the agent generates a customer-facing breach explanation that fabricates a plausible-sounding root cause instead of retrieving the actual logged cause, and when the SLA clock pause/resume logic misclassifies the source of delay or fails to resume promptly. Four distinct mechanisms produce four failure patterns in SLA management: retrieval-based tier selection, handoff schema narrowness, hallucinated-cause substitution, and status-field-based clock management. Each mechanism independently defeats a different kind of verification: similarity-based retrieval defeats structural tier confirmation, fixed handoff schemas defeat overtime-determined-override propagation, free-text generation defeats logged-cause grounding, and status fields defeat actual-causality checking.
Every SLA-management pattern documented here reflects a gap between what the agent reasonably decides and what needs to be verified: a tier is selected by similarity when structural tier confirmation is needed, an override is noted in free text when structured account updates are needed, a cause is generated when a logged cause must be retrieved, and a clock state is managed by status when actual causality must be verified. The fix is standardized: pre-filter retrieval by structural tier confirmation, extend handoff schemas for task-relevant determinations, gate breach-cause generation on incident-tracking tool calls, and replace status-field-based clock logic with verified-causality logic.
Use a deterministic lookup against the billing/contract system to resolve the account’s contracted tier first, using that tier to select the applicable SLA document. Do not rely on free-text similarity to select the document. See Embedding-Retrieval Matches Wrong SLA-Tier Policy Document.
Add a structured, time-bound SLA-override field to the account record and require any support agent that negotiates an override to populate it directly, rather than leaving it only in a free-text conversation summary. See Multi-Agent Handoff Drops Customer-Specific SLA Override Between Intake Bot and Billing Agent.
No. Every cause statement in a customer-facing breach communication should be grounded in an incident-tracking tool call. Without a mandatory verification step, agents will generate plausible-sounding causes that may not match the actual logged cause, exposing the company to liability. See SLA Agent Fabricates Breach Root Cause in Customer Communication.
Not reliable. Status-field-based clock pause/resume logic measures what the system recorded, not what the customer actually experienced. Internal delays hidden by “waiting on customer” status inflate SLA compliance metrics. Dual reporting (status-based and actual-elapsed-time) reveals the gap. See SLA Breach Blindness from Clock-Pause Errors.
| Pattern | Mechanism |
|---|---|
| Embedding-Retrieval Matches Wrong SLA-Tier Policy Document | SLA tier retrieved by boilerplate similarity without structural tier filtering |
| Multi-Agent Handoff Drops Customer-Specific SLA Override Between Intake Bot and Billing Agent | Override negotiated in support; structured account record has no override field |
| SLA Agent Fabricates Breach Root Cause in Customer Communication | Breach cause generated without incident-tracking tool call to verify actual logged cause |
| SLA Breach Blindness from Clock-Pause Errors | Clock pause/resume based on status fields rather than verified causality, masking internal delays |
Total: 4 patterns
An SLA-Management Agent's RAG Step, Used to Retrieve the Applicable Response-Time and Resolution-Time Commitments for an Incoming Ticket Based on the Customer Account's Description, Pulls a Lexically Similar but Wrong-Tier SLA Policy Document, Causing the Agent to Apply Incorrect Commitment Clocks to the Ticket
An Intake Bot That Learns, During a Support Conversation, That a Customer Has a Negotiated SLA Override -- For Example, an Extended Response-Time Allowance Granted as Part of a Contract Renegotiation -- Records That Override Only in Its Conversation Summary, and a Downstream Billing or SLA-Compliance Agent That Calculates Breach Penalties From a Structured Account Field Never Receives the Override, Applying the Standard SLA Instead
When Generating a Customer-Facing Explanation for a Missed SLA, the Agent Produces a Plausible-Sounding Root-Cause Narrative It Was Never Given Rather Than Querying the Incident-Tracking System for the Actual Logged Cause
Agent Incorrectly Pauses or Resumes the SLA Response-Time Clock When a Ticket Status Changes, Masking an Actual SLA Breach