Talker–Reasoner
A System 1 model keeps the conversation live while a System 2 model works in the background.
Problem
Voice and live chat need replies within about a second, or the conversation feels broken. But the tasks people ask for, like rebooking travel or diagnosing an account, need multi-step reasoning and tool calls that take far longer. One model can’t be both instant and thorough.
- Conversation needs sub-second turn-taking and natural acknowledgements.
- Real work needs reasoning and tools that take 5–30 seconds or more.
- The user may keep talking, change their mind or add details mid-task.
- Two models that each hold part of the state can contradict each other.
Solution
Split the agent into two roles that run at the same time. The Talker is a fast model that owns the conversation: it acknowledges, asks clarifying questions and relays results in natural language. The Reasoner is a slower model that owns the task: it plans, calls tools and writes its findings and current beliefs to a shared memory. The Talker reads from that memory on every turn, so it can say what’s known so far without waiting, and it passes new user input to the Reasoner as updates.
Diagram
The two models never block each other. Shared memory is the contract between them, so the Talker only says what the Reasoner has written down.
When to use
Use it when
- Voice agents or live chat where silence feels broken
- Tasks need tools or reasoning that take many seconds
- Users add details or change requests while work is in progress
- You want the conversational tone tuned separately from task logic
Avoid it when
- Tasks finish in a second or two; one model is simpler
- Asynchronous channels like email where waiting is fine
- You can't afford two models running for every session
Trade-offs
Gains
- Natural, responsive conversation even during long tasks
- Users can add details mid-task without restarting it
- Tone and task logic can be tuned and evaluated separately
Costs
- Two models and a shared state store to run and monitor
- Race conditions when the user changes the request mid-task
- Risk of the Talker promising something the Reasoner hasn't confirmed
Worked example
A voice travel agent for a corporate travel desk. The traveler's 3pm flight was cancelled.
- Traveler“My 3pm to Seattle got cancelled. Can you rebook me?”
- TalkerReplies in about 400 ms: “Sorry about that. I’m checking options now. Do you still need to land before your 6pm meeting?”
- ReasonerStarts in parallel: pulls the booking, searches same-day flights, checks fare policy. Writes
status: searchingto memory. - Traveler“Yes, and I’d prefer an aisle.”
- TalkerPasses
constraint: land_by 17:30, seat: aisleto the Reasoner and says “Got it, aisle and before 5:30.” - ReasonerAfter 11 seconds, writes two options: a 4:10pm in-policy flight landing 6:20pm, and a 3:45pm flight landing 5:15pm that is $140 over policy. Flags that the second needs manager approval.
- TalkerReads both from memory and explains the trade-off in two sentences. It doesn’t claim either is booked.
Failure modes
| Failure | Symptom | Mitigation |
|---|---|---|
| Talker overpromises | Says "you're booked" before the Reasoner has confirmed | Talker may only state facts present in shared memory |
| Stale constraints | Reasoner finishes using details the user already changed | Version the task state; Reasoner re-checks before final output |
| Awkward silence or chatter | Talker repeats "still working" or goes quiet | Reasoner writes progress updates the Talker can relay |
| Split-brain | The two models hold different beliefs about the task | One shared memory as the source of truth; Talker keeps no task state |