how to build an agent that triages your support inbox

You built a support agent. It reads incoming emails and can draft basic replies. That was the easy part.

Now you've got 100+ emails hitting that inbox every day. Some are password resets. Some are customers threatening to churn. Some are enterprise prospects asking about SOC 2 compliance. And your agent treats all of them the same, because the only logic you gave it was "categorize and respond."

Triage is the missing piece. Not just "is this billing or technical?" but "how urgent is this, who specifically should handle it, and can the agent resolve it without involving anyone?" That's what we're building here.

If you haven't set up a basic support agent yet, start with our guide on building a support agent that handles email. This tutorial picks up where that one left off and focuses entirely on the triage and routing layer.

The routing table#

Before writing any code, define your routing rules. This is the part most people skip, and it's the part that determines whether your triage agent actually reduces workload or just adds noise.

Here's a routing table for a typical B2B SaaS team:

const ROUTING_TABLE = {
  billing: {
    critical: { assignee: "finance-lead@yourcompany.com", sla: "1h" },
    normal:   { assignee: "billing-queue@yourcompany.com", sla: "4h" },
    low:      { assignee: null, autoReply: true },
  },
  technical: {
    critical: { assignee: "oncall@yourcompany.com", sla: "30m" },
    normal:   { assignee: "engineering-queue@yourcompany.com", sla: "8h" },
    low:      { assignee: "engineering-queue@yourcompany.com", sla: "24h" },
  },
  account: {
    critical: { assignee: "cs-lead@yourcompany.com", sla: "2h" },
    normal:   { assignee: "cs-queue@yourcompany.com", sla: "8h" },
    low:      { assignee: null, autoReply: true },
  },
  general: {
    critical: { assignee: "cs-lead@yourcompany.com", sla: "4h" },
    normal:   { assignee: null, autoReply: true },
    low:      { assignee: null, autoReply: true },
  },
};

The null assignee with autoReply: true means the agent handles it alone. Everything else gets routed to a specific person or queue. The SLA field is for tracking, not enforcement -- we'll use it later to flag breaches.

Classifying urgency#

The existing support agent post uses a simple low/medium/high urgency scale. For triage, you need more precision. Critical means something is broken or money is involved right now. Normal means the customer needs a response but nothing is on fire. Low means it can wait.

The trick is giving the LLM enough signal to distinguish between these. A customer saying "this is urgent" isn't necessarily critical. A customer saying "our production API has been returning 500s for 20 minutes" is.

async function classifyEmail(email) {
  const safeBody = email.safeBodyForLLM();

  const response = await llm.chat.completions.create({
    model: "gpt-4o",
    response_format: { type: "json_object" },
    messages: [
      {
        role: "system",
        content: `You are a support email triage system. Classify this email on two axes.

Category (pick one): billing, technical, account, general
Urgency (pick one):
- critical: production outage, security incident, payment failure, data loss, legal threat
- normal: feature request, how-to question, non-blocking bug, billing inquiry
- low: feedback, general question, newsletter reply, thank-you note

Also assess:
- confidence: 0-1 float, how certain you are about category + urgency
- canAutoReply: boolean, true only if this is a routine question with a clear answer
- summary: one sentence describing the issue
- customerTier: "enterprise", "paid", or "free" if determinable from context, otherwise "unknown"

Respond as JSON.`,
      },
      {
        role: "user",
        content: safeBody,
      },
    ],
  });

  return JSON.parse(response.choices[0].message.content);
}

Notice email.safeBodyForLLM() instead of passing raw body text. This wraps the email content in boundary markers and strips any injected delimiters, so a malicious support email can't hijack your agent's classification prompt. When your triage agent processes hundreds of emails from unknown senders, this matters.

The routing function#

Now connect classification to your routing table:

async function triageEmail(email) {
  const classification = await classifyEmail(email);

  // Override: low-confidence classifications always go to a human
  if (classification.confidence < 0.75) {
    return routeToHuman(email, classification, "cs-lead@yourcompany.com",
      "Low confidence classification — needs human review");
  }

  const route = ROUTING_TABLE[classification.category]?.[classification.urgency];

  if (!route) {
    return routeToHuman(email, classification, "cs-lead@yourcompany.com",
      "No matching route");
  }

  // Auto-reply path
  if (route.autoReply && classification.canAutoReply) {
    const draft = await generateReply(email, classification);
    await sendReply(email, draft);
    await logTriage(email, classification, "auto-replied");
    return;
  }

  // Route to assigned human
  await routeToHuman(email, classification, route.assignee,
    `SLA: ${route.sla}`);
}

