Payments Support Agent: Role, Channels, Completion Criteria, and Human Handover Boundaries

Hello, and welcome to the first lesson of the course. We begin with the design decision that makes every later layer testable: defining exactly what the payments-support agent is for, how customers reach it, what “done” means, and the point at which the agent must stop and involve a person.

This module will use a deliberately narrow reference agent: a retail payments-support agent in web chat. Narrowness is a feature at this stage. A vague ambition such as “help with payments” cannot be evaluated, while a concise operational specification can later be turned into concrete evaluation cases.

By the end of this lesson, you will have a four-part specification that can serve as the baseline for the evaluation inventory in the next lesson.

---

1. A specification is an operational contract, not a prompt

Before writing instructions, choosing a model, or connecting payment systems, establish the agent’s operating contract. It answers four questions:

1. Job: Who does the agent serve, what may it do, and what must it not do?
2. Channel: Where does the conversation occur?
3. Completion condition: What observable result counts as a completed interaction?
4. Handover boundary: Which situations must be routed to a human, and what happens when they are?

This is not the agent’s full system prompt. A system prompt later contains detailed workflow, tone, tool-use rules, and fallback language. The specification sits above that detail: it makes the scope and accountability decisions that prompt-writing must obey.

A specification that is too vague produces untestable expectations:

“The agent helps customers with payment problems and escalates complex issues.”

What is a payment problem? What makes an issue complex? Does a refund request count? Does an explicit request for a human override the agent’s ability to answer? Different people will answer differently, which means later evaluation results will be arguments rather than evidence.

A specification that is too detailed causes a different problem:

“The agent greets customers warmly, asks for a reference number, retrieves payment status, provides a three-sentence answer, adds a citation, offers a survey, and then logs the interaction…”

That may be useful prompt or workflow material later, but it mixes high-level product decisions with implementation. It will change frequently as the agent is tuned.

The useful middle level names:

• the customer group and permitted domain;
• the channel’s operational constraints;
• the observable outcome the agent is responsible for;
• the cases in which it has no authority to continue.

The OpenAI Help Center’s description of AI phone support is a useful contrast. It is explicit about both what the phone agent can answer and what it cannot submit, escalate, or guarantee. Its important design lesson is that a handover boundary need not always mean a live transfer: an agent may instead route a customer to a named workflow. What matters is that the boundary is clear and truthful.

---

2. Define the four parts precisely

The job: authority before capabilities

Start with one sentence that identifies:

• who the agent serves;
• which customer goals it can address;
• the source of its authority, such as approved policy or verified system data;
• where its authority ends.

For the course reference agent, we will use this job statement:

The agent supports retail customers with payment-status questions and published payment-fee questions, using approved knowledge and verified account data; it does not approve, reverse, dispute, or initiate payments.

This statement is useful because it makes several later decisions possible. It separates informational support from actions that change money movement or make a financial decision. It also establishes grounding: the agent is not entitled to fill gaps from general model knowledge.

Notice what the sentence does not include:

• a specific tool name;
• an exact greeting;
• a claim that the agent resolves every issue;
• subjective language such as “provide excellent support.”

Those are either future implementation choices or claims that cannot be graded reliably.

The channel: a product constraint, not a delivery detail

The same job can be safe and useful in one channel yet unsuitable in another. A voice agent must account for turn-taking and caller patience. Email may support longer, asynchronous cases. Web chat can show links, preserve a visible history, and support a relatively structured transfer to a specialist.

For this course, the channel is:

Channel: authenticated web chat within the customer payments portal.

“Web chat” alone is better than leaving the channel unstated, but the portal context matters too. It tells the design team that account context may already exist and that the agent can provide a handover with a visible conversation record. It does not automatically grant permission to expose account information; identity verification and data access remain design requirements for later layers.

Channel affects the specification in three practical ways:

Channel question	Why it belongs in the specification
Where does the customer start the conversation?	It defines the population, available context, and authentication assumptions.
What kind of response is realistic?	It sets expectations for response length, interaction speed, and transfer experience.
How can the customer reach a person?	It determines whether the agent transfers, creates a case, provides a route, or all three.

Completion: define an outcome, not a reply

A common but weak completion condition is:

“The interaction is complete when the agent has responded.”

That merely measures that the model generated text. It says nothing about whether the customer received a supported answer, whether required information is missing, or whether an out-of-scope request was safely routed.

A stronger completion condition distinguishes two legitimate endings:

1. Resolved within scope. The agent has supplied a grounded answer to the customer’s current in-scope question, and no required information or action remains.
2. Transferred correctly. The agent has initiated the appropriate human route, communicated what will happen next, and passed the necessary context.

For our reference agent:

A conversation is complete only when the customer has received a grounded answer to their current in-scope payment-status or fee question, with no information still needed from either party, or when the agent has completed the appropriate handover and explained the next step.

This wording rules out several false successes:

• giving a plausible but unsupported answer;
• asking for information and then ending the conversation;
• saying “I’ll escalate this” when no transfer or case route was actually initiated;
• treating a customer’s silence after an unhelpful reply as resolution.

