Part 6 of 12 – Conversation Intelligence Platform series Back to Part 1
The media tap described in Part 5 gives you the audio. Transcription gives you the text. Neither of those is directly useful to your systems – what your systems need is a structured signal. Did fraud occur? What was the customer’s intent? Was the right protocol followed? Is this a retention risk?
Operators are how you get from transcript to structured answer.
An Operator is defined by two things: a prompt and an output type.
The prompt is a natural language description of the analysis task. “Monitor this conversation and score the likelihood of a social engineering fraud attempt, on a scale of 0 to 100, based on urgency cues, requests for unusual account actions, and inconsistencies in the caller’s stated identity.” That’s an Operator. “Detect whether the handler has offered the caller the opportunity to register a complaint before closing the call, and return true or false.” Also an Operator. “Identify the primary intent of the caller – one of: billing query, technical fault, cancellation request, sales enquiry, complaint, other.” Also an Operator.
The output type is the declared structure of what the Operator returns. A fraud score is a number between 0 and 100. An intent classification is one of an enumerated set of strings. A protocol adherence check is a boolean. The output type is declared when the Operator is created, not inferred at runtime.
The reason output types matter: every downstream system – the webhook receiver, the event stream subscriber, the Configuration action – can work with the result without bespoke handling. The structure is the contract.
Operators run continuously during a call as the transcript develops. They’re not one-shot analyses run at the end; they evaluate as new content arrives. This is what makes real-time action possible. A fraud Operator that scores 23 at the start of a call and 87 three minutes in is signalling something that’s developing, and a Configuration can fire an action the moment that threshold is crossed, not after the call ends.
Customers define their own Operators for their own verticals. The analysis task described in the prompt, and the output type declared for it, are entirely customer-defined. Simwood provides the platform and the carrier-layer infrastructure; what you choose to observe and what you choose to emit are yours.
Configurations are what connect Operators to action
A Configuration specifies which Operators run on a session and what to do when they produce a result that warrants action. The two primary action types are webhooks and whispers.
A webhook action fires a POST request to a configured endpoint when an Operator output meets a specified condition. The payload carries the full context: the Operator’s output, the session identifier, the conversation history to that point, the timestamp. Your platform receives a complete, structured event in real time. We’ve been delivering this kind of real-time mid-call signal to fraud handlers in major banks since before the AI era – rule-based triggers feeding real-time webhooks to handlers who could act while the call was in progress. Conversation Intelligence replaces those brittle rules with AI-driven Operators while the delivery model stays the same.
A whisper action synthesises audio from a text template and injects it into the call, heard only by the targeted recipient. In most scenarios that’s the handler – a compliance prompt, a fraud alert, a suggested response – but in an outbound calling scenario the intended recipient might equally be the caller. The injection is private and targeted. The conversation continues without interruption.
Customers who want to handle signal delivery entirely on their own side can subscribe directly to the Operator event stream rather than using Configuration actions. The stream delivers every Operator output as it’s produced; what you do with it is up to you.
The webhook interaction model is currently one-directional: Simwood delivers events to your platform. A reasonable question is whether customers can respond to a webhook with instructions – “transfer this call”, “end the session”, “swap to this Operator set” – and in the API-driven tier (Tier 2), that control does exist via PATCH /sessions/{id}. Tier 2 customers drive session creation and can modify sessions mid-call; the webhook is one channel for receiving signals, not the only way to interact with the platform.
The shared resources model is worth understanding, because it’s what makes Operators powerful rather than just capable.
Operators have access to the same external tools, knowledge bases, and credentials that Agents use. An Operator can make a real-time call to a phone number reputation API to cross-reference a CLI. It can query a compliance policy document to determine whether something said constitutes a breach. It can look up account history in a CRM. These aren’t hypothetical capabilities; they’re the same integration layer that Agents already use, now available to silent observers as well.
You configure tools, knowledge bases, and credentials once. Everything that needs them – Agents, Operators, Configurations – can use them. No duplication.
Previous: Part 5 – The media tap
