Part 7 of 12 – Conversation Intelligence Platform series Back to Part 1
Per-call analysis is useful. Intelligence that compounds across calls is transformative.
A single conversation, however well-instrumented, tells you only what happened in that conversation. But calls don’t exist in isolation. The customer calling about a billing dispute today may have raised the same issue last month and the month before. The number showing elevated fraud signals this morning may have appeared in a suspicious context twice in the past fortnight. The caller who sounds distressed may have a documented history with the service that explains why. None of that context is available without some form of memory – and building it from scratch, per customer, is exactly the kind of problem that doesn’t get solved until someone decides to make it a platform primitive.
Conversation Memory is that platform primitive.
Every completed conversation produces a vCon – a Virtual Conversation record. vCon is an open standard (RFC draft, shepherded by the IETF) that defines a portable, self-contained representation of a conversation. It includes the parties involved, the transcript, references to the media, and all derived analysis: Operator outputs, tags, collected data items, structured results. The vCon is the definitive, complete record of what happened in a conversation, expressed in a format that any compliant system can read.
The choice to use vCon rather than a proprietary format matters. It means the conversation records the platform produces are not locked to Simwood’s infrastructure. They’re portable, queryable by any system that understands the standard, and yours.
vCons are stored in the customer’s own S3-compatible object storage – the same bring-your-own-storage capability the platform already supports for call recordings. The conversation record never leaves the customer’s infrastructure. The Memory service indexes and queries it on the customer’s behalf, but ownership and custody are unambiguous. Simwood does not hold your conversation history; you do.
This is a deliberate design choice, not a concession. Conversation records contain sensitive information – the content of customer calls, fraud signals associated with specific numbers, compliance deviations, health and distress indicators. That data belongs with the customer. They should control it, back it up, and be able to query it independently of the platform if they choose.
The Memory service indexes vCons by participant identity as they accumulate. When a new conversation begins, Memory queries that history and surfaces what’s relevant: prior contacts from this caller, signals detected in previous calls, outcomes reached and issues left unresolved, patterns that only become visible across multiple interactions. That context is available to Agents and Operators before the conversation’s first word is spoken.
The effect is that the platform’s intelligence compounds over time. An Agent handling a returning customer can be aware of their history without the customer needing to repeat themselves. An Operator assessing fraud risk can factor in prior signals from the same number. A webhook payload can note that this is the third unresolved complaint from this caller in six weeks.
In emergency services, this context can be genuinely significant. A caller with a documented history of mental health crises should trigger a different initial response than an unknown first-time caller describing the same symptoms. That distinction requires memory.
Because vCon is an open standard and the records live in the customer’s own storage, the memory the platform builds is fully portable. If a customer migrates off the platform, their conversation history goes with them. They can query it with their own tooling, export it to other systems, or feed it into their own analysis pipelines. The historical record of a conversation estate belongs to the customer – not as a policy position, but as an architectural fact.
This is worth thinking about in comparison to how most analytics platforms work. The standard model is: your data lives in our infrastructure, queryable through our APIs, exportable only in the formats we support, and gone if you leave. Conversation Memory works the other way: your data lives in your infrastructure, the platform indexes it on your behalf, and you could walk away with every vCon intact.
Today, Conversation Memory is scoped to voice. But the record format, the identity model, and the storage structure are deliberately chosen to match what we’ve already defined for async text channels: WhatsApp, SMS, email, and support tickets. A voice call and a WhatsApp thread produce the same kind of record. The turn format is medium-agnostic. The conversation identity doesn’t reference a session; it references the transport-native key, whether that’s a call ID or a message thread. When the async front-end arrives, those conversations land in the same record shape without requiring anything to be redesigned. That’s not an accident.
Part 8 switches from the product to the platform itself – specifically the new API architecture that underlies all of this and makes independent service evolution possible.
