DEV Community: Rémi Henriot

Conversational Versioning: Deploy Without Breaking Things

Rémi Henriot — Thu, 06 Aug 2026 12:00:27 +0000

Conversational Versioning: Deploy Without Breaking Things

Tech teams have git. Marketing teams have nothing to version their assistant with. That asymmetry kills more AI projects than any model choice.

Tech teams have git. Marketing teams have nothing to version their assistant with. That asymmetry kills more AI projects than any model choice.

The scene replays every week across dozens of teams: a prompt change applied straight to production, a validated behavior gone, and no way back.

Version control has existed for code for thirty years. Nobody would accept shipping software without history or rollback. Yet that's exactly what we ask of marketing teams operating a conversational experience.

Deployment Without Governance

Engineers know who changed which line, when, and why. They roll back in two minutes. They ship with a safety net.

The marketing team operating an AI assistant edits a prompt in production, no snapshot, no history, no rollback. On most platforms, configurations aren't versioned: they're overwritten. Change tracking, where it exists at all, lives in a Notion file.

It's a structural asymmetry. And it always produces the same outcome: a black-box configuration nobody fully understands, full of behaviors nobody can explain.

Fear Fossilizes the Assistant

A system prompt isn't a sentence. It's weeks of accumulated tuning, instructions, constraints, persona. Changing one line can disable a validated behavior or break a journey that was converting.

Without versions, every change is a bet. So teams stop betting: "don't touch it." The assistant fossilizes out of caution, while offers, seasons, and priorities move on without it.

Git for Conversations

At Scenaro, the Cockpit brings to conversational experiences the discipline git brought to code, without requiring the skills.

Every publication generates an immutable version of the full configuration: prompts, services, scenarios, features. You publish to staging first, validate, then promote to production. You compare two versions. You roll back in one move if a behavior goes sideways.

Promotion is non-destructive: the publication identifier doesn't change, so scripts already embedded on the site stay valid. Marketing publishes autonomously; engineering has nothing to redeploy. Tags even let you prepare a "Christmas" or "sale" version in parallel, without duplicating the scenario.

The effect is mechanical: when risk is controlled, iteration goes up. Teams move from "don't touch it" to confident weekly iteration. That's exactly what separates living experiences, Club Français du Vin, Urbansider, Lupi, from assistants frozen on day one.

And the stakes go beyond tooling. Every brand will soon talk directly with its customers; that dialogue will become an asset as critical as a website. A critical asset without change governance doesn't exist, not for long. Conversational versioning isn't a feature. It's the condition for marketing to run its assistant like a product, without fear, and without tickets.

See how Scenaro versioning works →

The full article lives on Scenaro: Conversational Versioning: Deploy Without Breaking Things

If you prefer the series by email: https://scenaro.substack.com/subscribe

Why Most AI Projects Stop at v1

Rémi Henriot — Sat, 01 Aug 2026 12:00:28 +0000

Why Most AI Projects Stop at v1

Building got easy. Running didn't. Most AI assistants die within 90 days, killed by a question nobody asked before launch: "who's maintaining this?"

Building got easy. Running didn't. Most AI assistants die within 90 days, killed by a question nobody asked before launch: "who's maintaining this?"

The demos impress. Budgets get approved. POCs have been multiplying across marketing teams for eighteen months.

Then the v1 becomes a tombstone. Still live, still billed, less relevant every week. Nobody dares touch it.

The technology didn't fail. It's the after-launch that nobody planned.

The Disposable POC

Industry reports converge: 60 to 70% of enterprise AI initiatives never make it past the pilot phase. Not for lack of ambition. For lack of infrastructure to operate a conversational system over time.

The disposable POC always follows the same script. An agency delivers in six weeks. The demo convinces. It goes live. Then user feedback arrives, the offer changes, a better model ships, and there's no owner, no tooling, no budget to iterate.

The budget covered the build. Nobody budgeted the operation. A conversational experience isn't a deliverable you sign off on: it's a living product you run.

Three Frictions That Turn v1 Into a Tombstone

First: the prompt belongs to engineering. Changing the assistant's behavior requires a ticket, a developer, a deployment. So even when user feedback is unambiguous, nothing moves.

