Support desk

A hardware shop runs a support desk: customers write in about a part that failed, a warranty question, or something that doesn’t work the way the manual says. Someone reads each ticket, checks the documentation and, for the tickets that need it, issues a replacement rather than answering in words.

Support desk composes that into one pipeline: sort the ticket, search the documentation, let the model reach for a tool when the ticket needs an action rather than an answer, and pause before anything costly goes out.

Example run

"The drain pump on my DW-300 (HLV-2205) failed under
warranty, still rattling after I replaced it once already."

Walkthrough

The four steps compose the runnable code already on the routing, RAG, function calling and human approval pages, each written against the site’s shared document set rather than a literal support desk. Composing them means keeping the same functions and swapping in this job’s own queues and tool: billing / technical / general instead of lookup / numeric / unclear, and issue_replacement(part, reason) in place of lookup_part(part_number). The tool is the only genuinely new code; no version of it exists in the repository yet.

The run shown is a repeat-failure ticket. It classifies technical, and the search step retrieves the warranty policy and the part’s own listing. The model reads both and decides on its own that a repeat failure under warranty calls for a real replacement, and calls the tool with the part number and its reasoning. Your code runs the tool and the model drafts the reply from the result: the same decided_by: "model" step, and the same “your code always runs whatever it calls” boundary, that function calling’s own page describes. Because a tool ran, the gate pauses on tool_used before the reply goes out, and a person checks the ticket, the sources and the tool call together before it ships.

Be plain about two things. The ticket text and the retrieved documentation both go to the model, so a desk handling anything customers would not want copied elsewhere has a hosting decision to make before an accuracy one. And log the tools offered, the call and its arguments, the retrieved sections, the gate’s reason and the reviewer’s decision together, or a replacement that should never have shipped cannot be traced to the ticket, the sources or the argument the model chose.

What to measure

Routing, RAG and function calling are each scored on their own by the site’s shared 60-question set (see docs/EVALS.md); this job’s version of each (is the ticket sorted the way a person would, does the citation hit rate on retrieved sources hold up, does model_decided_steps come back as exactly one per ticket, never zero and never more) reuses those numbers, on a labeled set of real or synthetic tickets instead of document questions. Watch one thing routing and RAG alone can’t tell you: whether the tool actually gets called on the tickets that need an action, and only those: a model that reaches for it on every ticket, or never, has learned the wrong lesson from its description. Human approval isn’t scored by the shared runner (a paused ticket has no answer to grade) and needs the three numbers its own page describes instead: pause rate, whether the right tickets pause, and accuracy after a person’s decision. No result file exists for any of the four, so this recipe claims no score.

Variations

• Reach for MCP once more than one application needs these same actions, or the tools should come from a server the support team doesn’t maintain.
• Move to knowledge graphs if tickets start needing facts joined across documents: a part’s compatible models and each model’s own warranty class, answered together rather than by one lucky search.
• Move to agentic RAG if a single search often misses what a second, better-aimed one would find, before the tool decision happens.
• Add a second tool (a refund, an escalation to a technician) once real tickets show a second action worth automating; the routing table and the gate carry over unchanged.

Design choices