A Sample Machine-Agent Pilot: Support Triage With Receipts

Customer support is one of the best places to pilot machine agents — and one of the easiest places to make a quiet mess.

A support agent can save hours by sorting tickets, checking account state, finding policy references, and drafting replies. It can also invent refund policy, miss a VIP escalation, expose private account details, or send a confident answer based on stale context.

The right first pilot is not “let AI handle support.” It is narrower:

Let the agent classify inbound tickets, check approved sources, draft responses for human review, route exceptions, and produce a receipt for every recommendation.

The buyer-safe pilot

The agent does not send customer messages, issue refunds, promise roadmap changes, change account settings, update subscription state, or override policy during the first pilot.

That is the whole point. The pilot proves whether the agent can classify, ground, escalate, and explain itself before it gets customer-facing authority.

Scope the pilot like this

• Input: 50-100 recent tickets from one product area, approved help-center docs, account metadata export, plan/tier field, and escalation rules.
• Allowed actions: read approved sources, classify ticket type, identify likely answer, draft customer reply, draft internal note, create an exception queue, produce a receipt.
• Forbidden actions: send replies, change account data, grant credits, cancel/upgrade subscriptions, promise timelines, access unapproved PII, or resolve tickets without review.
• Human checkpoint: support lead approves every customer-facing message and every ticket-status update.
• Success metric: reduce first-pass triage time by 40-60% with zero unauthorized sends and clear receipts for every recommendation.

The source-of-truth map

Support workflows fail when the agent treats Slack chatter, old docs, CRM notes, customer claims, and live system state as equally authoritative.

Make the precedence rules explicit:

• Product behavior: current help-center docs or approved release notes win.
• Account plan/tier: billing/account export wins.
• Customer entitlements: contract or billing system wins; ticket text is a claim, not truth.
• Refund/credit policy: approved policy document wins.
• Escalation status: latest support-lead note wins.
• Conflicts: queue an exception; do not guess.

The agent should never silently convert an old answer into current policy. In support, stale context becomes a customer promise.

The exception queue is the safety layer

A useful support agent should know when not to answer.

Queue these instead of drafting a confident response:

• the customer asks for refunds, credits, cancellations, or legal/compliance commitments
• the ticket contains anger, threat of churn, press/social escalation, or executive involvement
• the answer depends on account state the agent cannot verify
• the help docs conflict with recent release notes
• the customer includes sensitive personal or financial information
• the agent confidence is below the agreed threshold

Exceptions are not noise. They are how the agent preserves trust while still reducing the manual triage load.

What the agent should output

For each ticket, the agent should produce something closer to an operations receipt than a loose summary:

The draft reply is only half the value. The receipt is what lets a lead approve quickly without redoing the agent’s entire reasoning path.

The rollout plan

1. Week 0: replay test. Run the agent on historical tickets and compare classifications/drafts against actual human resolution.
2. Week 1: live draft-only triage. Agent prepares categories, drafts, and receipts. Humans approve every outbound message.
3. Week 2: narrow queue expansion. Add one more ticket category only if exception handling and receipt quality are strong.
4. Week 3+: increase volume before authority. Let the agent handle more tickets, not more permissions. Customer-facing autonomy comes later, if ever.

The dangerous move is giving send authority because drafts look good. Draft quality is not the same as operational reliability.

What not to automate first

Do not start with workflows where the agent can:

• send replies without review
• issue refunds or credits
• change subscription/account state
• make security, legal, or compliance claims
• handle angry VIP/escalated customers autonomously
• write durable customer facts into CRM memory without approval

Those may become future phases. They are not the first pilot.

The approval memo

Do not ask a support leader to approve “an AI support agent.” That sounds like uncontrolled customer risk.

Ask for this instead:

“We are running a two-week draft-only support triage pilot for one ticket category. The agent has read-only access to approved docs and exports, no send authority, no account-write authority, mandatory exception routing, and receipts for every recommendation. Success is faster first-pass triage with zero unauthorized customer actions.”

That is an approvable pilot. It creates speed without pretending the agent is ready to represent the company unsupervised.

For a buyer-facing approval memo, use the Machine Orchestration Pilot Proposal Template. For a broader artifact router, start at Start Here.

The production question is not whether agents can help support teams. They can.

The question is whether the first pilot proves grounding, escalation, and receipts before customer-facing autonomy.