This is a sales artifact, and I mean that as a compliment to a specific kind of engineering. Under the AgentDune banner, I needed to show ARASCO, a Gulf agribusiness giant with six business units, 550 trucks, and five million metric tons of annual cargo, what voice AI would feel like in their business, not in a generic demo. Nobody buys “sub-second latency” off a slide. They buy hearing an agent answer in Saudi-dialect Arabic, look up order one-two-three-four-five, and know that Entaj chicken is stocked at Carrefour and Tamimi. So the demo is built entirely out of their world: real business units, real branch networks, real product lines, with mock data behind the tools that returns realistic answers instead of lorem ipsum.
I’ll be honest about the foundation: the WebRTC plumbing started from an open-source Next.js starter for OpenAI’s Realtime API, and I kept what worked, including the use-webrtc hook, the session route, and the shadcn UI bones. The value I added lives in two files that starter never imagined: a 364-line persona registry and a 426-line tool library. That split is the actual lesson of the project: for enterprise voice AI, the transport is a solved commodity, and everything that determines whether the demo lands is prompt and tool design.
Six personas, because one agent that does everything does nothing well
Instead of one omniscient assistant, there are six narrow ones, each mapped to a real ARASCO function: a customer-service receptionist that routes callers across the six business units, an order-and-delivery tracker for B2B customers, an agricultural technical-support agent for farmers, a food-safety lab coordinator, a veterinary health advisor, and a retail assistant for the Entaj chicken brand. Each persona carries its own voice (ballad, ash, sage…), its own greeting, its own escalation rules, and, critically, only the tools its job needs, drawn from a pool of 30+: order lookup, live truck tracking, delivery rescheduling, feed-requirement calculations, branch inventory checks, lab test bookings. The receptionist can’t reschedule a delivery; the vet advisor can’t quote retail stock. Scoping tools per persona isn’t just security hygiene; it measurably improves tool selection. A model choosing among six relevant functions misfires far less than one choosing among thirty.
Voice prompts are their own discipline
Writing instructions for a voice model taught me things text chat never forces you to learn. Numbers must be spelled out word by word, as in “order one two three four five,” because a TTS voice reading “12345” produces something no customer should hear a phone number become. Responses are capped at two to three sentences, because in audio, a paragraph is a monologue you can’t skim. Escalation is scripted per domain and taken seriously: disease symptoms or mass-mortality reports don’t get chatbot advice; they get an immediate handoff line in whichever of the two languages the caller is using. And the bilingual behavior is engineered, not hoped for: English and Arabic only, follow the customer’s language, switch instantly when they do, and address a farmer as أستاذ because register matters in Saudi customer service. The same Realtime-API-over-WebRTC muscle later went into Zodega’s voice shopping assistant; this project is where I learned most of what made that one good.
The app around the conversation is built to be watched as much as talked to, with live Whisper transcription and interim states, tool results visualized alongside the call, and real-time token usage, because in a demo for executives, the people not on the microphone need to see the machine thinking.