How the UNLEASH AI assistant works

Contents

• The 30-second explanation
• 1. What it is built with
• 2. What happens when someone sends a message
• 3. Routing: what Jev does, and what it does not do
• 4. Remembering context without repeatedly asking
• 5. What the workflows actually do
• 6. Tools and source authority
• 7. Launch, cookies, and submission controls
• 8. Streaming, policies, and quality monitoring
• 9. How it was built and tested
• 10. Submissions, tracking cookies and privacy
• 11. Useful answers during the call
• 12. October fixes and final evidence
• Code map

Call guide updated 5 October 2026. October application fixes are local and not deployed; the original extracts below retain their explicit September 32ee84f5 snapshot links. Current exact extracts and the full change register are in the October fix record.

This explains the checked-out implementation, not a live audit of production settings. Code extracts below are copied from that snapshot; surrounding code is omitted. Local file links open the implementation, and GitHub snapshot links preserve the exact version.

The 30-second explanation

The assistant is a custom conversational interface built into the UNLEASH website. It combines a language model with UNLEASH content and application tools. It can answer questions, recommend event content, build an agenda, and—when enabled—prepare and submit enquiries.

It is not a model trained from scratch on UNLEASH. We supply relevant published information at request time, retain the conversation’s context, and put important permissions and submission checks in application code.

There are three separate jobs: Jev chooses the workflow; the conversational model answers and uses tools; application code controls what is allowed and what actually gets sent.

1. What it is built with

Built-in defaults are openai/gpt-5.4-mini for conversation, openai/gpt-5.6-luna for profile extraction, and openai/gpt-5.4 for review. Environment and/or Sanity configuration can override these; defaults are not proof of the live models.

2. What happens when someone sends a message

1. The browser collects the message, recent conversation, page URL, chat ID, and saved visitor facts.
2. /api/ai/profile extracts explicit new facts such as company, role, and email into a structured profile.
3. /api/ai validates the request, resolves the event, and applies policy/cancellation checks.
4. The router continues an active workflow or asks Jev which workflow fits.
5. The server combines instructions, known facts, event context, and the permitted tools.
6. The conversational model answers, calling source or workflow tools as needed.
7. Text streams back to the chat. Submission and agenda results use authoritative application wording where needed.
8. Telemetry and optional conversation review capture what happened.

Visitor → profile extraction → guards + workflow selection
        → prompt + permitted tools → conversational model → streamed answer
                                      ↕
                             Sanity / Pinecone / Inwink
                                      ↓ (only if allowed and confirmed)
                              Zapier request handoff

Completed response → asynchronous quality review → Langfuse

Source: index.ts:1632 · GitHub snapshot

