AI for Call Centers: Architecture, Handoffs, and QA

AI for call centers is useful when it owns a specific part of the service journey, not an unrestricted promise to "handle support." A voice agent might answer an approved policy question, reschedule an appointment through an API, or collect the reason for a call before transferring it. An employee-facing assistant might retrieve a knowledge-base passage or draft after-call notes. A post-call model might assign a small set of reviewable labels.

Each pattern has different risks. A customer-facing agent can say or do the wrong thing in real time. An agent-assist tool can distract an employee with a bad suggestion. Post-call analysis can quietly pollute operational data. The deployment design should state which pattern is in scope, which system holds the truth, and who owns the case when AI reaches its limit.

Choose a transaction, not a department

The best first workflow has a known start, a small number of valid paths, and a result that another system can confirm. Examples include:

• checking business hours or an order status from an authoritative service;
• rescheduling an existing appointment within returned availability;
• collecting a structured reason for contact and routing the call;
• answering questions from a versioned, approved policy set; or
• confirming that a requested follow-up was created.

"Resolve billing" is not a bounded workflow. It can include identity verification, payment data, refunds, contract interpretation, hardship, fraud, and complaints. Break a broad queue into transactions and risk-rate each one. A low-risk status lookup may be appropriate for AI even when a disputed charge remains human-owned.

A transaction specification should define:

1. the inputs the agent may request;
2. the source that can answer each factual question;
3. the actions an integration may take;
4. prohibited statements and actions;
5. transfer triggers and destinations; and
6. the final state that proves completion.

Without that specification, a polished conversation can conceal an incomplete or unauthorized task.

Separate the three call-center AI patterns

Customer-facing self-service

The AI speaks directly with the caller and may use tools to read or update a business system. It needs strict action boundaries, identity and authorization rules where applicable, and an immediate route to a person. This pattern carries the highest live-interaction risk.

Employee assistance

The customer still speaks with an employee. AI may search approved content, suggest a response, or populate a draft form. The employee remains responsible for checking the suggestion before using it. Measure whether the assistant produces relevant support without increasing handle time or error rates.

Post-call operations

AI processes a transcript or other call artifact after the conversation. Summaries, reason codes, quality flags, and follow-up suggestions can reduce manual classification work, but they are generated data. Validate them against a representative human-labeled sample before they drive coaching, staffing, customer treatment, or performance decisions.

These patterns can work together, but combining them in the first release makes failures harder to diagnose. Pilot one transaction and one operating pattern at a time.

Build the conversation around system state

Take a rescheduling workflow. The model's role is to conduct the conversation. The scheduling service determines what is actually possible.

1. Establish scope. The agent identifies the organization and says it can help with an existing appointment. If AI disclosure is required by policy or law, it belongs in the opening.
2. Apply the approved verification step. The application, not the prompt, decides what verification is sufficient. Do not ask for extra personal data because it might be useful later.
3. Read current state. A narrow tool returns the appointment, eligible actions, and any restrictions. If the system is unavailable, the agent does not guess.
4. Offer valid options. Another tool returns available slots. The model can present them in plain language, but it cannot invent a time outside that response.
5. Confirm before writing. The caller chooses a slot and hears a concise confirmation. A write endpoint receives the appointment ID, selected slot, and an idempotency key to prevent duplicate changes.
6. Verify completion. The system returns a confirmed result. Only then does the agent state that the appointment changed.
7. Transfer exceptions. Conflicting records, repeated tool failures, an explicit request for a person, or anything outside the transaction goes to the correct queue with context.

This arrangement protects the source of truth. The model interprets language; deterministic services enforce identity, inventory, permissions, and state changes.

Treat human handoff as a product path

Transfer is not an error to hide. It is the expected result for requests outside scope, low-confidence understanding, policy exceptions, vulnerable callers, complaints, and actions that require employee judgment.

A handoff design needs more than a phone number:

• Trigger: explicit request, unverified identity, unsupported intent, tool failure, policy keyword, or conversation loop.
• Destination: queue selected by business rules and current availability, not by an unconstrained model guess.
• Brief: verified identity state, caller's stated reason, actions already attempted, and tool results. Label model-generated summaries as such.
• Caller experience: what the caller hears, how long the system waits, and what happens when nobody answers.
• Failure path: callback creation, voicemail, alternative queue, or a safe end to the interaction.

