Avoca — Internal

Appearance

The comingFrom Primitive ​

A bare, construction-level-safe override for the phone number a test call is treated as calling from — ships with no storage, no UI, and no consumer yet. This page documents the primitive itself; a later plan decides who wires a real value into it.

What this is ​

Every pre-call and in-call customer lookup ultimately reads some phone number and treats it as "the caller." Normally that's the real telephony caller ID. comingFrom lets a test call substitute a different number at that read — so the agent (and every CRM lookup it triggers) behaves exactly as if a different, specific customer had called. Combined with faking the call's time (asOf, below), a test call can fully impersonate "this customer, at this moment" without needing to mock any tool-call responses.

The primitive is a single function:

ts
resolveComingFromOverride(isTestCall: boolean, overrideValue: string | null | undefined): string | null

isTestCall is mandatory and first on purpose. The function refuses to return a non-null override whenever it's false, regardless of what overrideValue was passed in — this is a construction-level safety guarantee, not a caller-side convention every call site has to remember to check. A real production call is provably, structurally incapable of ever being affected. See resolve-coming-from-override.test.ts for the property-style test that proves it across a range of override values.

Why not just extend asOf ​

asOf (mocked call time, from Peter Lehrman's Compiled Preview time tester) is the structural precedent this primitive deliberately does not copy in one respect: asOf trusts each call site to check isTestPhone before ever resolving a value, with no defense if a call site forgets or a future refactor moves the check. comingFrom bakes that check into the resolver itself instead.

The three injection points ​

PointFileWhat it overrides
Pre-call (both platforms)assistant-request.tsThe caller number fed into resolvePreCallIdentity → runParallelPreCall → gatherPreCallData → getPrecallCRMInfo — i.e. what the pre-call CRM lookup and personalized-greeting variables think the customer's number is.
VAPI in-callfindCustomerDNS.tsThe single customerNumber variable every CRM branch (ST/HCP, Neighborly, ServiceMinder, Four Seasons, AccuLynx, FieldRoutes) reads from.
ElevenLabs in-calldispatch.tsctx.customerPhone, the field every EL tool handler (including findCustomer.ts) reads.

Pre-call and in-call share no customer-lookup code at all, even for the same CRM — so all three points are independently required; overriding only one would leave the other two showing the real customer.

Each site scopes the override narrowly: it changes the number a CRM lookup uses, never the literal telephony audit trail (calls.caller_id, the Statsig experiment userId, or the blocked-caller log). A test call's own DB record still traces back to the real number that dialed in — only what the agent believes about the customer changes. (VAPI's pre-call site is a partial exception: because runParallelPreCall accepts one callerNumber for both the CRM lookup and the test call's own row, the override does reach that row's caller_id too — deliberate, since it's already a test-call-only row.)

What ships here, what doesn't ​

This primitive ships:

  • The resolver function and its safety guarantee.
  • The three threadings, each independently tested (mocked integration tests per platform/CRM branch).
  • Proof that pre-call and in-call resolution can't interfere with each other — the resolver is stateless, so nothing carries over between calls.

This primitive does not ship:

  • Any durable storage for the override value.
  • Any UI.
  • A Hamming consumer (test_case_context_mocks extension, mirroring how mocked_as_of already works) or the live-call-mocking profile system — either could be the first real consumer; the primitive doesn't privilege one over the other.

Until a consumer exists, every call site resolves overrideValue to undefined in production — a call to resolveComingFromOverride with no real second argument always returns null, so this primitive is entirely inert today.

UI guidance for the future consumer ​

Captured here so it isn't lost between planning sessions: the test phone number's existing assistant-config selector (the "flask" toggle in AssistantConfigsCard.tsx) and a future "overrides" section (comingFrom, asOf, and anything added later) should stay as two separate sections on the same test-phone-call settings surface — not merged into one unified "profile" object. Assistant config selection is its own concern; call-context overrides are a different, additive one.

Source ​

  • Overview
  • Tool Call Mocks — the sibling test-call-only mechanism this primitive complements (tool-call responses vs. who the caller is)