Allianz annuity agent demo plan¶

Status: Historical plan | Last reviewed: 2026-09-29

The implementation and measured results now live in the demo runbook. This document preserves the original design assumptions; use the runbook for installed configuration and commands.

Use this plan to build the two experiences in Annuity Contact Center Sample Use Cases_Initial Demo.docx: a human representative assisted during a beneficiary death-claim call, and a producer-service voice agent with a visual companion and human supervision. The document's people, contracts, amounts and business rules are demo fixtures. They do not establish Allianz product terms or service commitments.

The plan uses the current environment/vanguard workspace at 987f1fcb, including existing uncommitted GPT Live work. Repository support is evidence of an implementation path; provider access, deployed versions and measured latency still require validation. This planning change creates no agents or live integrations.

Recommended scope: two primary agents, one supporting supervisor Chat agent, two insurance capability packs, two component catalogs with a common theme, and one Allianz branding profile. Rehearse the beneficiary and producer journeys independently: they concern different people and policies.

Asset	Role
Allianz Beneficiary Assist	Native Copilot for Jordan's human-to-human call with Elena
Allianz Producer Services	GPT Live voice agent, speaking as Taylor
Allianz Producer Specialist	Supervisor Chat assistant used by a human reviewer
Beneficiary claims capability	Verified policy context, requirements, claim preparation and follow-up
Producer servicing capability	Policy snapshot, illustration requests, commissions and service notes
Allianz Agent Assist catalog	Existing coaching/answer/form cards plus a claims facts card
Allianz Producer catalog	Policy snapshot, illustration editor, commission and receipt components
Allianz branding profile	Shared colors, logos, typography and surface settings

Scenario 1 experience¶

Jordan conducts the entire call. The Copilot listens to both speakers, offers brief guidance and displays evidence. Jordan can use, adapt or dismiss a suggestion. The Copilot does not send customer communications or submit a claim solely because it inferred an intent from speech.

Use four concurrent behaviors: empathy coaching, grounded suggested answers, claims context/next action, and a claim-intake form. Generate a wrap-up draft at call end. Keep a stable facts panel and one prominent coaching suggestion; make secondary answers expandable so routine updates do not overwhelm Jordan.

Conversation moment	What appears for Jordan
“I'm calling about my husband's policy. I'm not sure what I need to do.”	Acknowledge the loss; slow down; offer one step at a time. Suggested wording: “I'm sorry you're having to work through this. We can take it one step at a time.”
Elena provides identifying details	Intake fields with proposed values, source utterance and confirmation state. Show verification status from the identity service.
“What documents do I need?”	Certified death certificate, claimant statement and government ID; distinguish potentially needed tax/payment information. Include the supporting knowledge passage.
“Do I need to mail everything?”	Contract-appropriate secure submission guidance; offer the written checklist.
“I'm worried I'll miss something.”	Reassurance and a concrete next action: explain the checklist and how missing items are identified. Avoid promising approval or an unchanged timeline.
“How much is the benefit?”	$312,500 estimated gross, including $27,500 rider enhancement. Explain that review can change the final amount.
“Is that what I'll receive?”	Reinforce estimated versus final and gross versus eventual payment.
“Will taxes be taken out?”	Approved process explanation and a claims/tax-team referral; no personalized tax conclusion.
“How long will it take?”	The fixture says approximately five business days after a complete package, expressly for this demonstration.
Jordan closes	Draft checklist, outstanding actions and claim reference CLM-804219, only after the claim tool confirms creation.

Coach conversational behavior as well as wording: allow pauses, avoid repeated condolences, explain one thing at a time, acknowledge a correction, and avoid repeatedly requesting information already confirmed. Use spoken content and conversational context; do not present a clinical or emotional diagnosis.

The knowledge pack contains short, independently retrievable articles for verification, required/conditional documents, secure upload, estimated benefits, the GMDB rider, payment options, tax-question handling, the demo review window and closing. Each has a source ID, revision, applicable contract/jurisdiction and approved wording. Say the acronym as “G M D B” unless the approved glossary specifies otherwise.

Keep knowledge and account data separate. Explanations come from the knowledge pack; balances, beneficiary relationships, verification outcomes and claim status come from tools. Do not embed all private fixture values in the system prompt.

Scenario 1 latency design¶