Review transfer calls as a distinct test set. A system can report a high transfer "success" rate while callers repeat everything, reach the wrong team, or disconnect during the bridge.

Integration details determine reliability

The model should never be the only place where a business rule lives. Put operational controls in the application layer:

• Define tool inputs with enumerated values, length limits, and required fields.
• Authorize every read and write on the server. Do not trust a value because the model supplied it.
• Return explicit states such as not_found, not_eligible, or service_unavailable instead of ambiguous prose.
• Set timeouts and safe fallbacks. A delayed account lookup should lead to retry or transfer, not a fabricated answer.
• Make writes idempotent so repeated requests do not create duplicate credits, bookings, or cases.
• Keep secrets and unrestricted database access out of prompts and tool arguments.
• Reconcile conversation outcomes against the CRM, ticketing, order, or scheduling system that owns the record.

Minimize data at every boundary. A routing workflow may need the stated issue and language preference, but not a full transcript of earlier calls. In jurisdictions governed by the EU General Data Protection Regulation, Article 5 includes purpose limitation, data minimization, accuracy, storage limitation, and security principles. Map comparable obligations for every location and sector in which the service operates.

Test conversations and transactions separately

Call reviews should answer two different questions: Did the conversation behave acceptably, and did the business transaction finish correctly?

Build a test set from real call shapes after removing or protecting personal data. Cover accents and speech variation relevant to the served population, interruptions, background noise, silence, ambiguous dates, corrections, repeated questions, tool timeouts, unavailable destinations, explicit human requests, and attempts to move outside scope.

Score observable criteria rather than general "naturalness":

Average handle time and containment rate can help with capacity planning. Neither is a goal on its own. Short calls can be unresolved, and high containment can mean the system blocked access to an employee. Track first-contact resolution and repeat contact by transaction type, then compare them with an appropriate baseline.

The NIST Generative AI Profile is a voluntary companion to the AI Risk Management Framework. It provides a useful structure for identifying generative-AI risks and planning governance, measurement, and management activities. Translate that structure into named owners, test cases, thresholds, incident handling, and review dates for the actual call-center workflow.

Apply communication and recording rules before launch

Inbound service, outbound support, collections, sales, health care, and financial workflows do not share one compliance checklist. Requirements depend on the purpose of the call, the recipient, the data, the jurisdiction, and the systems involved.

For U.S. outbound calls, the Federal Communications Commission determined that AI-generated voice is an artificial or prerecorded voice under the Telephone Consumer Protection Act. The applicable consent and identification rules therefore need review before dialing. The Federal Trade Commission's Telemarketing Sales Rule guidance explains federal requirements and exemptions, and it also notes that state recording laws vary.

Before traffic reaches the workflow, assign owners for:

• call eligibility, consent evidence, calling hours, and do-not-call requests;
• AI and caller-identification disclosures;
• recording or transcription consent and retention;
• authentication and access to account data;
• payment, health, financial, or other regulated information;
• accessibility and an effective human alternative;
• complaints, incidents, and correction of bad downstream data; and
• vendor access, subprocessors, deletion, and contract obligations.

Legal review produces requirements; engineering makes them executable; operations verifies they continue to work.

Where Dasha fits in the call-center stack

Dasha supplies a managed runtime and APIs for voice AI agents. It does not replace your contact-center routing, workforce management, CRM, ticketing, identity, or compliance program. A production design has to connect those systems and define which one owns each decision.

For bounded transactions, external tools let an agent call webhook-backed functions whose parameters are defined with JSON Schema. Dasha documents cold, warm, and HTTP-routed transfers; the appropriate method depends on whether the employee needs a briefing and whether your routing service must choose the destination. Webhooks report conversation lifecycle events to your application.

Completed calls can be examined in the Call Inspector, including transcripts, model interactions, tool executions, and a timeline. Activity Logs cover call lifecycle, webhook, tool, and configuration events. Teams connecting their own telephony provider can review Dasha's SIP credential and trunk configuration, including transport and call-pacing fields.

Use those components to run a transaction-level pilot. Keep the first release narrow, sample both successful and transferred calls, reconcile every claimed completion with the source system, and expand only when the workflow meets its quality, safety, and customer-impact gates.

Create a Dasha account when you are ready to test a defined voice workflow with your own integrations and acceptance criteria.