Inspiration
Translation is not the same as shared understanding. A shop owner can promise Friday, a customer can hear Monday, and both can leave the call believing the other person agreed. The words crossed the language gap; the commitment did not. That failure creates missed work, repeated calls, damaged trust, and real cost for multilingual small businesses, service providers, remote teams, and customers.
Conversate already makes private translated voice conversations possible. During OpenAI Build Week, we meaningfully extended it with Conversate Confirm: an optional, consent-first outcome layer that turns the conversation into a bilingual agreement both participants can inspect, correct, and approve.
What it does
Before anyone speaks, both participants separately decide whether to enable Confirm. If both opt in, Conversate temporarily captures bounded source-turn text. Conversate does not write raw microphone audio to its application database or application logs; OpenAI's API data controls still apply. After the conversation, GPT-5.6 creates a strict-schema bilingual card containing agreements, action items, owners, deadlines, unresolved questions, and details that need confirmation.
The card is not treated as truth. Either participant can correct it. Every correction creates a new version and resets both approvals. Prompt text, working turns, unapproved drafts, and correction history are not written to Conversate's durable repositories. After same-version dual approval, Conversate retains the approved card with limited approval, owner, expiry, schema, and configured/requested model metadata. Logical access ends after 30 days, and the authenticated room owner can delete the card sooner from the judge workspace.
How we built it
The new extension spans shared TypeScript schemas, a Fastify API service, React participant UI, PostgreSQL approved-card persistence, OpenAI Responses API Structured Outputs, OpenAI Realtime source transcription, authorization, bounded process-local mutation deduplication, cancellation, retention, and a dedicated Cloud Run judge sandbox. The sandbox has separate service, database, service account, and secret bindings. The production deployment, service, database, and Stripe configuration remained unchanged; the competition branch was deployed only to the dedicated judge sandbox. The shared Google OAuth client was updated only to authorize the exact sandbox origin.
GPT-5.6 performs the semantic work: extracting a bilingual shared outcome from bounded multilingual turns. Deterministic code owns the safety boundary: consent, authorization, schema validation, versioning, dual approval, retention, deletion, rate limits, and fail-closed behavior.
Confirm is deliberately distinct from both meeting notes and e-signature. Meeting summaries are usually unilateral memory aids; e-signature starts with a prepared document. Confirm begins with a live multilingual conversation only after separate bilateral opt-in, lets either participant correct the same bilingual version, resets both approvals after every edit, and persists only the version both participants approve. It is not a legal signature or a guarantee of translation equivalence.
How we collaborated with Codex
Codex with GPT-5.6 mapped the existing repository, implemented the shared
Confirm schema, Fastify API, and participant UI, and hardened consent
withdrawal, concurrent corrections, approval races, cancellation, and failure
handling. It also accelerated adversarial review, test generation, and
deployment diagnosis. We used a dedicated dated Codex session and preserved
its /feedback session ID for judging.
Key product decisions remained human-directed: build an outcome rather than a transcript, require consent from both people, reset approval after any correction, persist only a mutually approved version, and isolate the judge sandbox from production. Codex repeatedly challenged those decisions against failure modes and helped turn them into executable invariants and tests.
Challenges
The hardest engineering problem was preserving a trustworthy privacy and concurrency boundary around asynchronous speech and model calls. Consent can be withdrawn while transcription or generation is in flight; room end and expiry can race provider startup; corrections and approvals can be retried or arrive out of order. We added room-scoped cancellation, participant mutation queues, expiring process-local mutation deduplication, version snapshots, monotonic polling, bounded capture, and sanitized error boundaries so late work cannot restore cleared content or approve the wrong version.
The live sandbox also exposed a useful integration truth: the original translation lane could deliver audio but not the source text Confirm needs. We kept the feature fail-closed, diagnosed the mismatch, and moved the isolated sandbox to Conversate's separate app-specific OpenAI Realtime lane. The final two-person spoken English/Spanish flow then passed end to end.
Accomplishments
- A complete two-participant product flow, not a prompt demo.
- A substantial post-baseline extension spanning shared schemas, API behavior, participant UI, persistence, cancellation, and adversarial tests.
- The published V6 video freezes the earlier 571-test demo-head count; final exact-head CI passes the repository-wide Vitest suite—62 files and 578 tests.
- The configured Playwright matrix passed; its 114-test desktop Chromium run includes 21 Confirm-specific flows.
- Separate consent, bounded transient capture, strict schema output, corrections, same-version dual approval, approved-only persistence, expiry, and deletion.
- A live dedicated sandbox that passed owner login, invitation, two-way spoken translation, GPT-5.6 generation, version reset, dual approval, listing, and deletion.
- No application reuse of browser, operator, Codex, ChatGPT, or OpenClaw OAuth credentials.
What we learned
An AI-generated summary is easy; a mutually governed outcome is a product. The model should propose meaning, not decide truth. Trust comes from giving both people equal power to challenge the proposal and from making the deterministic system enforce what can be captured, approved, retained, and deleted.
What's next
Next we will validate the interaction with consented multilingual small-business users, measure whether approved cards reduce follow-up clarification, expand owner card management, and move from the single-instance judge topology to a distributed transient-state design before any broader production enablement.
Built With
- codex
- fastify
- google-cloud-run
- google-cloud-sql
- google-secret-manager
- gpt-5.6
- openai-realtime-api
- openai-responses-api
- playwright
- postgresql
- react
- typescript
- vite
- vitest
- websockets


Log in or sign up for Devpost to join the conversation.