Sitemap

Apologizing for Network Errors in AI Systems

3 min readAug 4, 2025

--

Date: 2025–08–04
Prepared By: Jason Allshorn

🔌 1. Why AI Apologies for Network Failures Matter, Even More Than You Think

AI agents today aren’t just answering questions, they’re expected to carry the flow of entire user journeys. Whether that’s helping someone reset a password, check a refund, or troubleshoot a failing integration, users treat AI as a frontline channel, not a toy. But what happens when that channel suddenly drops out, not because the model got something wrong, but because the Tools it’s using created an error?

Unlike hallucination, this isn’t a confidence problem. It’s a continuity failure.

When an AI says something false, the user might raise an eyebrow. But when it says nothing at all, just “hmm, something went wrong’, the user’s experience flatlines. In customer support and high-frequency workflows, this isn’t a minor hiccup. It’s an interruption that risks the entire interaction.

At Sendbird, we’ve seen firsthand that trust isn’t only lost when a model misfires, it’s lost when the Tool calls error out without grace. That’s why we believe apologies for infrastructure failures must be just as thoughtful as those for misinformation.

Inspired by the frameworks from “AI Apology: A Critical Review of Apology in AI Systems”, and shaped by brutal lessons from real-world Sendbird agent deployments, this piece explores how to build dynamic, contextual apologies when your AI hits the wall because the backend ghosted it.

💔 2. Why Flow Breaks Matter

AI agents now shoulder entire user journeys, from password resets to refund checks. When the backend breaks, the conversation flat-lines, and the user feels abandoned.

🙏 3. Failure Pattern #1 — The “Something Went Wrong” Cop-Out

What it looks like.

"Hm… something went wrong.

Why it’s deadly

  • Zero attribution → user wonders “Was it me?”
  • No guidance → conversation stalls.
  • Erodes the illusion of control faster than a bad answer.

A proper apology

"I couldn't reach our servers just now. That's on my end. 
Want me to try again, or flag a human? "

🛠️ 4. Flow-Repair Scaffold for Backend Failures

Step: 1 Acknowledge

Purpose: Admit the snag, stay human.

Example: “Sorry, hit a snag fetching that.”

Step: 2 Detect & Classify

Purpose: Map error type → playbook.

Example: Timeout → retry; auth error → escalate.

Step:3 Attribute

Purpose: Blame yourself, not the user.

Example: “Looks like a backend hiccup.”

Step: 4 Explain (optional)

Purpose: One-line cause builds trust.

Example: “Our service didn’t respond in time.”

Step: 5 Offer Repair

Get Jason Allshorn’s stories in your inbox

Join Medium for free to get updates from this writer.

Purpose: Put the user back in charge.

Example: Retry │ Notify │ Human │ Alternatives

ASCII Swim-lane (happy ↔ failure path)

User → Agent → Backend

| | |

| normal | call |

|──────────┼────────▶|

| | 5xx |

| |◀────────|

| | asks: retry / notify / escalate |

|◀─────────┼────────▶|

🛡️ 5. Counter-Arguments: When Not to Apologise

Concern: Noise from over-apology

Guideline: Rate-limit to one apology per unique error ID per session.

Concern: Security leakage

Guideline: Keep explanations generic (“server timeout”), never expose stack traces.

Concern: False hope via retries

Guideline: Offer “Retry” only if historical success > 30 % in the last 60 s.

💻 6. Implementation Snippet — Decorated Error

400 Error.

{
"message": "Bad Request",
"userMessage": "Sorry, I couldn't process your request to update the profile. The input format looks off.",
"agentHint": "Suggest the correct JSON payload, then offer to retry once corrected."
}

Check out the example server seen here for a full example of error decoration.

🚶 7. Conclusion & Next Steps

  1. Audit your current error catalogue and flag “uninformed errors”.
  2. Map each error class to the five scaffold steps.
  3. A/B test retry vs. notify vs. escalate flows for a month.
  4. Localise & tone-match the apologies for global users (yes, Korean too).

🤖 Don’t Fake Resilience

The biggest sin here is the illusion of recovery. If you know retries won’t work, don’t offer them. That’s just another form of lying, yeah?

👀 Things to Watch Out For

  • Avoid fake empathy: “We understand your frustration” = ugh. Just fix it.
  • Avoid technical overkill: Don’t show a 502 traceback.
  • Avoid the ‘try again later’ cop-out: Give a specific next step, or admit it’s out of your hands and you’ve flagged it.

--

--