Block Dessa: who controls your voice AI conversations?

Dessa: AI interaction and conversation context — unDraw illustration

IA IA

Voice AI: buy a service or keep control of your conversations?

A customer starts describing a fault, then corrects their order number. If a reply is already underway, the correction needs to interrupt it. A system that listens while speaking makes that real-time adjustment possible to explore. With Dessa, Block is exploring this kind of simultaneous conversation. For businesses, that raises a practical question: should you buy the capability as a service, or be able to run it in an environment you control?

Buying an API, hosting an existing model and training your own model are three different decisions. Dessa makes the second possibility worth watching, but it is not currently a ready-to-deploy business solution. The choice depends on conversation quality, total operating cost and where the data actually travels, rather than how natural the voice sounds.

What Dessa changes about a conversation

On its official page, Block describes Dessa as a speech-to-speech model: it takes audio in and produces audio out. It is also full-duplex, meaning it can listen and speak at the same time. That opens up interruptions, acknowledgements and conversational timing without always requiring a strict question-then-answer exchange.

Audio carries more than words. A hesitation might mean someone is looking for a reference; an interruption might correct information before a response is finished. Retaining those signals could help a voice interface follow the conversation. It does not establish that the system always interprets emotions correctly, or that it knows your company’s policies.

Block says it trained Dessa solely on human conversations, without text or pretrained models. This research approach differs from adding a voice interface to an existing language model. The published recordings demonstrate conversational behaviour; they do not measure reliability across your customers’ accents, your products or your support procedures.

Running a model is not the same as training it

Two hardware claims in the announcement need to stay separate. For training, Block names an NVIDIA GB200 NVL72: a rack-scale system, not a single graphics card. For inference, which means using the already-trained model, the team claims local execution on a MacBook Pro M4 Max or better, faster than real time.

These are vendor statements, not independent benchmark results. They suggest that a voice capability could run on a powerful workstation without reproducing the infrastructure used to create it. They do not establish how many simultaneous conversations that machine could support, or what continuous operation would cost. For a smaller business, hosting an existing capability would be the first option to investigate, rather than training one from scratch.

Can a business actually access Dessa today?

When we checked the page on 31 October 2026, the download and waitlist calls to action still led to the message “Launch links are coming soon”. The page also offered an early-access application for safety researchers. We did not identify downloadable model weights, a usable public licence, documented API access or public pricing.

That makes Dessa a technical direction to assess, not a production dependency to promise a customer. Even a future download would not, by itself, settle commercial licensing, updates or support. Those conditions will need checking when access terms are actually published.

Three ways to obtain a voice capability

Buy an API. The provider operates the model. This can simplify an initial trial because your team can focus on the customer journey and business-system connections. In return, you depend on the contract, usage limits, service availability and the provider’s terms for handling conversations. The fastest route to a test may still require substantial integration work.

Host an existing model. You may gain more control over where audio is processed and which model version is used. Your organisation also takes responsibility for hardware, monitoring, updates and incidents. This route first requires an accessible model with suitable licensing and adequate quality. Ownership of a machine does not remove the need for someone to operate the service.

Train your own model. This is a different undertaking: assemble authorised training data, fund a research team, train the system and evaluate it. Block’s announcement does not make that a sensible default for a small business. The research budget would also come before the work of connecting the resulting model to an actual service.

A fluent voice does not resolve a support request

Consider an illustrative scenario, not a customer case study. A support team receives a refund request. The customer interrupts the AI to explain that the product has already been replaced. A full-duplex interface could follow that correction more naturally. It would not automatically know whether a refund is permitted, or whether the caller owns the order.

The system would still need to verify identity, retrieve the record, apply the refund policy and send exceptions to a person. An empathetic answer followed by an unauthorised refund is still a failure. A useful test asks whether the correction reaches the right record, and whether the system stops before taking an action it cannot authorise.

Telephone infrastructure is another layer. Routing a call, surviving a dropped connection, transferring to an adviser and maintaining service continuity do not come with the voice model automatically. If the goal is simply to write notes by speaking, local dictation with Handy addresses that narrower task without requiring a conversational system.

Compare total cost and the complete data journey

Before comparing vendors, choose a narrow interaction: qualify a request, retrieve a reference or prepare a handover. Specify what must be understood, what may be answered and what needs human approval. Then compare the options against the same test conversations, including interruptions, background noise and conflicting information. Record failures as well as successful exchanges. Reject an option if a correction is lost, an unauthorised action goes ahead or the human handover fails.

Total cost includes integration, hardware or API charges, monitoring, maintenance and human recovery work. A locally hosted option can still be expensive if specialist support is scarce. A managed service can still be a poor fit if its limits prevent a reliable handover. Compare who handles each failure, not just the price of generating audio.

For data, map the audio, any transcripts, logs, backups and destination applications. A locally running voice model does not make the entire chain local. A cloud customer-management tool or remote logging service can still receive information. Local execution also does not automatically establish GDPR compliance: purposes, access, retention and the relevant contractual responsibilities still need assessment.

Dessa points to a concrete possibility: voice interactions that depend less on rigid speaking turns. Choosing an architecture then means deciding who operates that capability, where conversations travel and who is accountable for decisions. Talk to Say Digital about scoping a first use case: a defined scenario, an API-versus-hosting comparison, a data-flow map and human-handover criteria before deployment.