Playbook: Build a Tier-1 Support Triage Subagent

Most support tickets are not new problems. Look at the last hundred tickets in your queue: the long tail looks unique, but the head is dominated by maybe ten flavors of the same five questions. "How do I reset my password?" "Why is my order delayed?" "Can you cancel order X?" "What's the status of my refund?"

Each one ties up a tier-1 agent for ten minutes — sometimes more, because the agent has to look up information across two or three systems before they can answer. By the time they have helped the customer, three more of the same kind of ticket are in the queue.

This playbook walks you through a different approach: a triage subagent that lives in your support intake channel, recognizes the routine questions, delegates them to specialist subagents that already know how to answer them, and only routes a real ticket to a human when none of the specialists can.

What you will build

By the end of this playbook, you will have:

  • A Support Triage subagent in #support-intake that classifies every inbound message and decides what to do with it.
  • Three specialist subagents — Order Status Specialist, Refund Status Specialist, Account Self-Service Specialist — that each handle one category and nothing else.
  • A delegation flow: triage looks at the message, picks a specialist, hands it off, and posts the specialist's answer back to the customer.
  • An escalation path: anything the triage agent isn't confident about gets a real ticket created and a human paged.
  • A weekly digest that tells you which categories the agent handled, escalation rate, and what new patterns are emerging.

What you need before you start

  • An Assist workspace with your AI client connected via MCP.
  • Read access to your order management system and your support ticketing system. For this playbook we assume order management at https://oms.internal.company.com/api, and a ticketing system (Zendesk, Linear, Jira Service Management — whichever you use) with API access.
  • The Slack bot in your support intake channel.
  • A way to actually create a ticket from an API call, when the agent decides to escalate.

Step 1: Pick the categories

Look at your last 200 tickets. Group them. You will probably end up with something like:

  • Order status — 35%
  • Refund/cancellation status — 20%
  • Account/login issues — 15%
  • Billing questions — 10%
  • Real new problems — 20%

This playbook covers the first three, which together represent 70% of inbound traffic. After the pattern is working, you can add specialists for billing and any other category that grows large enough to merit one.

Step 2: Build the per-category tools

Each specialist needs the tools that let it answer its own category. Build them in /tools/new, test them on the edit page, and publish each before wiring it up. The shared toolbox playbook covers the full build/test/publish flow if you are new to it.

Each blockquote below is the spec for one tool.

Order Status

oms_get_order — takes an order_id and returns the order status, line items, ship date, expected delivery date, and tracking number if available. Endpoint: GET https://oms.internal.company.com/api/orders/{order_id} with bearer auth using OMS_TOKEN.

oms_find_order_by_email — takes an email and an optional since_date and returns the most recent order(s) for that customer. Endpoint: GET https://oms.internal.company.com/api/orders?email={email}&since={since_date}.

Refund Status

oms_get_refund_status — takes an order_id or a refund_id and returns the refund's current status, amount, processed date, and payment method. Endpoint: GET https://oms.internal.company.com/api/refunds?order_id={order_id}.

Account Self-Service

account_password_reset_link — takes an email, calls the auth service to issue a one-time password reset link, and returns the link. Endpoint: POST https://auth.internal.company.com/api/password-reset with body {email, source: 'support'}. Uses the secret AUTH_SUPPORT_TOKEN.

account_recent_logins — takes an email and returns the last five login attempts with timestamp, IP, and outcome. Endpoint: GET https://auth.internal.company.com/api/login-history?email={email}&limit=5.

Escalation

tickets_create — takes customer_email, subject, body, and priority. POSTs to the ticketing API and returns the new ticket ID and URL. Endpoint: POST https://tickets.internal.company.com/api/tickets.

Test each tool on its edit page with a known-good example. Publish each one before moving on.

Step 3: Create the three specialists

Each specialist is its own subagent with a tight scope. Go to Subagents > New Agent and create them in turn.

Order Status Specialist

  • Label: Order Status Specialist

  • Description: Answers customer questions about order status, shipment, and delivery. Looks up the order, returns a clear status with expected delivery and tracking link.

  • Job Description:

    You answer order-status questions and nothing else. You are given a customer message and a customer email. Use oms_find_order_by_email to find the most recent order, then oms_get_order to get details. Reply with a short, friendly status: where the order is in its lifecycle, the expected delivery date, and the tracking link if shipped. If you cannot find an order matching the customer, say so honestly and recommend escalation. Do not invent details.

  • Tools: oms_find_order_by_email, oms_get_order.

  • Model: a fast model.

Refund Status Specialist

  • Label: Refund Status Specialist

  • Description: Answers customer questions about the status of refunds and cancellations. Looks up the refund and returns processed date, amount, and method.

  • Job Description:

    You answer questions about refund status. Given a customer message and email, find the most recent order with oms_find_order_by_email, then check refund status with oms_get_refund_status. Reply with the refund's current state, amount, processed date, and method. If no refund is in progress, say so and recommend escalation. Never promise a refund or commit to a timeline beyond what the data supports.

  • Tools: oms_find_order_by_email, oms_get_refund_status.

  • Model: a fast model.

