How to decide which support actions an AI agent may take alone

Sort tickets before the agent acts

The first decision is not about the model. It is about the actions. List what your support workflow can do to a customer, and sort each action by one question: can it be undone cheaply? A reply that answers a question is cheap to correct. A refund, a cancellation or an address change on a shipped order is not.

Then classify each ticket before anything acts on it. The ai.classify node picks one label from a fixed list you set and returns it with a confidence score. The approval-gate template ships with three labels, low_risk, needs_review and high_risk, and runs the classification at temperature zero, so the same text gets the same answer.

• Answer-only tickets: order status, delivery questions, how-to questions. The agent replies without a person in the path.
• Reversible changes: a note on the account, a tag on the ticket. Usually safe unattended, and visible on the trace afterwards.
• Money and irreversible changes: refunds, cancellations, credits. These wait for a person, every time, whatever the classifier says.

Draw the tool boundary on the node

The cheapest control is the one that makes a mistake impossible. The ai.agent node can act only through the tools you give it, so the tool list is the boundary. In the support-agent template the agent has two: a clock and a read-only get_order HTTP tool that fetches one order by its id. It can look things up. It cannot change anything.

• Give the agent read tools freely and write tools sparingly. An agent that has no refund tool cannot refund.
• Set the iteration limit and the per-tool timeout on the node. The template sets both, so a stuck lookup ends the loop instead of extending it.
• Let a failing tool fail softly. A tool that raises does not fail the step; the error text goes back to the model, which may retry or answer without it.
• Put the risky write after the agent, as its own node, behind the approval. The agent drafts; the workflow executes.

Treat confidence as a routing input, not a verdict

A classifier’s confidence is a number the model reports about its own answer. It is useful for routing and useless as proof. Use it to send uncertain tickets to a person sooner, never to skip a person on an action that needs one.

The approval-gate template puts both the label and the confidence into the reviewer’s prompt, so the person deciding can see how sure the screen was. For extraction, the clarification template goes further: when the model’s confidence falls below the threshold set on the node, the run pauses and asks a person to pick from the candidates. Here is how a set of synthetic tickets moves through the combined workflow:

ticket  “Where is my parcel?” (order id supplied)
  screen    low_risk      agent calls get_order, replies
  approval  none

ticket  “I was charged twice, please refund one.”
  screen    needs_review  agent drafts refund reason
  approval  Approve refund → approve → refund issued, reply sent

ticket  “Cancel everything and close my account.”
  screen    high_risk     agent drafts, takes no action
  approval  Approve cancellation → no answer → timeout branch
  fallback  ticket assigned to a person, customer told it is in hand

The approval step, its timeout and the fallback

A human.prompt step suspends the run until a person answers or its timeout lapses. It shows the approver the question you wrote and the choices you set; in the template those are Approve and Reject, and a control.branch node routes on the answer to one email or the other. The decision is recorded with the run.

• Timeout. Set one on every approval step. Left blank, a step waits forever, and a refund nobody looks at becomes a complaint nobody answers. The template sets one.
• Fallback. Decide what the timeout means before it happens. In the template as shipped, no answer fails the step and the run, and the failed step is kept with its input and error. For support, route the timeout branch to a person or a queue instead, and tell the customer what happens next.
• What the approver sees. Put the draft action in the prompt text: the amount, the order, the reason the agent gave. A person asked to approve something they cannot see is not an approver.

Approval adds the approver’s response time to every ticket that needs one. That is the trade you are making, and it is worth making only on the steps that cannot be undone.

Inspect the runs, then move the line

Every model turn and tool call the agent makes is recorded in the run trace, with tokens, latency and cost, and a failed step is kept with its input and error. Run your synthetic tickets first, then read the traces rather than the replies. Look for three things: tickets the screen labelled low_risk that a person would have held, approvals that were always granted, and timeouts that nobody noticed.

The first tells you the classifier needs better labels or a stricter route. The second tells you an approval may be ceremony and could become a reversible, unattended step. The third tells you the fallback is not reaching anyone. Move the line in small steps, and read the traces again after each one.

Prerequisites, limitations and a next step

• Prerequisites: a model provider connection for the screen and the agent, an email connection such as SendGrid or SMTP, a way for your help desk to call a webhook, and a person who owns the approvals.
• The agent cannot look up what no tool returns. If the order API is down, the agent says so or answers without it.
• An approval records a decision, not that the decision was right. It is a control, not a guarantee.
• When the AI budget is reached, the agent stops and tickets go to people. Keep a human queue staffed for that and for the timeouts.

The customer support solution shows the full shape: a ticket trigger, the agent with order lookup, a refund branch behind an approval, and a reply on the same ticket. The AI page covers budgets and approvals in more depth. If you want to see it run, book a demo: we start from the support-agent template, add an approval with a timeout, and read the trace of the first run with you.