Define latency as the end of the relevant spoken phrase to the first correct, useful card visibly rendered. Measure both this and STT-final-to-card time; measuring only the model or ignoring transcription would misstate the experience.

Target p95 at or below one second for preapproved empathy/process cues and already-fetched facts. Treat that as an engineering objective to prove, not a model guarantee. A fresh backend lookup or composed knowledge answer may take longer; initially budget roughly one to three seconds and measure the actual distribution. A loading indicator does not count as useful guidance.

Use two concurrent paths:

Path	Work	Intended experience
Immediate cue	Stable transcript prefix → conservative intent/state match → approved cue or cached, authorized facts → card	Early, concise help without waiting for retrieval and prose generation
Enriched response	Finalized utterance → optional query refinement → knowledge/data retrieval → compact structured answer	Source-backed explanation replaces or supplements the cue

An illustrative fast-path budget is 150–350 ms for audio delivery/transcript stabilization, 25–100 ms for trigger selection, 0–100 ms for local/cache access, and 50–150 ms for event delivery/rendering: 225–700 ms total. These are design allocations, not observations; test them on the intended call channel.

The existing Copilot runtime already runs workers concurrently, supports per-speaker triggers, gate bypass, applicability results and stable card identities. However, SuggestionLLMProcessor explicitly excludes interim transcripts from extraction. Its default minimum is two utterances and its default debounce is three seconds. Debounce limits repeated runs; it can suppress a rapid follow-up rather than adding a simple fixed delay.

Configure the initial version as follows:

Use the native Custom Copilot engine and two-channel transcription. Benchmark OpenAI GPT Live Transcribe against the existing Deepgram option on these exact names, IDs, interruptions and dollar amounts.
Set fast coaching to one utterance and zero debounce; bypass the shared model gate. Let its applicability result suppress irrelevant output.
Do not place transcript enhancement or a second model classifier in front of immediate coaching.
If retaining a gate for knowledge workers, make grief, uncertainty, corrections and process concerns actionable. The default question-oriented gate can miss “I'm worried I'll miss something.”
Preload the approved scenario knowledge. Fetch account context only after trusted verification/authorization, then reuse it with an explicit freshness policy.
Keep prompts compact and output schemas small. Add explicit reasoning-effort/output-limit plumbing where needed: the current direct OpenAI Copilot call does not forward those controls.

For the strict sub-second objective, add an opt-in stable-partial trigger with utterance/revision IDs and a deterministic cue selector. Commit account facts and form values from confirmed data/final speech only. Partials may display reversible coaching or start read-only prefetch after authorization; they must not verify identity, submit requests or issue communications.

Add latest-pending-turn processing and stale-result rejection so a slow response cannot overwrite help for a newer question. Combine duplicate cues, retract invalidated partial cues, and apply a display policy that prevents flashing or continuously moving cards. Reconcile partial and final versions of one utterance into one card update.

Instrument audio/phrase timing, first partial, stable partial, final transcript, trigger, lookup, model completion, event publication and browser paint. Report warm/cold p50 and p95, missed cues, irrelevant cues and stale updates, including under expected concurrency.

Scenario 2 experience¶

Use GPT Live 1 (gpt-live-1) for Taylor's spoken interaction and Responses delegation for the initial backend. Current OpenAI guidance separates conversational delivery from reasoning/tool execution and recommends evaluating gpt-6-luna as a starting backend. Keep client delegation available if an existing non-OpenAI backend or custom execution control becomes necessary. [O1–O3]

The voice prompt sets brisk but clear delivery, measured backchannels, interruption behavior, accurate number pronunciation and delegation policy. The backend owns authentication, permissions, policy facts, procedures, tool results, UI actions and review state. Delegate corrections, short answers to an active question, refusals and cancellations as well as initial requests.

Use a single business procedure with optional branches:

Authenticate and authorize. Capture David Chen's producer ID and agency, then obtain a trusted verification result and check access to Helen Carter's policy. Reciting an ID and agency is identification, not a production authentication mechanism.
Load policy context. Fetch cash value, surrender schedule and applicable crediting period together where possible. After authorization, prefetch the commission record in parallel.
Explain the amounts. Display and read $184,320.14 cash value and $2,764.80 surrender charge. A decimal arithmetic tool computes $181,555.34 before taxes, other adjustments or contract-specific deductions; label it an estimate.
Confirm the illustration. Capture the current premium schedule and no additional withdrawals. The producer can confirm or change assumptions by voice or in the companion form.
Review when required. Run the Human Supervision variant below if the servicing tool reports a review requirement.
Submit and track. Submit once after required confirmation/review. Return IFR-291640 from the fixture service. Show submitted status; do not imply that an illustration has already been generated.
Answer the commission question. Show $1,248.60, scheduled for the October 15 processing cycle, subject to final processing and adjustments.
Record and recap. Persist the requested notes, show the actual write outcome, summarize the request and explain delivery through the approved producer channel.

