Build AI-assisted support triage with scoped MCP tools

Letting an LLM write customer replies unsupervised is how brands end up apologizing. Letting an LLM classify, prioritize, and route tickets is how teams get faster without that risk.

This post walks through how to set up an MCP triage agent that does the latter, with the supervisory pattern that keeps it from drifting into the former.

What the agent does

Give the triage agent an MCP client with the agent workspace role and these coarse scopes:

• support:read
• support:write
• tasks:write
• activity:read, activity:write

When a ticket arrives, the agent:

1. Reads it via list_support_tickets and list_support_ticket_messages. 2. Classifies queue, priority, and tags. Calls update_support_ticket to set them. 3. Posts a one-paragraph internal summary via add_support_ticket_comment. 4. Creates a Reply within SLA task via create_task for the assigned human.

It never calls add_support_ticket_message — the action that posts a customer-facing reply.

How the "never reply directly" constraint is enforced today

Slab5's current Support scope model is coarse: support:read and support:write. With support:write, the agent *can*, mechanically, call add_support_ticket_message. The triage agent never doing so is enforced by three layered controls:

1. The prompt and tool catalog. Explicit instructions, examples of what to do and what not to do, and a tool surface that emphasizes add_support_ticket_comment over add_support_ticket_message. 2. The `agent` workspace role. Removes ability to change credentials, MCP auth policy, or other workspace administration. The agent's worst case is "sent a customer-facing message it shouldn't have," not "elevated its own access." 3. The audit log + revocation. Every add_support_ticket_message write is logged against the agent identity. If you see a customer-facing message you didn't expect, revoke the credential. The blast radius is bounded by how fast you noticed.

Finer-grained scopes (comments-only write distinct from messages) are on the roadmap. Until they ship, supervision is the audit log and a fast revocation reflex.

If you want a hard guarantee today

Run the triage agent with support:read and tasks:write only. It can still read every ticket, propose priority and routing decisions as comments via a separate write-capable identity, and create follow-up tasks. The triage gets a little slower; the guarantee that the agent cannot write a customer-facing message becomes mechanical instead of conventional.

Most teams find the supervised pattern good enough. The teams who don't, run the read-only variant.

What the audit log gives you

Every action the agent took is recorded against its identity. You can review classification accuracy, undo bad routes, and adjust scope or prompt if anything looks off. A weekly skim is enough for the first month.

Why this is still worth deploying

A triage agent that classifies, prioritizes, comments internally, and creates follow-up tasks handles the 80% of support work that slows your team down. The remaining 20% — writing a real customer reply — stays with a human, because that's where judgment lives. With the supervisory loop in place, the failure mode is "the agent did something I have to undo," not "the agent shipped something to a customer." That's the line that matters.

MCP client with the agent workspace role and support:read, support:write, tasks:write, activity:read, activity:write. Convention: never call add_support_ticket_message. For a hard guarantee today, drop to support:read + tasks:write only.

POST /v1/support/tickets from inbound channels. Dashboards read GET /v1/support/tickets. Webhooks on ticket.created and ticket.updated.