ByHeartAI
Advanced8 min read

Design a Customer-Support Agent

A support agent looks up this customer, grounds in policy, proposes a structured action, and only then acts — refunds and mail are gated. Success is the ticket done right, not a friendly paragraph.

Explain like I'm new to AI

Q&A over policy is the RAG chatbot. Support changes state (refund, ship, close). That's where excessive agency lives.

  1. 1. Identify
  2. 2. Ground
  3. 3. Propose
  4. 4. HITL
  5. 5. Act

Identify: Session is this customer. Load ticket + entitlements from your API — not from the model's imagination.

Support is a workflow with one agentic middle — not a mega-agent with refund and shell on the same kit.

Job: resolve this customer's issue within policy. SLO: correct resolutions, p95 that a human can wait, $ per ticket, no unauthorized refunds.

Shape: mostly workflow with a little agent in the middle (how to phrase, which doc). Not a mega-agent with shell + refund.

Mental model

A junior specialist with a binder and a stamp that only the supervisor (or a hard-coded rules engine) can press.

How it works

  • Identity from the session/CRM, never from chat ("I am the account owner").
  • Retrieve policy + this ticket (ACL). PII minimized in the window.
  • Tools: get_order, preview_refund — not refund until gate.
  • HITL or deterministic policy ("under $20 auto") in code.
  • Memory: session for the thread; long-term preferences carefully (memory-conflicts).
  • Eval: gold tickets with expected tool + outcome. Online: time-to-resolution, reopen rate.
  • Route FAQs to the RAG chatbot path; escalate ambiguity to humans.
  • Traces: tool spans. Polite text can still have called delete.

Real-world example

Bot "cancels" by deleting the user because tool names were vague. Schema + confirm + session user id would have saved it. Injection in a ticket attachment is the same hole (indirect injection).

Technical explanation

Structured output for the preview. Your API binds parameters. Encode anything rendered.

Don't put the Stripe key in the prompt. Loop cap so a confused agent doesn't refund 400 times.

Common mistakes

Common mistake

One kit: search, refund, send-mail, "run SQL." That's a buffet for injection.

  • Thumbs as the only metric.
  • Skipping HITL in staging because "not real money."

When to use it

  • Issues that need lookup + a small set of actions + policy. High volume FAQs stay RAG-only.

When NOT to use it

  • Don't agent-ize "what's our return window?" — that's the RAG chatbot.
  • Don't let the model invent the customer id.

Alternatives

  • Pure workflow (classify → template). Human-only for high-risk. Fine-tune tone after the gates exist.

Quick quiz

Question 1 of 3

Where should the customer id come from?

Question 2 of 3

What's the primary success metric?

Question 3 of 3

True or false: refund and unrestricted SQL belong on the same support kit for convenience.

Related concepts

  • Human-in-the-Loop — Human-in-the-loop inserts a person's approval before risky or irreversible agent actions, combining autonomy with safety and accountability.
  • Tool Abuse and Excessive Agency — If the model can call a powerful tool, injection can try to. Shrink the kit, validate args, and require humans for irreversible actions.
  • Design a RAG Chatbot — A RAG chatbot retrieves an approved corpus, reranks, and answers with real citations — not an agent, not a fine-tuned wiki.
NextDesign a Coding Agent

Last reviewed: 2026-09-04 · Written by ByHeart AI · Reviewed by ByHeart AI