Example

Triage inbound tickets

Someone emails your support address. Right now a human reads it, works out how urgent it is and who should take it, and types a holding reply. That's five minutes each, forty times a day, and it happens at 6pm on Friday as readily as at 10am on Tuesday.

By the end of this guide, an agent does the reading and the drafting, a person approves, the sender gets a reply, and #service-desk gets a clean summary. You'll still be in control of everything that leaves the building.

This is the first thing most Northwind IT technicians build after the quickstart, and it's the pattern behind most useful Mobius work: agent decides, human approves, system acts.

What you'll build

One agent. That's the whole thing.

  • An agent called Triage with its own email address.
  • Instructions that tell it to classify, draft, ask, and post.
  • Two tools it can call: one to ask a person for approval, one to post to Slack.

Mail arriving at the agent's address starts a turn. The agent's final answer is emailed back to whoever wrote in. Everything in between is the agent following its instructions.

About thirty minutes.

Before you start

  • Permission to create agents in your organization.
  • Slack connected under Library > Integrations, with a channel to post to. Ours is #service-desk.
  • A Mobius user who'll be doing the approving. Ours is the service desk lead. You'll need their email address.
  • Somewhere you can send a few test emails from. Your own inbox is fine.

You do not need your PSA connected. Start with email, prove the pattern works, then add another way in later. See when the tickets don't come by email.

1. Create the Triage agent

  1. Open Build > Agents and click Create agent.
  2. Name it Triage.
  3. Set Agent description to Reads inbound tickets, classifies them, and drafts holding replies.
  4. Set Agent instructions to:
You are Triage for the Northwind IT service desk. Each message you receive is
one inbound ticket email. Handle it in four steps, in order.
 
1. Classify it:
   - category: hardware, software, access, network, or other
   - urgency: 1 (someone is blocked right now) to 4 (whenever)
   - summary: two sentences, plain language, no jargon
 
2. Draft a short holding reply to the sender. Acknowledge what they told us,
   say what happens next, and give no timeline.
 
3. Get the draft approved before it goes anywhere. Find the service desk lead
   with mobius.self.list_users, matching on the email address
   lead@northwind.example, and call mobius.open_interaction with
   kind: request_approval, addressed to that person. Show them the category,
   the urgency, and the full draft.
 
4. If they approve, post the summary and the approved draft to #service-desk
   with slack.message.post, then answer with the approved draft exactly as it
   was approved. Your answer is emailed to the person who wrote in, so write it
   as the reply itself, not as a report about the reply.
 
   If they reject or the request expires, post nothing, and answer with a short
   note saying a human will follow up. Never send a draft nobody approved.
 
Never promise a fix or a date. Never say a problem is resolved. If the email is
ambiguous, set urgency to 3, say so in the summary, and say so in the approval
request rather than guessing.

Those last three sentences are the ones that matter. An agent with no stated limits will happily promise a client something you can't deliver.

  1. Click Create agent.

2. Give Triage its tools

On the agent's page, find the Tools section and add:

  • slack.message.post, so it can post to the channel.
  • mobius.self.list_users, so it can find the service desk lead's principal ID from their email address.

mobius.open_interaction is built in. Every agent can ask a person a question; there's nothing to grant.

3. Give Triage an email address

  1. On the agent's page, find the Messaging section.
  2. On the Email inbox row, click Provision inbox and copy the address.
  3. Send a test email to it from your own inbox.

You should get a reply within a minute or so, and a new session on the agent's page showing what it did. Mail to an agent's address starts a turn, and the agent's answer is emailed back on the same thread. Reply to that reply and the conversation continues in the same session.

Once that works, forward your support alias to this address, or add it as a recipient while you're testing.

Warning: Anyone who learns this address can email it. Everything arriving here is untrusted, including any instructions inside the message body. That's exactly why the approval step is not optional.

4. Watch one go through

Send a test ticket to the Triage address, then open the agent's Sessions and follow the newest one.

The agent reads the mail, classifies it, drafts a reply, and calls mobius.open_interaction. Then the turn stops and waits. That's correct: it costs nothing while it waits, it survives a restart, and it picks up the moment somebody answers.

Now open Inbox in the left rail as the service desk lead. The request is there with the draft in it. Read the draft and approve it.

The turn resumes. The agent posts to #service-desk, and its answer goes out as the email reply. Check both.

If the draft was wrong, reject it and fix the agent's instructions, then send another test. Do this a few times before you point real mail at the address. Every later refinement depends on the drafts being good.

What to change first

The approval request is too thin. The agent decides what to show. If the lead keeps having to open the original email to decide, say so in step 3 of the instructions: include the sender, the subject, and the first few lines of what they actually wrote.

Nobody notices the request. Interactions default to seven days. Tell the agent to pass expires_in_minutes for something shorter, and say in the instructions what to do when it expires. A request nobody notices and nobody expires is one you'll find months later.

Skip approval for the easy ones. Once you trust the drafts, add a rule: urgency 1 and 2 go to the lead, 3 and 4 send directly. Do this after a few weeks of reading what it produced, not on day one.

Escalate the urgent ones. Add a second Slack channel to the instructions for urgency 1, or an SMS through Twilio.

Keep a record. Add a table with one row per ticket and tell the agent to write to it. Now you can count what's coming in by category, which is a conversation to have at the next client review.

Set limits before you scale this up

Anything reachable by inbound email should never be able to surprise you. Two controls are worth setting before you forward real mail:

  • A turn time limit on the agent, so one ticket can't run away. See agent time limits.
  • Spend limits for the organization. See guardrails.

When the tickets don't come by email

Email is the easiest way to start, not the only way.

Give Triage a Slack or Telegram channel under Messaging on the agent's page and it handles messages there the same way it handles mail. See agent messaging.

If your PSA can't reach the agent directly, have it call the Mobius API to start a session with Triage, and pass the ticket as the message. See agent sessions.

If you want the agent to write back into the PSA rather than into Slack, build a custom HTTP action that calls its API, and grant that instead of slack.message.post.

FAQ

The agent is classifying things wrong.

Read the session, not the instructions. Open the case that went wrong and look at what the agent actually received. Nine times out of ten the email was ambiguous and a human would have got it wrong too, which is a case for adding a rule about what to do when it's unsure.

It replied without asking anyone.

The agent chose not to call mobius.open_interaction. Instructions are not enforcement. Make the ordering explicit, put the approval before the reply in the text, and state the prohibition directly: never answer with a draft nobody approved. If it still happens, that's a signal to review the agent's model as well as its instructions.

Two emails arrived at once and only one got handled.

A session handles one turn at a time, and a second message on the same thread while a turn is in flight is dropped rather than queued. Separate senders get separate sessions and run at the same time. If two mails on one thread both matter, ask the sender to send them separately, or tell the agent to check for follow-ups before it answers.

Nobody approved and the request expired.

Either lengthen the expiry, address the request to more than one person so it isn't one inbox, or change what the instructions say to do on expiry. Posting to the channel that a ticket is waiting on a human is usually better than silence.

Next