Second: nobody sees anything. Without conversation metrics, there's no way to know whether users are asking unanswered questions, or whether a conversion path is broken somewhere. You're flying blind, which means you're not flying at all.

Third: no governance. Who changed what, when? Without history, every modification is a leap of faith. The assistant becomes a black box nobody dares touch. Six months post-launch, it answers exactly like day one, same mistakes included.

This isn't an LLM problem. The problem isn't GPT-4. It's zero context, zero scenario, zero memory, and zero loop to fix any of it.

Run It, Don't Re-Deliver It

At Scenaro, the premise is the opposite: a conversational experience is a living product, and the infrastructure must make iteration mundane.

In the Cockpit, every publication generates an immutable version. You publish to staging, then production. You compare two versions. You roll back when something breaks. It's "git for conversations", but usable by a marketing team, no tickets, no deployments. That's the concrete answer to "who's maintaining this?": the team that knows the customers, autonomously.

On visibility, conversations are analyzed automatically: unanswered questions, recurring topics, and drop-off moments surface every week. Iteration stops being intuition and becomes a loop fed by reality.

That's the difference between Club Français du Vin, Urbansider, or Lupi, production experiences that keep evolving, and the POCs that fade out in silence.

And there's a reason to build this muscle now rather than in two years. Every brand will soon talk directly with its customers, just as mobile apps forced everyone to "think mobile," the next design reflex will be thinking conversation-first. Teams learning to run conversational products today will be three years ahead of those still re-delivering POCs.

Building...

The full article lives on Scenaro: Why Most AI Projects Stop at v1

If you prefer the series by email: https://scenaro.substack.com/subscribe

Voice Prompt Engineering: A Discipline of Its Own

Rémi Henriot — Thu, 30 Jul 2026 12:00:50 +0000

Voice Prompt Engineering: A Discipline of Its Own

Copy-pasting your ChatGPT prompts into a voice assistant is the first mistake, and nearly everyone makes it. Voice has its own rules, and text never taught them.

Copy-pasting your ChatGPT prompts into a voice assistant is the first mistake, and nearly everyone makes it. Voice has its own rules, and text never taught them.

Teams learned to prompt with ChatGPT. A few iterations, a tone adjustment, and the text assistant behaves. So they transpose: same prompts, microphone attached.

The result: verbose agents that recite lists out loud and leave awkward silences while they work. Users hang up.

Prompting for voice is not prompting for text. It's a different discipline. And it can be learned.

The Copy-Paste That Fails

The problem is structural. There are thousands of resources on text prompting, ChatGPT, Claude, Gemini. Voice gets treated as just another output channel, handled with a "respond conversationally."

That's not enough. A prompt written for writing produces writing, and writing read out loud is exactly what makes users leave.

The discovery always happens in the same place: in production, when people hang up.

What Speech Forbids

Out loud, no markdown. An agent that generates a bulleted list produces absurd synthesized speech: "Dash. First benefit. Dash. Second benefit." That's not a conversation, it's a document reading.

Out loud, no scrolling back. Comprehension is linear and irreversible, the user can't reread. A 40-word sentence that works in text becomes unintelligible in synthesis. Short sentences. A rhythm.

Out loud, silence is a bug. When the agent runs a tool, product search, stock check, three seconds of dead air is enough to make the conversation feel broken. A human would say "let me check." The agent should too.

And out loud, the first sentence decides everything. An opening that sounds like a call center script ("Hello, I'm your virtual assistant, how can I help you today?") produces immediate abandonment. The opener must be a line of conversation, not a service announcement.

How Scenaro Structures the Voice Prompt

At Scenaro, a scenario's prompt isn't a monolithic block. It's structured around two things text prompting systematically conflates.

Character. Each scenario carries a persona: who this agent is, how it speaks, what it never does. A wine advisor at Club Français du Vin doesn't share a register with a travel concierge at Urbansider. Character governs sentence-by-sentence behavior, tone, rhythm, forbidden formats.

Goals. What the agent is trying to accomplish in the session: qualify, recommend, guide toward a purchase. Goals are declared separately from character. Mixing them into one block produces schizophrenic agents, that know what they want but not how to carry themselves, or the reverse.

And one voice-specific rule: Scenaro prompts encourage the agent to keep talking while tools execute. While a search runs, the agent narrates what it's doing. Silence is never left to chance.

