Outverse

Our customer had high call volume, strict account verification, regional language needs, and an existing Talkdesk and Salesforce stack. We'd not yet branched our agent into Voice, so this was about quickly exploring how voice agents could/should work for Outverse.

The agent graph

In the interest of speed - we used ElevenLabs to power our prototype voice agents - it enabled me to get started immediately building out the agent graph and it's pathways.

FIG 01 / GRAPH VIEW OF AGENT

Authentication - The agent authenticated callers by matching a name and ID against a mock Airtable DB via tool use. Verified callers could then ask their query and the agent would route depending on the intent.

General support - For general queries, the agent drew on an uploaded knowledge base of product docs to answer.

Invoice requests - Customers were often calling requesting invoices - whilst this was something they could self serve, we wanted to also equip the agent with the ability to look up the customers invoices, and if requested send it to them.

Downgrades/Cancellations - When the agent detected cancellation or downgrade intent, it routed to a retention pathway - letting the caller know it needed to transfer to a human, then handing off to Talkdesk.

Prototyping the interface

ElevenLabs powered the agent, but I wanted to explore how it would live inside Outverse. Their SDK @elevenlabs/react made this straightforward.

The sandbox let us start a call directly inside Outverse and talk to the voice agent in-browser. When the call ended, the API pulled the conversation into the history view — where the recording could be played back and the transcript, workflow events, routing decisions, and tool calls displayed inline. Full observability of every call, not just the audio.

FIG 02 / SURFACE FOR USERS TO START CALL / VIEW CALL HISTORY

FIG 03 / A viewable call transcription

Using coding agents to iterate on the agents

ElevenLabs also has a CLI, which let me use Claude/Codex to pull my live agent config, simulate calls, and build a test-tweak-review loop programatically

Automating the demo pipeline

I built a Notion agent to automate the setup for new voice-agent demos. It used Firecrawl to pull details about a prospect company - their product, support docs, help center content - and synthesized that into a system instruction prompt.

Outverse’s AI agents were resolving thousands of tickets across channels but the conversation data behind those resolutions was going underutilized.

Dashboards are great for high level metrics, but are rigid - conversational interfaces are great for queries that require flexibility in answers, but tiring to consume. Generative UI sits between the two : A richer experience that's easier to scan and angaging and flexible enough to assemble around whatever the user asks.

Prototype

I built the prototype in our internal design playground — a repo I created that mirrors our product surfaces using Next.js, ShadCN, and Tailwind. I used Chris Tate’s JSON Render as the foundation, which let the agent return structured UI (charts, metrics, drilldown tables) rather than just paragraphs. The frontend assembled those components dynamically from the agent’s JSON spec, making it feel like a product surface rather than a chatbot.

FIG 1 / WORKING PROTOTYPE USING OPENAI RESPONSES API & JSON RENDER

For data, I generated a realistic synthetic dataset - support conversations, CSAT scores, intents, channels, outcomes - so I could test whether the responses felt genuinely useful to a support operator.

MCP as an additional entrypoint

When it comes to being able to query your data, Its quickly becoming table stakes to allow your product to be queryable from other AI tools, think claude, co work, chatgpt, codex.

FIG 2 / PROTOTYPE MCP SERVER INSIDE OF CLAUDE

Agent native

Whilst I initially prototyped the VOC agent in our existing interface, I think soon most tools will look like users talking with agents that drive user interface. This was some exploration into how we could shift our interface to enable that!

FIG 3 / AGENT NATIVE UI ENTRYPOINT