Always display the valuation timestamp, rate period and commission-record timestamp returned by the source. The source document supplies neither a valuation date nor a year for October 15. Choose explicit fixture dates before recording the demo and label them as added demo data.

Allow follow-up questions and corrections during lookup. Reuse the verified session and existing snapshot rather than repeating authentication or re-fetching everything each turn. The backend must recognize cancellation even if the voice agent is interrupted while an operation is in progress.

GPT Live is already integrated in the current workspace, including capability callbacks, supervision notices and A2UI actions. Its adapter documentation identifies caption/evidence waits around consequential tools. A quick conversational acknowledgement and a completed tool result have separate latency budgets; do not shorten verification or confirmation checks to advertise a faster transaction.

Human Supervision demonstration¶

Add a clearly identified variant to Scenario 2: the illustration service reports that a recent premium-schedule change requires a specialist to validate the current assumptions. This exception is an addition to the supplied scenario, not an asserted Allianz rule.

Taylor says: “I'll have a specialist check those illustration assumptions. While that's being reviewed, I can check the commission record.”

The flow is:

The capability creates an operation-scoped review request containing the authenticated producer, authorized policy, current snapshot, proposed assumptions, reason for review and intended action.
Native Human Supervision starts the transcript relay and opens the associated specialist Chat session. Configure the selected request_support tool or asynchronous workflow and the supervisor agent; a capability toggle alone does not implement the business review.
The human sees a compact decision card, relevant call context and the live transcript. Reuse the native ApprovalRequest component where its contract fits.
The reviewer approves, rejects, requests a correction or asks Taylor to clarify something with David. Any changed assumptions are reconfirmed with David before submission.
An authenticated action handler records reviewer identity, operation ID, decision, exact approved inputs and expiry. The execution tool checks this record. An AI summary or injected message containing “approved” cannot grant permission.
The validated result reaches Taylor's backend, which submits the illustration once and announces the actual result. Approval of the request does not guarantee illustration delivery timing, commission payment or policy values.

Use the existing deterministic supervisor conversation and message injection. The supervisor assistant monitors quietly and helps the human understand context; the human makes the decision. Tie approval to the current request revision so a later withdrawal/premium change invalidates an earlier approval.

Make all outcomes demonstrable:

Outcome	Behavior
Approved	Submit once, show receipt, continue the same call
Correction requested	Ask the producer, update the assumptions, obtain a decision on the revised request
Rejected	Explain the permitted next step; keep submission blocked
No response	Offer an authorized pending service request/follow-up; never assume approval
Caller cancels	Cancel pending review/submission and acknowledge the cancellation
Call ends	Expire call-bound decisions; do not act on a late click

The native supervision loop provides transcript relay, resumable Chat and call-end card expiry. Operation-specific approval enforcement belongs in the new servicing capability. If an actual voice conversation with a specialist becomes useful, add External Consult as a separate optional branch.

Multimodal components and Allianz branding¶

Offer David a secure companion surface after obtaining the relevant channel consent. A phone call opens it through the native secure-link flow; a browser rehearsal uses the corresponding preview/emulator flow. Voice-only use remains complete when the producer declines or cannot open it.

Component	Purpose and interaction
`PolicySnapshot`	Policy/client identity, cash value, charge, rate, as-of dates and estimated net calculation
`IllustrationRequest`	Review/edit premium and withdrawal assumptions; confirm; show pending review/submission state
`CommissionStatus`	Amount, processing cycle, freshness and conditional-payment language
`ServiceReceipt`	Illustration reference, recorded requests, secure delivery status and next steps

Use strict, versioned component schemas. Bind displays to tool outputs; send UI actions to the backend with operation/revision IDs. Treat display, selection, confirmation and completed submission as distinct states. Complete each action visibly, and keep voice and UI on the same request revision.