Every prompt change is versioned and testable in real voice before publication. Because a voice prompt isn't judged by reading it, it's judged by listening to it.

Prompting for voice is a skill to build, not a reflex to transfer. Teams that treat the two disciplines as one pay for it in production. Teams that listen to their prompts before publishing...

The full article lives on Scenaro: Voice Prompt Engineering: A Discipline of Its Own

If you prefer the series by email: https://scenaro.substack.com/subscribe

Realtime vs Separate Pipelines: Choosing the Right Voice Architecture

Rémi Henriot — Sat, 25 Jul 2026 12:00:26 +0000

Realtime vs Separate Pipelines: Choosing the Right Voice Architecture

Everyone wants realtime. Not everyone needs it. Latency isn't a religion, it's a setting, tuned per use case.

Everyone wants realtime. Not everyone needs it. Latency isn't a religion, it's a setting, tuned per use case.

Since GPT-4o Realtime, "real time" has become the magic word in boardrooms. The demos are stunning: 200ms latency, natural interruptions, a conversation that finally feels like a conversation.

So teams demand realtime. Everywhere. For everything.

That's an architecture mistake dressed up as ambition. You're choosing the thrill of the demo, not the fit of the use case. And the invoice follows.

What the Hype Doesn't Show

Realtime processes audio natively, with no intermediate transcription. It's real, it's impressive, and it comes with three trade-offs the demos gloss over.

Cost. Native speech-to-speech is structurally more expensive than a separate pipeline. At volume, support, lead qualification, the gap isn't marginal, it's budgetary.

Voice. In a pure realtime stack, synthesis is baked into the model. Less TTS customization, no cloned voice. Your brand's voice becomes the provider's voice.

Fit. A user exploring a catalog by voice deserves 200ms. A prospect recording an async message will never hear the difference. Paying for realtime there is burning budget on a thrill nobody feels.

Two Architectures, One Setting, Not a Doctrine

At Scenaro, each scenario chooses its architecture. It's not a platform decision, it's a per-context setting.

The realtime model: native audio, roughly 200ms, natural interruptions. Ideal when conversational fluency is the differentiator, a premium advisor in full duplex, voice-driven product exploration. Trade-off: less control over the voice.

The STT→LLM→TTS pipeline: 800ms to 1.5s, but full control over every layer. You pick your transcription engine, your model, your voice, cloned if needed. Ideal for volume, cost control, and sonic identity.

And in between, the hybrid variant: realtime inference, separate voice synthesis. Realtime speed on reasoning, freedom on voice.

The Right Question

The right question isn't "realtime or not?" It's: what latency, what voice, and what cost fit this specific scenario?

A wine advisor in full duplex on a homepage justifies realtime. A qualification scenario in push-to-talk doesn't need 200ms, a separate pipeline does the job at a fraction of the cost, with the brand's exact voice.

That's why at Scenaro the choice happens scenario by scenario, in the Cockpit. The same conversational experience can run a realtime scenario and a pipeline scenario side by side. You compare, measure, adjust. Scenario versioning even lets you test one architecture against the other on the same journey before rolling it out.

The most expensive mistake never changes: deploying realtime everywhere because the demo impressed, then discovering on the invoice that most conversations never needed it. Voice architecture is decided per use case. Never per trend.

The full article lives on Scenaro: Realtime vs Separate Pipelines: Choosing the Right Voice Architecture

If you prefer the series by email: https://scenaro.substack.com/subscribe

STT, LLM, TTS: The Full Stack Behind a "Simple" Voice Assistant

Rémi Henriot — Thu, 23 Jul 2026 12:00:10 +0000

STT, LLM, TTS: The Full Stack Behind a "Simple" Voice Assistant

"Plug in OpenAI and you're done" is the most expensive lie in voice AI. A voice that answers is three layers, fifteen-odd providers, and a trade-off at every link.

"Plug in OpenAI and you're done" is the most expensive lie in voice AI. A voice that answers is three layers, fifteen-odd providers, and a trade-off at every link.

A visitor asks a question out loud. They get a natural answer in under a second. From the outside, it looks like a product. From the inside, it's a chain: one layer transcribes speech (STT), one generates the answer (LLM), one speaks it back (TTS).

