Automation  ·  AI operations

How to build an AI agent handoff to a person

The agent cannot solve it, says so, and tells the employee to raise a ticket. They do, and the person who picks it up asks them to explain the problem from the start. Here is the model behind a handoff that carries the work across, the prompts that build it, and what it takes to run in production.

Built with Tray Headless

  1. System Agent
  2. Step Stop rules
  3. Step Package the case
  4. Step Route to the owner
  5. System ServiceNow
Also Learn from the handoff

The agent stops on clear rules, and the person receives the whole case, so nobody asks the user to start again.

The short answer

What is an AI agent handoff to a person?

An agent handoff to a person has four parts: rules for when the agent stops, a case passed across with everything the agent learned and tried, routing to the team that owns the problem, and a message telling the user what happens next. The part teams skip is the case. An agent that hands off by telling the user to raise a ticket has saved nobody any time, because the person who picks it up starts from nothing.

Stage 4 of 5: Hand off to a person. Part of AI agent deployment, end to end : every stage, the systems it runs on and the guide that builds it.

What matters here

  • Stop on rules you can read, such as missing access, a request outside the agent's job, or two failed attempts, rather than on how sure the model feels.
  • Pass the whole case: the request, what the agent found, what it tried, and why it stopped. Nobody should ask the user to repeat themselves.
  • Route by who owns the problem, using the same rules your service desk already uses.
  • Tell the user who has it and what happens next, in the same conversation.
  • Treat every handoff as data. The common ones are the agent's next job.

Who this is for

You run an AI agent that answers employees or customers. Some requests it cannot or should not complete, and right now those land on a person with no context.

How it works in practice

What happens between the agent deciding it should stop and a person picking the work up.

  1. 1

    A stop rule is met

    The request is outside the agent's job, it lacks the access, it failed twice, or the user asked for a person.

  2. 2

    The agent writes up the case

    The request in the user's words, what it looked up, what it tried, and the reason it stopped.

  3. 3

    The case is routed to the owning team

    By the same category and assignment rules the service desk uses, with priority carried across.

  4. 4

    The user is told what happens next

    Who has it, the ticket number, and when to expect a reply, in the same Slack thread.

  5. 5

    The person picks it up with full context

    They start from the agent's notes, not from a blank ticket.

  6. 6

    The outcome comes back to the agent's owner

    How it was solved, so the common handoffs can become new tools or knowledge.

What a handoff is made of

Four parts. The second is the difference between a handoff and a dead end.

Stop rules

Written down and checked by the workflow: outside the job, no access, repeated failure, a sensitive topic, or the user asking for a person. How confident the model sounds is not on the list.

A complete case

The original request, the records the agent read, the steps it tried with their results, and its reason for stopping, attached to the ticket.

Routing to the owner

The same categories and assignment groups the service desk already runs on, so handoffs join the normal queue rather than a new one.

A message to the user

Who has the request, the reference number, and what happens next, sent in the conversation where they asked.

The Tray Headless prompts

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

  1. 1

    Start here: write the stop rules

    The agent needs to know when to stop before it needs to know how.

    Headless skills build-workflow 

    Use build-workflow.

Define the rules that make the agent stop and hand off. Check them in
the workflow after every step, not only in the agent's instructions:

  The request is outside the agent's listed job
  A tool it needs is not available to this user
  The same step has failed twice
  The topic is on a sensitive list, such as legal, HR complaints or
    security incidents
  The user asks for a person, in any wording

Do not use the model's own confidence as a stop rule. A model is often
most confident when it has misunderstood the request.

    Asking for a person should always work on the first try. An agent that argues with a user who wants a human loses that user's trust for good.

  2. 2

    Write up the case before handing off

    So nobody asks the user to start again.

    When a stop rule is met, have the agent write a short case summary in a
fixed shape:

  Request: the user's own words, unedited
  Who: name, team, and the account or record it concerns
  Found: what the agent looked up, with links to the records
  Tried: each step it took and the result
  Stopped because: the rule that was met

Attach the full conversation and tool log to the ticket as well, so the
summary can be checked against what actually happened.
  3. 3

    Route it the way the service desk already does

    Handoffs belong in the normal queue.

    Headless skills tray-patterns 

    Use tray-patterns.

Create the ticket in ServiceNow, or Zendesk for customer requests, using
the existing categories and assignment groups. Map the agent's category
to the service desk category rather than inventing new ones.