For optional vision input, let David upload an older statement and ask why it differs. A vision-capable backend reads the document date and visible figures, then compares them with the authoritative policy snapshot. Uploaded content is untrusted evidence and cannot replace live values or authorization. GPT Live's voice model itself accepts audio/text; the framework forwards images to the backend. [O1, O4]

Use the Allianz Life US identity as the initial brand assumption because the scenarios are US annuity servicing. Its public production stylesheet declares Allianz Neo, primary-brand blue #003781, action colors including #006192, and white/neutral surfaces. These observations guide the demo; select exact logo variants and font assets from the approved brand package. [B1]

Create one branding profile with the Allianz wordmark, dark-blue header/primary color, white surfaces, restrained borders, clear amount typography and neutral loading text. Disable customer-visible reasoning/tool traces. Avoid decorative animation during claims and financial explanations.

The current branding schema and provider already support logos, colors and CSS overrides. Load the font files explicitly and map the actual inherited font variables used by surface-app and the catalogs; a font-family string alone does not load Allianz Neo. Validate the shell, cards, iframe and supervisor view separately.

Keep Agent Assist cards in an agent_assist catalog and producer components in a multimodal catalog. Share styling tokens, and preserve the framework's one-owning-catalog-per-surface contract. Begin with native coaching/answer/form/summary components; build the claims facts card only where those cannot express the required data clearly.

Capability and data contracts¶

Implement versioned, tenant-scoped capabilities with deterministic synthetic services first. Make the demo resettable. Keep business tools identical when replacing fixture implementations with real APIs.

Pack	Proposed operations
Claims	`get_beneficiary_claim_context`, `get_claim_requirements`, `prepare_claim`, `create_claim`, `issue_secure_checklist`, `save_claim_notes`
Producer	`get_producer_policy_snapshot`, `calculate_surrender_estimate`, `get_commission_status`, `prepare_illustration_request`, `submit_illustration_request`, `get_illustration_status`, `save_service_notes`
Review extension	`request_illustration_review`, `get_review_status`, authenticated reviewer decision action

Reuse native authentication and secure-channel mechanisms; adapt them to the approved producer/beneficiary identity source. The script's spoken identity fields can be retained in the demo, but the fixture identity adapter must return verification/authorization explicitly. Never seed a prompt variable that manufactures authentication or a human approval.

Tool results carry typed amounts/currency, source timestamps, record versions, status, authoritative IDs and applicable limitations. Write tools require server-checked authorization, explicit confirmation where appropriate, current approval evidence where required, and idempotency keys. Failed lookups return unavailable/stale states rather than plausible values.

Important fixture details:

Elena Martinez is beneficiary for Robert Martinez, policy VA-4729816. The $27,500 enhancement is already included in $312,500; do not add it again or infer an undocumented contract value.
Collect sensitive verification inputs through the appropriate secure path. Retain masked outcomes in cards and summaries.
David Chen, producer PR-004781, represents Chen Financial Group; policy VA-5830194 belongs to Helen Carter.
Cash-value subtraction uses decimal arithmetic. Display $181,555.34 as the limited estimate described in the script, not a final surrender quote.
4.25% is the fixture's displayed rate. Confirm actual product/contract terminology before substituting a real Allianz annuity.
Delivery means a secure producer channel. An email notification, if enabled, links there and does not attach the private illustration.
Creation/submission reference IDs come from successful tool results. A planned action, rendered card or supervisor decision is not proof that the write completed.

Model evaluation¶

Task	Starting candidate	Selection test
Two-speaker transcription	GPT Live Transcribe; compare the existing Deepgram integration	End-to-card latency, finalization, names/IDs, money and speaker attribution
Immediate approved cues	Deterministic selection from authored cues	Recall, false triggers, stability on partial corrections
Coaching/extraction/short answers	`gpt-6-luna`, effort `none` once forwarded by the Copilot adapter	Tone, schema correctness, source fidelity and p95 latency
Voice conversation	`gpt-live-1`	Interruptions, number pronunciation, delegation and accurate spoken results
Voice backend	`gpt-6-luna` through Responses, initially low effort	Tool accuracy, confirmation handling, vision and latency
Hard backend cases	Evaluate `gpt-6-sol` only if the smaller model misses required outcomes	Improvement on the same fixtures

OpenAI documents structured output, image input and none reasoning for GPT-6 Luna, and recommends comparing backend quality and latency for Live. These are candidate capabilities, not evidence that this deployment meets the one-second objective. Validate model availability and request-shape compatibility in the tenant integration. [O2–O4]

