Voice Concierge pod: architecture and releases

Where the client-specific code lives, which shared headless services do the heavy lifting, and how a new agent flow version reaches callers.

Where the code goes

Membersphone, SMS, emailClient managersbrowserTelephony and speechnumbers, speech to text, voicePod Hubbranded client portalcalls, textssign inCUSTOM CODE · one repo and container per clientVoice runtimefrom pod-sdklisten, run flow step,speak, filler lines,silence rulepod.yamlmodels, tools, hostsflows/*.jsonwork-hours, after-hours,sms, email, outboundprompts/opening messages,personatools.yamltools, args, timeoutsevals/140 golden calls,204 routesmetrics.yamlAI purchases,saves, hoursaudio streamHEADLESS SERVICES · shared by every pod, no UI of their ownpod-gatewaymodels, budgets,card and ID blockRagOSknowledge,promotions recordtoolOStools, secrets,webhooks, approvalsEvalOSgolden calls,release gateLangfuseone traceper callKeycloaksign-in,roles, tenantspod-controlversions, livepointer, usageShared by default, each client isolated. Single-tenant or client-hosted on request.pod-egress sits in front: a pod can only reach the hosts named in pod.yaml.MCP and API calls, trace id on every hopreads records, editspromotions, versionsClient supportteampeople on the loopwarm transferwith contextflaggedcalls toreviewClient systems: order system, subscriptions, tickets, automationssigned calls
Orange is custom code: one repo and one container per client. Blue is headless services that every pod reuses. The blue arrow from the voice runtime is the human on the loop: when Ava hands a call over, the client's team gets the member, the reason and what Ava already did; flagged calls land in their review queue. The pod never holds a model key or a client system password; it calls the services, and toolOS is the only path to client systems.
Custom, per clientHeadless, sharedOutside the platform

Why this is easier to build, more custom and more responsive

AreaHow it works for a client pod
Faster buildsThe next pod reuses all seven services. Only the orange box is new work, built from a tested template.
Custom per clientEach client gets its own flows, prompts, tools, metrics and portal screens, in its own repo. Nothing is forced into a generic builder.
Agent flowJSON in git: reviewed, compared step by step, rebuilt from the last shipped version
Safe releasesEvalOS gate on 140 golden calls and 204 route replays; a worse version cannot ship
Responsive changesKnowledge, promotions, opening messages, voices and routing change from the portal and are live on the next call
KnowledgeRagOS: capture dates, a promotions record that always wins, shared across pods
Tools and secretstoolOS: timeouts, failure results, approvals; keys never enter the pod or its exports
Modelspod-gateway: per-pod budget, card and ID numbers blocked before any model call, models swapped without code changes
TracingLangfuse: one trace per call across speech, model, knowledge and tools
Voicepod-sdk voice runtime built for turn latency: filler lines, warm tool connections, silence rule
Client portalPod Hub screens built for this pod: history, voices, promotions, impact

Where it runs, where data lives, how long it is kept

OptionWhat runs whereBest for
Shared (default)The client's pod runs in its own container; the seven services are shared, with every record scoped to that clientMost clients: fastest to start, lowest cost
Single-tenantThe pod and a dedicated copy of every service, used by this client only, run and patched by SectorFlowClients who need no shared infrastructure
Client-hostedThe same containers deployed in the client's own cloud account; SectorFlow ships releases through the same gateRegulated clients, or data that cannot leave their account
DataResidencyDefault retentionClient control
Call records and transcriptsRegion chosen per client: Canada, US or EU13 months30 days to 7 years, per agent; card and ID numbers never stored
RecordingsSame region90 daysOff, or up to 7 years
TracesSame region30 daysShorter or longer per client
Knowledge and promotionsSame regionUntil removed; every version keptDelete any topic or version
BackupsSame region14 daysFixed
A member's data––Deleted on request across records, recordings and traces

How an agent flow version is updated

1 Changeflow JSON, prompt,tool or model, in a branch2 Build checksedges, reachability,variables, diff by node3 Quality gate140 golden calls,204 route replays4 Client reviewrelease notes and gateevidence in Releases5 Make livemove the live pointer,numbers unchangedEvery release is a new immutable version. v81 is never edited; v82 is built from it.fails: blocked, cannot be overridden, back to step 1Main line(555) 010-2200Work-Hours v81Work-Hours v82After-Hours v36After-Hours v37beforeafter step 5Work-Hours and After-Hours move together as a pair. Rollback is one move of the pointer back to v81 and v36.No release needed: knowledge, promotions, opening messages, voice weights, phone routingsaved in the portal, live on the next call; every change is versioned and in the activity log
A flow, prompt, tool or model change goes through all five steps. Pointer moves are done by SectorFlow in pod-control after the client has seen the gate result. Content changes at the bottom skip the release path because they do not change how the agent behaves step by step.

Release steps in detail

StepWhoWhat happens
1 ChangeSectorFlow engineerBranch from the live version. Edit flows/work-hours.json and its After-Hours pair, prompts or tools.yaml. Write release notes.
2 Build checksCIEvery edge and tool exists, every step is reachable, every variable is set, no logic in spoken text, a failure edge on every tool step. Diff by node, edge and tool for the reviewer.
3 Quality gateCI calls EvalOSSimulated callers replay 140 golden calls; 204 logged production routes must still exist. All 50 must-pass cases pass, at least 90% overall, no regressions against live.
4 Client reviewClient in Pod HubThe candidate appears under Releases with notes, scores and failed cases. Make live is disabled for client users.
5 Make liveSectorFlow in pod-controlThe image and flow hash are registered as an immutable version. The live pointer for the number moves to the new pair. Traces and alerts are watched on the first calls.
RollbackSectorFlowMove the pointer back. The previous pair is still deployed, so it takes effect on the next call.