Every AI support agent eventually meets a problem it shouldn’t solve alone. What it does next decides whether customers trust it.
Most setups give the agent one escape hatch: escalate to a human. That’s too blunt. A refund request isn’t an emergency, and a billing question doesn’t need a person to take over the chat. Treat every problem as an escalation and your team drowns in handoffs the agent could have handled.
So in Myna, an agent has three distinct moves:
- Help in the thread. Most problems end here.
- Open a ticket when the issue needs tracking. The AI keeps the conversation.
- Hand off when a person has to take over the thread. The AI stops.
Or, as we put it internally: a ticket while the AI is still talking means tracked, and the AI owns the thread for now. A handoff means a human must take the thread, and the AI stops.
A ticket is not the AI failing. Billing questions, refunds and complaints are ticket work, not reasons to escalate.
A ticket a person could have written
Myna isn’t trying to replace your help desk. It has a lean, native ticket that people and AI agents can both create and update, built to map cleanly to the tools teams already use.
Each ticket belongs to a contact and carries a title and description, a status, a priority, a category, an assignee and a due date, plus where it came from: the channel, the conversation, and whether a person or the AI created it. Statuses are fixed (open, in progress, waiting on customer, resolved), so reporting means the same thing in every workspace. Priorities are yours to rename, and each one carries a “resolve within” time that sets the due date automatically.
The rule behind AI-created tickets is the one we care about most: the model is not a form. Every ticket the AI opens has to be complete, the same shape a person would save. And any field your settings own is never filled in by the model:
- Title: written by the AI, or a fixed template with merge fields like the contact’s first name and the ticket number.
- Priority and category: inferred by the agent, or fixed by you.
- Assignee: unassigned, one person, or round-robin. Letting the model pick a person was considered and rejected.
- Always set by Myna: the contact, conversation, channel, opening status, ticket number and due date.
If you’ve fixed a field, the model simply can’t contradict it. And if the agent can’t work out a good summary, the ticket is still created with the customer’s recent messages in its body, so nothing is lost.
The agent sees open tickets before it acts
Duplicate tickets are the classic failure. A customer follows up, and the agent dutifully opens ticket number two for the same problem.
Myna’s answer isn’t a “list tickets” tool the agent might forget to call. Instead, every turn starts with the contact’s open tickets already in front of the agent: number, title, status, priority and category. Seeing that a ticket exists is what makes the agent update it instead of opening another.
Myna then checks again when it saves. Before a new ticket is written, it’s compared against every open ticket for that contact, not just the ones the agent saw. A matching title or a near-identical description returns the existing ticket and writes nothing.
There’s also a ticket limit per contact, one open ticket by default. It’s enforced twice: the create action disappears from the agent once the limit is reached, and the limit is checked again at the moment of saving, in case two messages arrive at once.
Updating follows the same care. If a contact has one open ticket, an update goes to it. If they have several and the agent doesn’t name one, Myna refuses to guess. And a ticket is only marked resolved when the customer confirms the problem is fixed.
Ticket first, handoff last, enforced in code
Our earliest live tests taught us something prompts alone couldn’t fix.
In one, the setup instructions listed billing as a reason to hand off, so a routine refund went straight to a person. We fixed the wording. The agent then did something subtler: it opened a ticket, and in the very next step handed the conversation off anyway. Nobody had asked for a human.
More prompt text wasn’t the answer. So now Myna itself refuses a handoff when a ticket was already opened earlier in the same turn and the customer didn’t ask for a person. The agent is also told not to hand off until it has actually worked the issue, unless the customer asks for someone. If a customer asks for a person, they get one, every time.
What a handoff actually does
Handoffs are driven by situations you write in plain language, like “The contact asks to talk to a person.” When one applies, the handoff happens in a single step:
- The contact is marked Handoff, and an owner is assigned: one person, round-robin, or whoever already owns them.
- A note is added with the trigger, the reason and a short summary, so the teammate picks up with full context.
- Optionally, a ticket is opened too. That’s off by default.
The agent then sends one short confirmation, written by the AI or a fixed message you choose. It doesn’t ask a new question or promise a response time it can’t keep. If the handoff itself fails, the agent won’t promise a person is coming.
Handoffs can also come from the conversation itself. When follow-ups run out, or a conversation hits its message cap, Myna sorts the contact: warm leads get a full handoff, cold ones are marked unresolved without pulling a person in.
The off switch is the same one your team already uses
After a handoff, the agent goes quiet because of the same Takeover switch a teammate flips manually in Conversations. That’s deliberate: one switch, one meaning.
With Takeover on, the agent doesn’t run at all, and nothing else sends on its behalf. But the customer’s messages still arrive and are logged, so your teammate sees everything. Handing back is a person’s decision: switch Takeover off and the agent picks up again.
No false claims about tickets or people
“I’ve opened a ticket for you” is a promise. So is “I’m connecting you with the team.” An agent should never make either unless it happened.
The agent may only claim what the ticket or handoff actually did, and must use the real ticket number, never an invented one. On top of that, checks in code look for ticket and handoff claims in every reply. A claim without a matching action gets one repair; if a false ticket claim survives, the whole reply is replaced with a safe question instead. It’s the same approach we use to stop a failed booking turning into “you’re all set,” described in how tools work inside a Myna agent.
The handoff check only runs on agents that can hand off, so a sales agent’s friendly “let me connect you with a specialist” isn’t flagged as a lie.
Where your team works
On the human side, everything lives in a few places:
- Tickets: a board (Kanban or list) with saved views, filters and export, and an AI badge on every ticket the agent created. Analytics show open and resolved counts, median time to resolve, and median time in each stage.
- Beside every conversation: the contact’s tickets, so a teammate never has to go looking.
- Agent settings: a Ticketing card for numbering, titles, priority, category, assignee and limits, and a Hand Off to Human card for the message, the situations, and who gets the conversation.
The structure, in one line
Help first. Ticket when it needs tracking. Hand off only when a person must take over, and make every one of those steps something the agent can’t fake.
That’s how an AI agent earns the right to handle support: not by never needing people, but by knowing exactly when, and how, to bring them in.