“Grounded” will become technically important in the data layer. For now, it means the answer rests on an approved policy source or verified live result rather than a guess.

The handover boundary: specify triggers and destination

A handover boundary is not merely a list of difficult topics. It is a statement of authority. The agent must hand over when continuing autonomously would be unsafe, unauthorized, unsupported, or counter to the customer’s expressed preference.

A practical handover rule contains four elements:

Element	The question it answers
Trigger	What customer request, risk, or failure requires handover?
Destination	Which team, queue, or approved workflow receives it?
Action	Does the agent transfer, create a case, or provide a named route?
Context	What does the receiving person need to avoid restarting the conversation?

Avoid phrases such as “escalate when appropriate” or “hand over complex issues.” Replace them with observable triggers. For a payments-support agent, useful categories are:

• Customer preference: the customer explicitly asks for a person.
• Authority boundary: the customer asks for a refund decision, dispute outcome, payment reversal, or other action outside the agent’s authority.
• Safety or security boundary: suspected unauthorized payment, account compromise, fraud concern, or a privacy or regulatory complaint.
• Knowledge boundary: the requested information is not covered by an approved source or cannot be verified.
• Failure boundary: the agent has made two unsuccessful attempts to resolve an in-scope request.

The last category needs care. “Unsuccessful” should not mean that the customer simply disliked a policy answer. In this course, it means the agent could not obtain the information required to answer, or the customer states that the proposed in-scope resolution did not address their request.

The human-handoff resource gives two especially durable design rules: honor direct requests without making customers argue for them, and define a failure trigger rather than allowing an unproductive conversation to continue indefinitely.

A good specification also says what happens if the preferred human route is unavailable. Otherwise, the agent may claim a transfer happened when it did not.

For example:

If the payments-specialist queue is unavailable, the agent must state that it could not complete the transfer, provide the approved alternative contact route, and avoid promising a callback, case number, decision, amount, or timeframe that it cannot verify.

This is a boundary, not pessimism. It prevents a failed transfer from becoming a misleading assurance.

A “warm handoff” requirement should be concise and privacy-aware:

For every handover, pass the conversation summary, detected intent, handover reason, relevant verified identifiers already available to the specialist, and actions or checks already attempted.

The phrase relevant verified identifiers matters. A handover should preserve enough context to prevent repetition, but it should not become a reason to copy every piece of customer data into every queue.

---

3. Assemble the concise specification

The following is the working specification for the rest of this course. It is intentionally short enough to review with an operations owner or subject-matter expert, yet specific enough to generate evaluation cases.

Agent and channel. The Retail Payments Support Agent serves authenticated retail customers through web chat in the customer payments portal.

Job. It answers payment-status questions and published payment-fee questions using approved knowledge sources and verified account data. It does not initiate, approve, reverse, refund, or dispute payments, and it does not make financial, legal, or regulatory decisions.

Completion condition. A conversation is complete when the agent has given a grounded answer that addresses the customer’s current in-scope question and no required information or action remains, or when it has completed an appropriate handover and explained the next step. Sending a reply alone does not count as completion.

Human-handover boundary. The agent immediately routes to the payments specialist when the customer requests a human; reports suspected unauthorized activity, fraud, account compromise, or a privacy or regulatory concern; requests a refund, dispute, reversal, approval, or other money-moving action; asks for information that cannot be verified from approved sources; or remains unresolved after two unsuccessful in-scope attempts. The handover includes the conversation summary, intent, reason for transfer, relevant verified context, and actions already attempted. If the normal route is unavailable, the agent explains the approved alternative route and makes no unverified promise.

This is not the only defensible specification. A real client may decide that the agent can open a dispute case, that it serves unauthenticated visitors, or that fraud is handled by a dedicated emergency team. The important discipline is to make each decision explicit before building.

A final review checklist

Before accepting a specification, test it against these questions:

• Can a stakeholder name a request the agent should handle and one it must not handle?
• Does the channel name the actual customer setting rather than merely a technology?
• Could an evaluator tell whether an interaction is complete without guessing about the model’s intent?
• Does each handover trigger lead to a named destination or approved fallback?
• Does a direct request for a person override the agent’s desire to continue?
• Does the transfer preserve enough context that a specialist can continue without asking, “What is the issue?”
• Are terms such as complex, appropriately, helpful, and when needed absent or replaced with observable conditions?

If the answer to one of these is no, the specification is still a business aspiration rather than an operational contract.

---

Key takeaways and next step

A concise agent specification has four parts: job, channel, completion condition, and handover boundary. The job defines authority; the channel sets interaction constraints; completion is an observable customer outcome rather than a generated reply; and the handover boundary states exactly when autonomy ends, where the case goes, and what context accompanies it.

For the payments-support agent, the central boundary is clear: it can provide grounded information, but requests involving financial decisions, money movement, security concerns, unsupported information, repeated failure, or an explicit request for a human must leave the agent’s autonomous scope.

Next, you will turn this specification into an evaluation inventory: a systematic list of cases implied by every must, never, tool, knowledge source, and out-of-scope requirement.