The existing Live service default is gpt-5.6-terra; explicitly select the intended backend rather than silently inheriting it. Copilot needs no speech-generating model. Keep alternate providers as benchmark candidates only when a concrete accuracy, latency, hosting or cost constraint justifies them.

Delivery sequence and acceptance¶

Step	Deliverable	Exit condition
1. Fixture and transport baseline	Approved scenario fixture, dates, knowledge, identities and selected demo channel	Replay both speakers correctly; trusted auth adapter works; no private facts before access checks
2. Functional beneficiary Copilot	Four behaviors, grounded cards and wrap-up	Covers all six script sections, uses exact amounts and produces an initial latency baseline
3. Functional producer voice	GPT Live, policy/commission tools and illustration flow	Completes the original script with correct spoken and displayed results
4. Supervised variant	Specialist Chat, review workflow and enforced decision record	Approval/rejection/correction/timeout/cancel/end journeys work
5. Visual companion	Allianz branding and four producer components	Voice/UI edits share state; secure delivery and voice-only fallback work
6. Latency and rehearsal	Partial-cue path if required; meaningful measurements and recorded journeys	Sub-second objective demonstrated for the declared cue class; slower paths disclosed

Build the first authenticated policy lookup and one coaching cue early. They test the two main uncertainties—Live integration behavior and audio-to-card timing—before investing in every visual component.

Estimate 8–12 focused engineering days for a polished synthetic demo with working integrations, available brand assets and a reviewer participant. Allow roughly 3–5 additional days if partial-transcript handling, Copilot model controls or the selected channel needs runtime work. These are planning estimates; real identity, policy-administration, illustration and CRM integrations require a separate scope after API discovery.

Run the original scripts and meaningful variants: grief without a question, long pauses, overlapping speakers, misheard/corrected IDs, a repeated question, gross/final confusion, tax questions, stale data, precise cents/rates, rapid follow-ups, edited assumptions, duplicate submission, slow tools, supervisor outcomes, call termination and lost surface connectivity.

Acceptance requires:

Every consequential figure, status, reference and completion claim matches tool evidence; the spoken response agrees with the card.
No policy details or writes before trusted authorization. No skipped review or fabricated confirmation/approval.
Relevant, concise coaching without repeated condolences or irrelevant card churn. Human review assesses tone.
Measured first-useful-card latency meets the declared target on the selected channel, with sample count and concurrency reported.
The human supervisor decision actually changes the execution outcome; record each outcome separately.
The producer finishes by voice alone or with the visual surface. UI completion, secure delivery and visible error states work.

Use native agent tests for individual calls and recorded journey evidence for the voice–supervisor connection. The native Copilot tester can rehearse with a voice stand-in; it does not provision a real CCaaS tap. Choose the actual two-channel ingress before claiming a contact-center deployment.

Record expected latency and outcome evidence alongside saved configurations. Update the matching handbook/user-guide pages with implementation changes; regenerate configuration/API documentation only if their sources change.

Decisions to settle before implementation¶

Use these defaults unless the demo owner specifies otherwise: synthetic US annuity data, Allianz Life branding, native phone/browser preview, one human specialist, Responses delegation and a scenario-specific knowledge pack.

The build needs a target tenant/integration, the final demo channel (preview, Genesys, Connect/SCV or another existing tap), approved brand assets, explicit fixture dates, and a decision about synthetic versus real backend access. These do not block planning.

Source notes¶

The source scenario is the repository-root Word document named above. External references were retrieved on 2026-09-28.

O1 — OpenAI, GPT-Live 1: https://developers.openai.com/api/docs/models/gpt-live-1
O2 — OpenAI, Getting started with GPT-Live: https://developers.openai.com/api/docs/guides/live
O3 — OpenAI, Delegation and tools: https://developers.openai.com/api/docs/guides/live-delegation
O4 — OpenAI, GPT-6 Luna: https://developers.openai.com/api/docs/models/gpt-6-luna
O5 — OpenAI, GPT-Live-Transcribe: https://developers.openai.com/api/docs/models/gpt-live-transcribe
B1 — Allianz Life, production stylesheet linked from its homepage: https://www.allianzlife.com/-/media/Sites/AzlCommon/Project/styles/style.css?vs=140