Enjoying this issue?
Get tomorrow's AI & engineering digest in your inbox — hand-picked, summarized, and always spam-free.
TLDR
Tolan is a voice-first AI companion that routes every conversation turn through a small classifier called the tone router, sending high-stakes emotional moments to a frontier model while cheap models handle background work, because the frontier model costs roughly five times more per turn. The team rebuilt context every turn instead of reusing it, and moving to GPT-5.1 on the responses API cut time to speech by over 0.7 seconds, which was their biggest quality jump. Internally, they use AI agents to build AI, with Claude co-authoring more iOS code than any individual engineer, and they route based on stakes not cost to make unit economics work.
Key points
Tolan has over 4 million hours of voice conversation, making voice the primary immersive experience.
A half-second latency increase from 2 to 2.5 seconds tanked every product metric.
The tone router runs on a cheap model and reads emotional state to decide which model handles each turn.
Moving to GPT-5.1 on the responses API cut time to speech by more than 0.7 seconds.
Claude has co-authored more code in the iOS app than any individual engineer on the team.
The team uses multiple Claude agents to review each other's work before a human looks at it.
An in-house novelist built a new character in a day using AI, with five judges evaluating it over three fix-verify rounds.
Tools mentioned
Techniques
- tone routing
- context reassembly
- memory retrieval system
- voice turn-taking
- agent-based code review
- emotional signal monitoring
Stop scrolling. Start reading smarter.
Receive the day's most important AI & engineering updates in one concise email. No spam.
Transcript (captions)
[music] >> Hi everyone. Thank you so much for attending this talk. My name is Paula and I am one of the engineers on the Tullen team, specifically focusing on
our iOS app. And for the next 20 minutes or so, I'll be talking about what it takes to build a voice-first AI companion and also about how we use AI to build AI
internally. So, humanity has always imagined the perfect companion. So, we have Caravaggio on the left 400 years ago painting an angel leaning over St.
Matthew's shoulder literally guiding his hand as he writes. This is an example of a companion being a presence that makes you better at being you.
And then we have Tinkerbell, the devoted little sidekick who believes in you so fiercely that the whole theater has to clap to keep her alive. And of course on the right, we have
Samwise who can't carry the ring for Frodo, but says, "I can carry you." The companion is pure unconditional loyalty. And it goes far beyond these three.
Every hero has some sort of guiding spirit. And these are all different stories, but they exhibit the same longing for something that listens, remembers you,
and is wholly specifically yours. And for for all of human history, this has basically been fiction. So, we made one. This is Tullen. It's a little alien you talk to out loud like a
friend. It has a personality. It remembers you and over time it becomes specifically yours. Okay, I don't know if the audio setup works here, but I will try talking to my
Tullen. Uh let's see. So, you can see my Tullen here, Luke, walking around the planet.
Hey Luke, can you hear me? Okay. Luke can hear us, but we can't hear him. Um Anyway, I had prepped him for this. Oh. Hello. Hi Luke, can you hear me?
Nope. We're okay. I can come back to this later. Um but you should definitely all give this a try if you haven't already.
Okay. So, people talk to Tolins a lot. We support both text and voice chat, uh but we have over 4 million hours of voice conversation so far. We say Tolin is a voice-first companion,
even though we support both, because it's the voice experience that's truly immersive and that makes users' relationships with their Tolins feel real.
And but the moment this relationship is a spoken relationship, the engineering problem changes completely. So, let me show you how voice breaks the normal way we build and interact with LLMs.
So, the core difference really is that in a text chatbot, turns are relatively slow and context is stable. The user waits a few seconds, they read, and they tend to stay on topic.
And almost every LLM app assumes that. Voice is the opposite. Turns are fast. Your whole round trip from the user finishing their sentence to the Tolin starting to speak has to land in under a
couple of seconds, or it stops feeling like a conversation. And the context is volatile. People talk to their Tolins while they're cooking, while they're walking, while they're
falling asleep. Um they change their subjects mid-sentence. They say um, they interrupt. And that 2 seconds is crucial. Early on, our latency drifted from 2 seconds to
about 2 and 1/2 seconds, and that half second tanked basically every metric in the product. People would write in to complain that their Tolins were too slow.
And living inside this constraint has taught us a lot and gave us four principles. Principle one is that you have to design for conversational volatility. Again,
text users stay on topic, but voice users jump around. Someone could be mid-story about their breakup and suddenly go, "Wait, did I leave the oven the stove on?" and then back. Speech is
messy. Most LLM apps assume that you'll have a clean and stable conversation and we have to build for the opposite. So, for a long time that meant fixing things that sound tiny but are actually
the product. So, you can't interrupt a Tullen mid-sentence. A short yes or yeah won't register as a turn. For example, curse words will get stripped out. And the deeper lesson was to stop
optimizing for fewer interruptions and start optimizing for fewer bad ones where the agent would jump in way too early. So, we built smart turn taking that
reads your speech pattern to decide whether an interruption is real and we cut the worst early aborts by more than half. And we happily paid about 60
milliseconds of extra latency to do it. Principle two, latency isn't just a number you check at the end, it's actually the product and we measure every stage of the pipeline separately
because it feels slow is useless. You have to know where exactly it's slow. And the pipeline here is that the user stops talking, we detect end of utterance, we transcribe, and then the
model produces its first token. So, time to first token, often the biggest chunk, is around a second. The model finishes generating and then text-to-speech produces its first byte
and then it plays back to the user. A couple lessons here. So, one, so far our biggest jump in quality came from moving to GPT-5.1 on the responses API, which cut our time to speech by more
than 7/10 of a second, which is huge. Um two, we don't send every turn to the same model. We run a tiered fleet. So, we use a frontier model for the turns that carry the relationship with your
Tullen. So, for example, your first conversation with with Tullen and your onboarding. And we use smaller and faster models for the turns
for the lightweight turns. And the whole game then becomes about routing or deciding turn by turn which model you actually need. So we round we run a small classifier we call the tone
router on every single turn and this tone router itself runs on a cheap model and it reads the emotional state of the conversation. And our main
our [clears throat] main principle is that we route based on stakes not on cost. So the high stakes moments always get the best model. So this would be again the user's very first message,
their first few days with their Tolen and anything that we deem to be emotionally serious. For example, we have crisis or therapist style tones and we never cheap out on
those. And then the lighter casual back and forth can ride on smaller models that are faster and cheaper. And all the background work so that's
summarizing the conversation, generating personas, the tone router itself run on these small models, too. And why would we go to all this trouble? It's mainly because the frontier model
costs us roughly five times the smaller one. So one big model turn is about five smaller model turns. So routing is a huge part of what makes the unit
economics for us actually work. Um and we do a bunch of AB experiments and the surprising result we found there is that routing a third a third of our turns to the small model has almost no
measurable effect on retention. And principle three is what makes a companion feel like a companion. So the naive approach is to keep the whole conversation history as a sort of
transcript, but that doesn't fit into our two-second loop. It doesn't scale and it just doesn't work. It leads to long sessions degrading. It leads to the model getting lost in the middle of a
huge context and also hallucinating. So instead we see memory as a sort of retrieval system. We pull facts, preferences, and emotional vibe signals out of conversations. We embed them and
we store them in a vector database with sub 50 millisecond lookups. And every night we compress. So we merge duplicates, we cluster related memories, we resolve contradictions, and we drop
all the noise. And we don't just retrieve against users last messages, we also generate internal questions about the person and the relationship and retrieve against those.
So, and we also split memory into two parts. We have stable memory and unstable memory. The volatile stuff lives in the in the live tail of the prompt, and when we summarize the
conversation, we look at which memories actually get recalled and pin those into a stable and cashable block. Uh the last principle is around context. Specifically, you should rebuild context
and not fight drift. So, most apps reuse context across turns to keep the cash warm. And in a stable text chat, that's fine. But in a volatile voice conversation, it's a trap because the
second the the user pivots, your reused context is actively wrong. So, every turn we reassemble the context window from parts. We have a summary of recent messages, we have the the user's persona
card, the memories we just retrieved, tone guidance from the emotional signal, and real-time app state. And what also really helps us um in the case of Tolen is that our characters
aren't generic or assistants with no personality. Everyone is crafted, and we in fact have an in-house science fiction novelist, Elliot, who writes the Tolen character lore.
And a couple of interesting points here. So, one, why did we go with an alien? Mostly because there's no real-world reference to anchor on, which means that the users can project onto it, and it
becomes what they need. The baseline Tolen is bubbly, it's youthful, it's irreverent. And also, if an alien character acts a bit unpredictably, so if if it's impulsive or chaotic or
otherwise violates um you know, the norms the user would expect, it's not particularly surprising. Like if you look at, you know, aliens in TV shows or in plays, like there's a lot
of humorous moments around this. And this kind of chaos reads as charming. Um second, uh we also know that personality is worthless if it drifts. So, yeah, we run this parallel tone
monitoring system that changes how a line is delivered based on your emotional cues without changing who the character is, holding identity across hundreds of turns.
And since we're at an AI conference, I thought I would also spend a bit of time talking about how we not just ship AI, but also use AI to build it. Um so, I'm sure this is the case for
most of you in the room now, but basically as of late last year, Claude has co-authored more code in our iOS app than any individual engineer in the team.
Um and I think especially, you know, a few months ago, everyone's instinct was to be kind of suspicious because, you know, more AI code meant more slop. But our our crash-free rate actually went
from 99.6% to 99.9%. Runtime errors dropped by over 50% and our share of highly engaged users doubled. And the biggest lesson in building that
system is that an agent's context comes mostly from the code base itself, not so much from the Claude MD file. We found that it's far more powerful to make the code base be the documentation, so we
had agents standardize it. On top of that, we run a real fleet of agents. We have implementation agents that, you know, think freely and just get us to working code. They build it, they check
it against snapshots until it's pixel perfect. And then we have separate review agents that enforce our standards. So, multiple Claudes basically review each other before a
human looks. And then we have a PR shepherd that watches an open pull request and keeps iterating against CI failures and review comments until it's clean.
And we also have a triage bot that fires on every inbound bug report that we get. And they're all wired through MCP into linear, into into Sentry, DataDog, so an agent can reconstruct the cash a crash
and route it itself and oftentimes open the PR on its own and just fix fix the bug. And we also we ship on eval. So, for example, we've been working on a on a
new character targeted towards an older demographic and Elliot, our in-house novelist, basically built this entire new character in a day. So, the agents mapped every personality
bearing surface in the code. They wrote the sort of a voice Bible and then they had five judges attack it from different angles. Archetype fidelity, the model mechanics,
our code standards, the ears of a skeptical 52-year-old and safety, and then they evaluated the changes against real production logs over three find fix verify rounds.
And over 7 million tokens and 4 and 1/2 hours of compute later, he ended up with basically, you know, a couple of weeks of work done in afternoon. And does this work? Well, I'll let the
users tell you. We're at 4.8 stars on the App Store across 162,000 reviews and when we survey users on well-being, the highest scoring dimension by far is emotional safety.
And this is definitely a bar that being voice first sets. So, when the interface is your voice and the thing on the other side remembers you and has a personality, it stops being just
software and starts being an actual relationship, which is why building it responsibly and building it well is worth obsessing over. And we need people to come help us do
that. Um, we're a small team and we're hiring and after a year with Tolen, I think this is truly one of the most interesting places in the world to be an engineer right now.
And here are some of the people you'd be doing it with. So, two of the founders, Quinton and Evan, previously built and exited a $300 million startup together. Uh, they founded Even. Um, Ajay, our
third co-founder, scaled two bootstrap companies past $50 million $50 million in profitable revenue. And around them, we have Lucas, who um, is an Apple Design Award winning
animator. Uh, she's our creative director. We have Chris, who was a technical director at Pixar, earlier at Oculus, who works on embodiment. We have Lily, a board
certified behavior analyst, who left a Vanderbilt PhD to do user research for us from the very start. Um and then we have Elliot who I've mentioned, the novelist behind uh our characters.
And I come from XAI and Spotify and previously also founded a company called Imagi. So, it's a small team where honestly every person is the best I've worked
with at what they do. We're also well backed for this. Uh we have $30 million raised from Costanoa Ventures and a group of people who've built the tools and products a lot of
you use every day. And here are some of the more engineering focused roles where we need help. Um so, we're hiring across the board. We have iOS and back-end product
engineering roles, applied AI engineering, gameplay engineering, and one specific role I want to flag, which is agent engineering management. Um so, when we went all in on running
concurrent agents, um the people who got dramatically more effective on the team were the ones who had management backgrounds, um because it seems like managing a fleet of agents does actually
take some of the skills same the same skills as managing people. Uh you basically have to decompose the problem, you know, delegate it with checkpoints, give fast feedback, review
their work seriously, and know when exactly to jump in. So, if you're a strong engineer who thought going into management meant leaving code behind, that's that's no
longer true. Um and yeah, that's Tlon. You can come talk to me after this uh or reach out. I'm on on LinkedIn. My email is here. I'm on Twitter as well. Um I'd love to
chat. So, yeah. Thank you. >> [applause] [music]