Using Snapback from a chat agent (Telegram, Slack)? The formats that make it reliable

A chat agent has a different shape from a coding agent. It runs a user turn, calls a tool, and relays an answer back into a Telegram or Slack message — often via a slow round-trip, with a human waiting. Drop a 25-second diagnosis or a 40-field JSON blob into that flow and the experience falls apart. Snapback has specific formats for exactly this case; here's how to use them.

The one setting that fixes chat UX: format:"summary_only"

The full diagnosis response is structured JSON — great for a coding agent that will act on individual fields, wrong for a chat agent that just needs to tell the user what happened. Pass format:"summary_only" and you get back a single relayable line plus a short headline, instead of the whole object:

diagnose_infra_error({
  error: "unable to get local issuer certificate",
  format: "summary_only"
})
// → { summary: "TLS: the server is sending an incomplete cert chain — serve the
//              intermediate certificate, not just the leaf.",
//      headline: "Incomplete TLS chain" }

Use the instant, free tools — skip the slow ones over chat

In a chat turn, latency is the enemy. Lean on the tools that return in under a second and need no token:

• diagnose_infra_error — a cryptic error → its family + fix, instantly; library-first (no LLM), LLM fallback on a miss. The best fit for chat: fast, free, and one-line-able.
• detect_loop — is the agent repeating a call? Milliseconds, free.
• budget_guard — mid-run token/cost/context check with suggestions, no LLM. Pass summary_only for a one-line warning to relay.

For a full failed run, diagnose_trace still works from a chat agent — just treat it as async. A known pattern returns in under a second, but a genuinely novel failure needs an LLM call and can take up to ~25s. Don't block the chat turn on it: acknowledge to the user ("looking into it…"), call diagnose_trace, and relay the summary when it returns.

Don't use live sessions over chat

Calling a tool correctly (the chat-agent gotcha)

Whether you're on OpenClaw, a custom Telegram bot, or any MCP client, tools are called through tools/call — never as a top-level method (that returns -32601). The result comes back in result.content[0].text as a JSON string; parse it, then relay the summary field:

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"diagnose_infra_error",
           "arguments":{"error":"<the error your agent hit>", "format":"summary_only"}}}

// parse result.content[0].text → { summary, headline } → send `summary` to the user

A reliable chat-agent recipe

1. On a cryptic error: call diagnose_infra_error with format:"summary_only", relay the summary line to the user. Instant, free.
2. On a suspected loop or budget issue: detect_loop / budget_guard (with summary_only) — relay the warning.
3. On a full failed run: acknowledge first, call diagnose_trace as async, relay the summary when it lands (allow ≥30s).
4. Never open a live session from a chat handler, and never dump raw JSON into the chat — always relay the one-liner.

For agent builders

This is the difference between an agent that says "your run failed with unhandled_tool_error, confidence 0.86, source library, family dns-tls…" and one that says "Looks like a TLS chain issue — the server needs to send the intermediate certificate." The second is what a user in Telegram wants, and it's one parameter away.