Three layers. Three decisions. And one unforgiving rule: a slow or wrong link degrades the whole chain.

The problem isn't that this complexity exists. It's that most teams only see it after they've made the wrong calls.

The Naive Stack

The reflex is always the same: "We're using OpenAI, right?"

One API key, one contract, one invoice. It's comfortable. And that's exactly the trap: you're not choosing a stack, you're choosing procurement convenience. Every layer inherits a default provider, not the best one for the job.

Why Each Layer Deserves Its Own Decision

Transcription first. An STT model that shines on standard English can stumble on a regional accent or domain vocabulary. And a faulty transcription in produces an absurd answer out, the user doesn't hear "the STT failed," they hear "this assistant is stupid."

Voice next. A voice is a brand asset, just like a logo. "Serviceable" isn't enough for a premium brand: some engines deliver richer prosody, others let you clone a real ambassador's voice. That's a deliberate decision, not a default setting.

The model last. Complex reasoning, long instructions, multilingual contexts: no LLM wins everywhere. The right model depends on the task, and the right LLM tells you nothing about the right STT.

How Scenaro Composes the Chain

Scenaro is built on LiveKit, a battle-tested real-time engine, with fifteen-odd provider plugins: Deepgram, ElevenLabs, Cartesia, Mistral, OpenAI, Google, and more. Each layer is chosen independently, on its own latency-cost-quality trade-off.

The decisive part: the chain is configured per scenario, in the Cockpit. Swapping the STT, the LLM, or the voice is a setting, not a rewrite of the conversational experience. Business logic, scenarios, memory: nothing moves.

This is what runs in production at Club Français du Vin, Urbansider, and Lupi. Same chain, different settings, because a travel concierge and a wine advisor don't share latency constraints or a voice.

And that's the real test of a voice architecture: not the day-one demo, but how easily you change your mind at month three. Teams that freeze their stack at launch discover in production that the default provider wasn't the right one, especially on STT. That recalibration should be routine, not a rebuild.

A voice assistant isn't a product. It's an assembly of decisions. The right architecture gives each layer the best provider for your context, and lets you change your mind without rebuilding anything.

The full article lives on Scenaro: STT, LLM, TTS: The Full Stack Behind a "Simple" Voice Assistant

If you prefer the series by email: https://scenaro.substack.com/subscribe

Perceived Latency: The Invisible KPI Killing Voice Experiences

Rémi Henriot — Sun, 19 Jul 2026 12:00:08 +0000

Perceived Latency: The Invisible KPI Killing Voice Experiences

Your teams track conversion, NPS, session time. Nobody tracks the assistant's silence. Yet that's what drives users away.

Your teams track conversion, NPS, session time. Nobody tracks the assistant's silence. Yet that's what drives users away.

There's a precise moment when a voice experience tips from "fluid" to "broken." It's not the wrong answer. It's not the crash. It's the silence: the user asks a question out loud, and nothing happens.

The threshold is known: roughly 800 milliseconds of unmanaged silence, and the illusion collapses. In a real conversation, a pause that long is filled by a glance, a breath, a "hmm", signals that say "I heard you, I'm thinking." Remove them, and the same pause turns anxious. The user wonders: did it hear me? Is it thinking? Did it crash?

A collapsed illusion of conversation doesn't rebuild. The user won't leave a negative review. They'll just stop using it.

The KPI nobody looks at

The voice hype produced dashboards full of familiar metrics: conversion, NPS, session length, drop-off. Useful, and blind to the problem.

The time between the end of the user's utterance and the start of the agent's response shows up nowhere. Google Analytics doesn't see it. Session recording tools capture it poorly. Yet it's the first quality signal users perceive, before they've heard a word of the answer.

Cognitive science is unambiguous: beyond 700-800ms with no processing signal, the brain reads the pause as an error, not as thinking. The experience doesn't degrade gradually. It breaks.

Technical latency isn't perceived latency

Confusing the two is the most widespread mistake in voice deployments.

Technical latency is actual processing time: transcribing the voice, generating the answer, synthesizing speech. On a classic pipeline, expect 800ms to 1.5 seconds. Not catastrophic in absolute terms.

