Designing the Support Agents
Design Meridian’s support workflow around representative-reviewed general billing guidance. Screen requests before agent execution, retrieve approved policy excerpts, and route account-specific, ambiguous, conflicting, or unsupported questions to an acknowledged human recipient. Exclude account tools, autonomous customer messages, and writes from the pilot. Treat account access, plan changes, and voice as separate phases requiring authorization and verification. Evaluate routing and interruption-state failures separately, distinguish constructed replay results from deployed performance, and require approved guidance, staffed fallback, accepted owners, and release gates before any pilot.
A design review for a support agent usually turns on one question: what happens when the request isn’t the one you planned for? A confused customer, a handoff to the wrong agent, or a person who never picks up an escalation can each push a draft past the boundary Meridian agreed to. This lesson designs the agents for Meridian’s pilot: triage and drafting, human escalation, tool access, a later voice channel, and the evals that decide launch. Each part has to keep account access and customer-facing actions outside the system while still giving representatives a useful draft.
How does a request flow through the agents?
The first release is still chat drafts for general billing guidance, reviewed by a representative. Account-data access, account or ticket writes, replies sent without a representative, and voice are all excluded. The 40-contact pilot and 40-contact manual comparison from the previous lesson haven’t been run.
An application entry point receives the representative’s request and screens it against the agreed scope before any agent runs. A request is eligible only if it’s a general question, an approved policy version covers it, and the guidance doesn’t conflict. If the application can’t confirm all three, it sends the request to a person instead of guessing. The diagram shows both paths.
For an eligible request, a triage agent hands the turn to a general-guidance specialist. The specialist calls a read-only tool that retrieves an approved, versioned policy excerpt, and returns a draft that cites it. The representative reviews the draft, then corrects or sends it in the existing workflow.
In the Agents SDK, a handoff makes the specialist the active agent for the rest of the turn. It doesn’t transfer work to a person or grant access to customer systems. The SDK provides agents, tools, handoffs, and tracing; Meridian’s application still owns authorization and release decisions.
A fixed screen-then-draft workflow, with no triage agent, is a credible alternative. Compare the two on routing errors, draft quality, latency, and operating effort. If the extra handoff doesn’t improve the workflow enough to pay for another model call and another context transfer, use the fixed workflow.
How does escalation reach a person?
A human escalation is a work item the application sends to a named recipient, who acknowledges it. The application stops drafting for an account-specific question, a plan change, a policy conflict, an unsupported question, or an ambiguous request. It then presents a work item to the current representative or to a queue Meridian has agreed to staff.
The work item carries a short summary built from allowed fields, the escalation reason, the relevant policy references, and enough context to continue. It leaves out credentials and any account data the recipient doesn’t need. The application records the acknowledgment, because a sent message or an agent handoff doesn’t prove anyone received it. If the recipient is unavailable or doesn’t acknowledge, ...