Context Persistence Across Channels: CallSphere vs Vapi Limit

TL;DR

CallSphere's data model centers on customers (or patients in healthcare) tables that persist customer state across all channels. When a customer interacts on voice, the agent reads and writes to the same row that the chat agent uses, that the SMS agent uses, that the email agent uses. The result: the customer's preferences, history, and ongoing tasks are always one query away. Vapi exposes voice call records but no first-class cross-channel customer state.

What "Context Persistence" Means in Practice

Context is a slippery word. In conversational AI it can mean three different things:

1. Within-turn context — the agent remembers what the user just said. Every modern LLM gives you this.
2. Within-session context — the agent remembers everything from the start of this call/chat. Most platforms give you this.
3. Across-session context — the agent remembers across calls, chats, days, and channels. This is rare and where CallSphere differentiates.

Across-session context is what makes the agent feel like an actual assistant rather than a fresh hire on every call. It is also where most platforms fall down because they treat each session as independent.

CallSphere's Customer State Model

The customers table (called patients in healthcare for clarity) is the source of truth for every customer:

Column	Type	Notes
id	UUID	Primary key
tenant_id	UUID	Scope
phone	text	E.164
email	text	Lowercased
name	text	Full name
preferences	jsonb	Channel preference, language, etc.
profile	jsonb	Vertical-specific structured data
created_at	timestamp	First interaction
last_seen_at	timestamp	Most recent interaction (any channel)

Every agent — voice, chat, SMS, email — reads and writes this row. The customer's stylist preference learned from a voice call is available on chat. The dietary restriction noted in chat is available on the next phone call. The emergency contact captured in email is available everywhere.

In addition to the static customer row, CallSphere maintains:

• conversations — long-running conversations spanning sessions
• session_state — short-lived key/value state per conversation
• call_logs — every session's transcript and enrichment

Together these provide three layers of memory: long-term (customer row), medium-term (conversation), short-term (session).

Vapi's State Limitations

Vapi exposes call records and call metadata. It does not provide:

• A customer-state table that persists across calls
• A conversation abstraction spanning multiple sessions
• A multi-channel session-state store

A Vapi customer who wants this builds it themselves:

• Provision a Postgres
• Define their own customer table
• Write code in every Vapi function that reads and writes to that table
• Bridge that table to whatever chat/SMS platform they also run

This is doable but requires real engineering and is a common source of bugs (race conditions on concurrent updates, stale state, inconsistent identity resolution).

Side-by-Side Comparison

Capability	Vapi	CallSphere
Customer state table	DIY	Built-in
Conversation abstraction	No	Yes
Session state KV	DIY	Built-in
Cross-channel reads/writes	DIY	Native
Identity resolution	DIY	Built-in (phone, email, auth, cookie)
Concurrency safety	DIY	Built-in (DB transactions)
Engineering hours to deploy	60-160	0

Mermaid: Customer-State Propagation

graph TD
    subgraph Channels
      V[Voice Agent]
      C[Chat Agent]
      S[SmsAgent]
      E[EmailTriageAgent]
    end
    subgraph State Layers
      CT[(customers - long term)]
      CV[(conversations - medium term)]
      SS[(session_state - short term)]
      CL[(call_logs - history)]
    end
    V --> CT
    C --> CT
    S --> CT
    E --> CT
    V --> CV
    C --> CV
    S --> CV
    E --> CV
    V --> SS
    C --> SS
    V --> CL
    C --> CL
    S --> CL
    E --> CL
    CT -->|preferences| V
    CT -->|preferences| C
    CV -->|open task| V
    CV -->|open task| C
    SS -->|pending_action| V
    SS -->|pending_action| C

The diagram shows that every channel reads from and writes to all four state layers. State propagation is a property of the data model, not a feature each agent must implement.

Real Example: A Salon Client's Six-Month History

A salon client has used CallSphere for six months. Her customer record now contains:

• Preferences: stylist=Jen, color=balayage, payment=credit-card-ending-4422
• History: 14 visits, 11 with Jen, last visit 3 weeks ago
• Notes (auto-summarized from past conversations): "Allergic to a specific brand of hair dye, mentioned on visit 4. Prefers Saturday mornings."
• Profile: birthday, address, referral source

She calls on a Tuesday morning. The voice agent's first response: "Hi Maria, want to book your usual with Jen? She has Saturday at 10 AM open this week."

That single sentence is built from six months of cross-channel context. On a Vapi-only stack, the agent would say "Hi, what can I help you with?" and the customer would have to re-explain everything, every time.

Why Cross-Channel Concurrency Matters

Concurrency is where most DIY implementations break. Imagine:

• Customer is on a phone call and the voice agent is mid-booking.
• Simultaneously, the customer's spouse opens the chat widget on the same account.
• Both agents query the customer record. Both try to update it.

Without proper concurrency control, the writes conflict and one is lost. CallSphere's built-in state model uses Postgres transactions and optimistic locking to handle these correctly. A DIY Vapi-plus-store implementation has to discover and fix this class of bug, often after a customer-facing incident.

When Vapi-Only Is Sufficient

If your conversations are stateless one-shots (a single survey, a single appointment confirmation), state persistence is unnecessary. For any business that aspires to a persistent customer relationship, this is foundational.

Book a demo to see the customer-state model in action.

FAQ

Is the customer state encrypted?

Yes at rest with KMS-managed keys. PHI fields in healthcare are encrypted with field-level keys.

How does identity resolution handle multiple identifiers?

The customer record can have multiple identifiers (phone, email, auth ID). Resolution uses the first available match. Customers can be merged by an admin when duplicates are detected.

Can I store custom fields on customers?

Yes. The profile jsonb column accepts arbitrary structured data, schema-validated per tenant.

What happens to customer state when a customer requests deletion?

GDPR data-rights deletion wipes the customer row, all conversations, all session state, and all call_logs. Audit logs of the deletion request are retained per legal requirement.

Does session state expire?

Yes. Default TTL is 30 days for conversations and 24 hours for session_state. Configurable per tenant.

Can external systems sync to the customer table?

Yes. Webhooks fire on customer create/update/delete; bidirectional sync to Salesforce, HubSpot, and Zoho is supported.

Explore features or book a demo.