streamText({
                model: gateway(models.concierge),
                system,
                messages,
                tools,

The UI awaits profile extraction before starting the answer. That and classification/source calls contribute to time before the first visible text.

3. Routing: what Jev does, and what it does not do

The narrow selector is enabled with AI_JEV_FLOW_SELECTOR=active.

A price question alone should remain informational. Jev does not decide consent, validate email addresses, send enquiries, or review the generated answer.

An active flow is remembered by chat ID. Routine replies such as “yes,” an email address, or a quantity skip classification. Recognized current-request send confirmations also skip classification. Other active-flow messages use a narrower continue/change question. A factual side question preserves the active flow.

Source: flowSelector.server.ts:22 · GitHub snapshot

if (input.active && routineContinuation(input.message))
        return selectDestination('continue', 1, input.active)

The selector sees the current message, page, active workflow, and up to six earlier turns (three exchanges). Its timeout is 1.5 seconds, with no retries. Low-confidence/error results fall back; the confidence thresholds are application choices, not a guarantee of correctness.

Source: flowSelector.ts:56 · GitHub snapshot

export function selectDestination(
    choice: Destination | 'continue',
    probability: number,
    active: Flow | null,
): FlowSelection {
    if (
        !Number.isFinite(probability) ||
        probability < (choice === 'information' ? 0.65 : 0.75) ||
        probability > 1 ||
        choice === 'uncertain'
    )
        return { destination: active ?? 'uncertain', active, source: 'fallback' }

4. Remembering context without repeatedly asking

The event comes from the page/conversation; if ambiguous, the assistant should ask. Browser timezone/language are hints, not proof of event, role, or eligibility.

The browser stores the transcript, profile, chat ID, and conversational consent in sessionStorage. The model receives a known-facts table so it can reuse details and ask only for missing information. Corrections override older values; null extraction does not erase known fields. Quantity ranges stay estimates. Requested group quotes need not invent a pass selection. Sharing contact details does not itself grant send consent.

Source: userProfile.ts:41 · GitHub snapshot

'| Field | Saved value |',
        '| --- | --- |',
        ...(['name', 'email', 'company', 'role'] as const).map(
            (field) => `| ${field} | ${cell(profile?.[field])} |`,
        ),
        `| interests | ${cell(profile?.interests?.join(', '))} |`,
        `| ticket quantity | ${cell(profile?.ticketQuantity?.toString())} |`,
        `| requested pass | ${cell(profile?.ticketPass)} |`,
        `| ticket event | ${cell(profile?.ticketEvent)} |`,

Important limitation: active workflow state is a process-local map with a one-hour expiry and 5,000-entry cap. It is not a durable shared database across serverless instances. Browser memory is not authenticated account identity or cross-device memory.

5. What the workflows actually do

Agenda planning is deterministic application code: it checks eligible sessions, scores topic matches, avoids clashes, allows room-transfer time, and caps the daily selection. The model does not invent the timetable. Session links target agenda-schedule so the flyouts close onto the proper page.

Cancellation stops pending contact flows. A failed submission reports Support and ends qualification; an acknowledgement does not automatically retry. Informational pass/pricing questions do not begin contact collection. Reusing saved details still requires a summary and confirmation for a new enquiry. These behaviors combine code and prompts; they should be described as tested intended behavior, not an infallible transaction system.

6. Tools and source authority

See the detailed tool guide for every tool’s inputs, data sources, execution steps, outputs, error handling and code extracts.

A tool is a typed server function the model can request. The server supplies its description and input schema, executes it, and returns data. The model only receives the tools allowed for that turn.

Freshness is source-specific:

• Latest articles and future webinars use direct date-aware Sanity queries, not similarity ranking.
• Badge inclusions come from published content. Numeric prices use maintained Sanity mappings and Inwink products; price caches are 60 seconds and date bands are re-evaluated. Unknown/conflicting prices stay unavailable. Explorer is “Price on application.”
• Semantic knowledge is chunked and embedded into Pinecone. This is retrieval-augmented generation, not fine-tuning. Refresh success and editorial accuracy matter.
• Structured agenda reads use the stored catalogue; a ten-minute warm-instance cache and ingestion freshness apply.
• Hotel replies should use the direct external booking URL maintained in event-page data.

7. Launch, cookies, and submission controls

The visitor-facing widget requires explicit saved functional-cookie acceptance, including Accept all. Dismissing the banner or rejecting functional cookies leaves it hidden. Withdrawal unmounts the chat; existing cleanup aborts its active browser request. This is a UI gate, not a server authentication mechanism.

Source: GlobalLayoutAi.tsx:230 · GitHub snapshot

<Show
                    when={cookiesAccepted() && verifiedVisible() && aiSettings()?.visible}
                >

Sanity’s Show AI on production defaults off and gates production UI/API access. The browser checks fresh availability, then rechecks every 30 seconds and on focus. Published settings are used; drafts cannot enable production. A failed settings read disables capabilities. An already-started response may finish.

Sanity also exposes all 18 tool switches and an Allow email / contact submissions master switch, default off. When submissions are off, the application removes the tools and associated instructions, prevents contact-flow qualification from starting/resuming, and offers the appropriate contact route. In-chat agenda building can remain available.

Source: ai-capabilities.ts:27 · GitHub snapshot

export function aiToolEnabled(
    config: AiCapabilities,
    name: AiToolName,
): boolean {
    if (
        (name === 'submitLead' || name === 'sendAgendaByEmail') &&
        !config.allowEmailSubmissions
    )
        return false
    if (name === 'sendAgendaByEmail' && config.tools.buildAgenda === false)
        return false
    return config.tools[name] !== false
}

The separate Allow submissions on staging only setting applies only to Vercel Preview on pre-prod; it cannot grant production access. Other environments use the main submission setting. To disable sends on pre-prod, disable its staging permission too. This documents the configuration contract, not a live audit of the current switches.

The server checks permissions again immediately before a submission, so a tool offered earlier cannot bypass a newly disabled switch.

Source: aiCapabilityPolicy.ts:107 · GitHub snapshot

const config = await readSettings()
    if (!isVisible(config) || !aiToolEnabled(config, name))
        return {
            ok: false,
            error:
                'Contact submissions are currently unavailable. Nothing has been sent.',
        }
    return submit()

Cookie consent and conversational send consent are separate. Handoff checks validate required fields, event, email, intent, and consent; agenda emails also validate selected sessions. Zapier HTTP 2xx means accepted by the webhook. It does not verify Salesforce persistence or actual email delivery, and there is no application-level exactly-once guarantee.

8. Streaming, policies, and quality monitoring

Ordinary model text is forwarded as it arrives. Known send requests wait for the tool result so success cannot be reported ahead of that outcome. Agenda results can also arrive as complete server-owned text.

Source: chatDelivery.ts:31 · GitHub snapshot

if (authoritativeReplyEmitted || options.handoffRequested) return
            if (part.type === 'text-delta' && part.text) emit(part.text)

Application-owned response policies cover past editions (redirect to current/future events), personal-data requests (refer to support), and legacy UNLEASH WORLD capitalization. Contact routing uses customersuccess@unleash.ai for clearly sponsor/exhibitor questions and support@unleash.ai otherwise, including privacy/data questions.

Langfuse records model/tool activity and routing decisions. A separate asynchronous review flags potentially problematic conversations—loops, ignored cancellation, wrong event, missing links, or unsupported success. It runs after delivery and does not block streaming. A flag is evidence to investigate, not automatically a confirmed defect. Telemetry masking is partial, not comprehensive anonymization.

9. How it was built and tested

The implementation evolved through real visitor scenarios: event inference, repeated profile questions, cancellation, malformed email correction, send confirmation, ticket qualification, agenda links, price accuracy, and hotel booking URLs. We separated routing from workflow execution, moved authoritative data/side effects into tools, and added code-enforced launch permissions.

Verification uses owning-package unit tests, API conversation/UAT batches with captured mock webhooks, browser checks, and Langfuse traces. A rejected mock webhook (for example HTTP 503) is never counted as successful delivery.

Do not claim the full system has a clean final UAT pass: the 247-case run on 18 September was interrupted by AI Gateway insufficient credits. Earlier targeted reports and later focused tests are useful evidence, but are not a complete current release certification. This document-writing task did not run new UAT or verify live deployment/model settings.

10. Submissions, tracking cookies and privacy

See the separate privacy and submissions guide for consent distinctions, submitted data, cookie/Consent Mode behavior, marketing opt-in, trace masking, storage and operational limits, with code extracts.

The key distinction: functional-cookie acceptance makes chat available; conversational confirmation authorizes a particular submission; marketing opt-in is separate. Analytics-cookie rejection does not disable server-side AI tracing. Cookie withdrawal hides chat but does not erase already stored/submitted data.

11. Useful answers during the call

• “Can it send emails at launch?” Only if the published master switch and relevant tool switch allow it. We can launch information and in-chat agendas with submissions off.
• “Does Jev replace the chatbot?” No. It selects the destination; the conversational model and existing workflow code do the work.
• “How do we keep prices correct?” Structured source mappings and current product data, short caches, and no guessed fallback price. Editorial/source maintenance still matters.
• “Does it remember me?” It remembers explicit details within the browser session. It is not an authenticated customer profile.
• “Can it hallucinate?” Generated language can still be wrong. Structured tools, authoritative replies, policy checks, tests, and trace review reduce and expose errors; they do not eliminate them.
• “Where do we change behavior?” Sanity for editorial instructions/models/tool availability; code for routing, data authority, validations, and workflow behavior.

12. October fixes and final evidence

The final reviewed non-passing cohort has no verified application defect still open. Fixes include natural confirmation, saved details and corrected emails, group quotes/estimated quantities, one-day agendas, startup/Award distinctions, exact FAQ grounding, sponsor-name ingestion and safe streaming links. Missing source facts still produce honest uncertainty.

Original supplied UAT (C01–C95) is 85.8% raw / 95.3% adjusted across both models; the entire retained benchmark is 85.7% raw / 97.4% adjusted. These are rolling retained results, not a new complete suite run. Adjusted scores exclude itemized obsolete/evaluator-only expectations and retain content gaps and untested operations. The review preserves all raw grades.

Local tests are 303 pass, 0 fail. Seven mechanical FAQ update/delete tests and four final withdrawn-fact response probes passed. Real CRM/email delivery, browser identity isolation, live deployment controls and a sustained publish-to-answer SLA remain separate operational checks.

Current report · All fixes, code extracts and evidence.

Code map

• Widget and session memory: AiModule.tsx

• Visibility and cookie gate: GlobalLayoutAi.tsx

• Cookie acceptance/withdrawal: consent-state.ts

• Main orchestration and tool definitions: index.ts

• Profile extraction endpoint: profile.ts

• Workflow choice definitions: flowSelector.ts

• Jev request: flowSelector.server.ts

• Workflow memory: aiFlowSessions.ts

• Prompt/model assembly: aiPrompts.ts

• Default prompts/models: ai-prompts.ts

• Agenda planner: agendaPlan.ts

• Badge source and pricing: badges.ts

• Live price resolver: livePricing.server.ts

• Submission transport: leads.ts

• Published capability checks: aiCapabilities.server.ts

• Disabled-workflow behavior: aiDisabledWorkflow.ts

• Visitor policies: aiResponsePolicy.ts

• Streaming: chatDelivery.ts

• Trace instrumentation: aiTelemetry.ts

• Background review: aiConversationReview.server.ts

• Sanity AI settings: ai.ts

• UAT harness: run.ts

Further detail: original architecture reference (18 September snapshot) · launch-control guide