Account Self-Service Specialist

  • Label: Account Self-Service Specialist

  • Description: Handles password reset requests and account access issues. Issues self-service reset links and identifies obvious login failure patterns.

  • Job Description:

    You handle account access issues. For a password reset request, use account_password_reset_link to issue a link and reply with it (do not include the link in any logged context). For "I can't log in", use account_recent_logins to identify the pattern: wrong password, locked account, IP block. Reply with the appropriate self-service step. Escalate anything that looks like account compromise.

  • Tools: account_password_reset_link, account_recent_logins.

  • Model: a fast model.

Save all three.

Step 4: Create the triage agent

Now create the orchestrator. Subagents > New Agent:

  • Label: Support Triage

  • Description: Front-line triage for #support-intake. Classifies inbound questions and delegates to a specialist. Escalates anything outside the specialist categories by creating a ticket.

  • Job Description:

    You are the front line of support. Every message in #support-intake comes to you first. For each message:

    1. Identify the customer email. It is usually included in the bot-formatted message at the top. If you cannot find it, ask once: "Can you share the email address on the account?"
    2. Classify the question into one of: order_status, refund_status, account_access, or other.
    3. If order_status, delegate to Order Status Specialist with the message and email.
    4. If refund_status, delegate to Refund Status Specialist with the message and email.
    5. If account_access, delegate to Account Self-Service Specialist with the message and email.
    6. If other — or if any specialist returns "I can't help with this" — call tickets_create with the customer email, a one-line subject, and the full message body. Set priority to "normal". Reply in Slack: "I've created a ticket for this — a human will respond shortly. Ticket ID: {id}."

    Always post the specialist's answer back to the channel as your own response. Do not say "the Order Status Specialist replied". Customers should see one consistent voice.

    If you are unsure which specialist applies, escalate. False positives are worse than escalating something that could have been handled.

  • Tools: tickets_create, slack_send_message.

  • Model: a capable model — classification matters here.

Save it.

Step 5: Wire the triage agent to the channel

Open Support Triage's edit page. Add a Channel Mapping:

  1. Find the #support-intake channel ID in Slack (click the channel name, scroll to the bottom of About, copy the ID).
  2. In the agent's edit page, scroll to Channel Mappings, click Add.
  3. Pick Slack and paste the channel ID.
  4. Click Add Mapping.

Confirm the Assist Slack bot is in #support-intake (/invite @YourAssistBotName).

Step 6: Test the full flow

Post test messages in #support-intake covering each category:

For each, watch the triage agent classify, delegate, and respond. The first three should get a specialist response in seconds. The fourth should result in a ticket being created.

If triage classifies wrong, look at how it described its decision in the chat log (open /agent-tasks to inspect runs). Tighten the classification rules in the triage system prompt.

Step 7: Add the weekly digest

Once the system is running, schedule a weekly summary so you can see what's working and what isn't. Open the triage agent's chat:

"Schedule yourself to run every Monday at 8:00 AM America/New_York with this prompt: 'Look at last week's runs in agent-tasks. Count how many messages you handled by category, how many you escalated, and which specialists did the most work. Post a summary to #support-leads.' Call the trigger 'Weekly Triage Digest'."

The Monday morning digest gives the support manager a one-glance view of:

  • Volume by category.
  • Escalation rate (the leading indicator of new patterns).
  • Specialist performance (slow specialists may need better tools).

When escalation rate climbs in a specific shape — say, a lot of "billing" tickets — you know it is time to build a Billing Specialist.

What you built

You have a tier-1 triage system that:

  • Replies to 70%+ of inbound questions in seconds, instead of in minutes.
  • Routes only real new problems to humans, with a real ticket ID and full context.
  • Speaks with one voice to the customer, even though three specialists are doing the work behind the scenes.
  • Tells you, week over week, where the work is shifting so you can build the next specialist before the queue backs up.
  • Runs entirely in your Assist workspace — no third-party chatbot service, no sensitive customer data leaving your environment.

What used to be a six-person tier-1 queue is now a two-person queue handling the genuinely interesting work, plus an agent that handles everything routine.

Where to go from here

  • Add specialists. Billing, shipping address changes, gift cards — anything that breaches 5% of volume deserves its own specialist.
  • Add a "warm transfer" pattern. When triage escalates, post the specialist's diagnostic notes alongside the ticket so the human starts with context.
  • Add language detection. Front the triage agent with a translator subagent and your support coverage suddenly extends to every language you support.
  • Build a customer-facing version. The same triage + specialist pattern can be exposed to customers directly in your help widget through the same MCP server architecture.

Related guides