The confidence threshold is your safety valve. Anything below 0.75 goes straight to a human regardless of what the classifier thinks. Start with this threshold high and lower it as you review the agent's decisions over the first few weeks.

Routing to humans with context#

When the agent hands off to a person, the handoff quality determines whether you actually saved time. A forwarded email with no context is barely better than no triage at all. Here's what a good handoff looks like:

async function routeToHuman(email, classification, assignee, note) {
  const handoff = `**Triaged by support agent**
Category: ${classification.category}
Urgency: ${classification.urgency}
Confidence: ${(classification.confidence * 100).toFixed(0)}%
Customer tier: ${classification.customerTier}
Summary: ${classification.summary}
Note: ${note}

--- Original email below ---

From: ${email.from}
Subject: ${email.subject}
Received: ${email.receivedAt}

${email.body}`;

  await client.send({
    from: "support@yourcompany.com",
    to: assignee,
    subject: `[${classification.urgency.toUpperCase()}] [${classification.category}] ${email.subject}`,
    body: handoff,
  });

  await logTriage(email, classification, `routed to ${assignee}`);
}

The subject line prefix is deliberate. [CRITICAL] [technical] Production API returning 500s tells the assignee everything they need before opening the email. They can set up inbox filters on these prefixes to prioritize their own queue.

Handling edge cases#

Three situations will trip up a naive triage agent.

Multi-issue emails. A customer writes one email about a billing error and a broken feature. Your classifier picks one category and ignores the other. Fix this by adding a secondaryCategory field to your classification prompt and routing to both queues when it's present.

Reply chains. A customer replies to an auto-response with additional information. Your webhook receives this as a new email. Without thread awareness, the agent classifies it fresh and might route it to a different person. Track threads by In-Reply-To and References headers and route follow-ups to whoever handled the original.

async function triageEmail(email) {
  // Check for existing thread
  const existingThread = await findThread(email.headers);
  if (existingThread) {
    return routeToHuman(email, existingThread.classification,
      existingThread.assignee, "Follow-up on existing thread");
  }

  const classification = await classifyEmail(email);
  // ... rest of triage logic
}

Repeat senders. If the same customer emails three times in an hour, the third email should flag the pattern. Track sender frequency and auto-escalate urgency when someone is clearly frustrated or stuck.

Wiring it up#

Connect the triage function to your webhook handler. If you're using LobsterMail webhooks, verify the HMAC signature before processing:

app.post("/webhook/support", express.json(), async (req, res) => {
  const isValid = client.webhooks.verify(
    req.body,
    req.headers["x-lobstermail-signature"],
    process.env.WEBHOOK_SECRET
  );

  if (!isValid) return res.status(401).send("Invalid signature");

  res.status(200).send("OK");

  if (req.body.event === "email.received") {
    await triageEmail(req.body).catch(err => {
      console.error("Triage failed:", err);
      // Fail-safe: route unprocessable emails to a human
      routeToHuman(req.body, { category: "unknown", urgency: "normal",
        confidence: 0, summary: "Triage failed" },
        "cs-lead@yourcompany.com", `Error: ${err.message}`);
    });
  }
});

The catch block is important. If the LLM call fails, if parsing breaks, if anything goes wrong, the email still gets to a human. A triage agent that silently drops emails is worse than no triage at all.

Measuring triage quality#

After a week of running, pull your logs and look at four numbers:

1. Auto-reply accuracy. What percentage of auto-replies actually resolved the issue? Check by looking at whether the customer replied again within 24 hours.
2. Routing accuracy. How often did the assigned person re-route the email to someone else? Every re-route means the classifier got the category or urgency wrong.
3. SLA hit rate. What percentage of emails were responded to within the SLA defined in your routing table?
4. Confidence distribution. If most classifications land below 0.75, your prompt needs work. If most land above 0.95, you might be able to lower your auto-reply threshold.

These four metrics tell you where to tune. Adjust the classification prompt, update the routing table, and expand auto-reply coverage as the numbers improve.

What changes at scale#

At 100 emails per day, a single triage agent and one webhook handler is fine. At 1,000 per day, you'll want to process classifications in parallel and add a message queue between the webhook handler and the triage function. At 10,000 per day, you'll want multiple inboxes with dedicated agents per category, each with their own classification prompt tuned to that domain.

LobsterMail's inbox model supports this naturally. Each inbox gets its own webhook URL, so you can fan out at the infrastructure level rather than building a message router in your application code.

For more on how agents coordinate across multiple inboxes, see multi-agent email coordination. And if you're weighing webhooks vs polling for your triage setup, our webhooks vs polling comparison covers the trade-offs in detail.

Give your agent its own email. Get started with LobsterMail — it's free.