Perceived latency is what the user feels. And it can be engineered independently of the tech. A human doesn't go mute while looking something up: they say "let me check that…" and keep working. An audio or visual processing signal massively reduces perceived latency, at identical technical latency. With nothing, 800ms is an eternity.

At Scenaro, this principle is built into the agent itself. It exposes a state, listening, thinking, speaking, synchronized with the interface. And it's designed to talk while it works rather than leave dead air. Unmanaged silence isn't an incident: it's a design flaw.

The extreme case is the long wait. At Urbansider, building an itinerary takes real time, tens of seconds of search. Rather than hiding that wait behind a spinner, the experience transforms it: while the search runs in the background, the agent offers the traveler an interlude, a piece of Parisian culture, a neighborhood guide, a French word to learn. Pedagogical content, a relaxed tone, a touch of the unexpected. The wait stops being a hole in the conversation: it becomes a moment of the experience.

Latency is a choice, scenario by scenario

The other mistake is treating latency as a single number to optimize. It's a trade-off, and it's made per scenario.

Two architecture families exist. Realtime: 200-400ms, full duplex, natural interruptions, the architecture of fluid conversation, at the price of less flexibility on voice...

The full article lives on Scenaro: Perceived Latency: The Invisible KPI Killing Voice Experiences

If you prefer the series by email: https://scenaro.substack.com/subscribe

When to Use Voice — and When to Stay Quiet

Rémi Henriot — Fri, 17 Jul 2026 12:00:09 +0000

When to Use Voice, and When to Stay Quiet

"Voice everywhere" is a design mistake. An intrusive voice assistant is worse than a search bar.

"Voice everywhere" is a design mistake. An intrusive voice assistant is worse than a search bar.

There's a moment in every conversational project when someone says: "what if we made this voice?" Good question. The default answer, voice everywhere, enabled on every page, for every user, is the wrong one.

We know how that ends: an agent talking while the user reads a spec sheet. Interrupting a comparison to ask an open-ended question. Requiring people to speak out loud in an open-plan office. More irritation than fluidity.

Voice isn't a universal mode. It's a contextual choice. And that choice deserves a policy, not a toggle.

Voice takes up headspace

That's its power and its limit, and everything else follows from it.

In discovery, a user arriving with no specific intent, hesitating between categories, voice is ideal. It steers without pushing, reframes fuzzy needs, builds a relationship. Exactly what a good salesperson would do.

In analysis, it becomes an obstacle. A user comparing two spec sheets wants to read, pause, go back. The brain can't process spoken language and dense text at the same time. An agent talking through that moment isn't advising, it's disrupting.

Add the social context: open office, public transit, café. Speaking out loud there is impossible or uncomfortable for most people. That's not an edge case, it's a huge share of real-world usage.

"Voice everywhere" ignores all of it. It turns voice's greatest asset, presence, into a deterrent.

An activation policy, not a setting

The answer isn't to walk back from voice. It's to calibrate it by context, like an experience policy.

At Scenaro, four modes cover the spectrum. Full duplex, agent and user speak and interrupt each other naturally, for discovery and advisory. Discreet mode, the agent listens to voice but replies in writing, for public settings and content meant to be read. Push-to-talk, the user triggers when they choose, for support and noisy environments. Text→audio, the user types, the agent speaks, for busy hands.

These aren't toggles. They're design commitments, activated by context: full duplex on the homepage, discreet mode on a product page, push-to-talk in support. Urbansider, a travel concierge in active production, ships this "discreet mode" to its travelers, because nobody talks out loud to their phone on the Paris métro.

And context shifts mid-session. A user arriving in discovery benefits from full duplex; ten minutes later, deep in spec sheets, the same user needs the agent to go quiet or switch to text. On Scenaro, these transitions are defined at the scenario level, not just the page level.

That's a lesson learned in production. On Club Français du Vin, our first experience, the voice conversation ran continuously, and some users wanted to browse in silence. Urbansider, the next generation, draws the conclusions: the agent can be paused at any moment, the map can be explored without narration, and every screen offers a button to ask the agent to narrate, when the user decides. Voice stays permanently available. It's no longer permanently imposed.

Technical tempo follows usage tempo

The voice mode...

The full article lives on Scenaro: When to Use Voice, and When to Stay Quiet

If you prefer the series by email: https://scenaro.substack.com/subscribe