Carry priority across: a request the user marked urgent, or one that
blocks their work, keeps that priority.

If the ticket cannot be created, post the case to the owning team's
Slack channel and tell the user that a person has it, so a failed handoff
never leaves the user waiting on nothing.
  4. 4

    Tell the user what happens next

    Silence after a handoff reads as being ignored.

    Reply in the same Slack or Teams thread where the user asked:

  That a person is taking it from here, and which team
  The ticket number, linked
  When to expect a reply, based on the team's usual response time

When the ticket is updated or closed, post the update in the same
thread, so the user does not have to go and look for it.
  5. 5

    Learn from every handoff

    The common handoffs are the agent's next job.

    When a handed-off ticket is closed, record in Snowflake: the stop rule
that fired, the category, how the person solved it, and how long it
took.

Report weekly to the agent's owner:

  Handoffs by stop rule and category
  The most common requests that ended in a handoff
  Handoffs a person solved in a few minutes with a standard fix

The last group is where a new tool or a new knowledge article would let
the agent finish the job next time.
  6. 6

    Test it, then hand the rules over

    Because what the agent should stop on will change.

    Run the per-step checks and the whole-workflow audit. Test each stop
rule with a request that should trigger it, including a user asking for
a person in an unusual way, and confirm the ticket, the case summary and
the reply to the user all arrive.

Then open the same workflow in Tray Build so the service desk can adjust
stop rules, categories and routing in the visual canvas.

What it connects to

The agent stops, the case moves, and the user hears what happens next.

Slack

Where the user asked, and where they hear who has their request and every update after.

Reads and writes

ServiceNow

Create the ticket in the right category and group, with the agent's case summary and full log attached.

Writes

Zendesk

The same handoff for customer-facing agents, into the support team's existing queues.

Writes

Microsoft Teams

The same reply and updates for users who work in Teams.

Reads and writes

Snowflake

Record every handoff and its outcome, so the common ones can become the agent's next job.

Writes

Same build, other stacks

The design does not change if you run something else in one of these seats. The same prompts build it against Google BigQuery, Google Chat, Jira, Databricks, Jira Service Desk or AWS Redshift.

Connections in this build

Field mapping, templates and common problems for each pairing: ServiceNow + Slack, Slack + Zendesk, ServiceNow + Zendesk and ServiceNow + Microsoft Teams.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Running it in production

A handoff is where trust in an agent is won or lost.

Stop rules run in the workflow

They are checked as steps, so a change to the agent's instructions cannot quietly remove them.

A failed handoff still reaches a person

If the ticket cannot be created, the case goes to the team's channel and the user is told, rather than waiting on nothing.

The case and the log travel together

The person picking it up can read what the agent did, step by step, and check the summary against it.

The service desk owns the routing

Stop rules and categories open in Tray Build, so the team that receives handoffs decides where they go.

Handoffs feed the roadmap

The weekly report shows which requests a person solved quickly, which is the list of what the agent should learn next.

Questions people ask

When should an agent hand off?

When a written rule is met: the request is outside its job, it lacks the access, a step has failed twice, the topic is sensitive, or the user asks for a person. Not when the model says it is unsure.

What should the person receive?

The user's request in their own words, what the agent looked up, each step it tried with the result, why it stopped, and the full conversation log.

Should handoffs go to a separate queue?

No. They should join the service desk's existing categories and assignment groups, so the right team gets them without a new process to watch.

What does the user see?

A reply in the same thread saying which team has it, the ticket number and when to expect an answer, then each update as it happens.

How do handoffs make the agent better?

Every closed handoff records how it was solved. Requests a person fixed quickly with a standard answer are the next tool or knowledge article to give the agent.

Further reading

Background on the same subject, for the case rather than the build.

Related guides

AI operations

How to build human approval for agent actions

Decide what needs approving by blast radius, show the approver what will happen, expire cleanly, and keep the record. The Headless prompts that build it.

AI operations

How to test an AI agent before release

Build a test set from real requests, score what the agent did as well as what it said, set a pass bar per category, and run it on every change. The Headless prompts that build it.

AI operations

How to build AI support deflection

Answer only what the knowledge base actually covers, escalate early with the context, and measure resolution rather than deflection. The prompts that build it.

Last reviewed October 2026.