Pattern Matrix/White Paper/R5

Problem

Many reasoning patterns assume the user can wait. That may be acceptable in an asynchronous task but not in a live conversation or voice interface. The engineering problem is the period of silence while deep analysis runs.

Talker-Reasoner assigns interaction and deep analysis to separate agents. The Talker meets the product's first-response budget and gathers clarification; the Reasoner runs in the background; both coordinate through a shared belief state.

Classification: Reasoning × Hierarchy

• Vertical axis · Reasoning: It separates two reasoning modalities, real-time response and deep reasoning, into a dual-process reasoning architecture — corresponding to Kahneman's System 1 (fast, automatic, low-cost) and System 2 (slow, deliberate, high-cost). This is an engineering mapping of cognitive science onto agents, not a single reasoning channel.
• Horizontal axis · Hierarchy: The Talker is in front (fast, shallow) and the Reasoner behind (slow, deep). This is a layered division of labor, not parallel competition. The two differ in responsibility, model, and timing. The Reasoner's output influences the Talker's answer through the belief state, an upper-layer–lower-layer collaboration.

Solution and mechanics

A single dual-process round consists of three parts:

1. Talker responds within the interaction budget: A fast model keeps the conversation moving, acknowledges the request, and asks clarifying questions. Its output contract prevents unverified concrete advice before analysis completes.
2. Reasoner thinks asynchronously: A more capable model performs deep analysis in the background and writes structured conclusions to the shared belief state without blocking the conversation.
3. Belief state coordination + natural bridging: The two agents communicate through one shared state; writes must take a lock to avoid race conditions. After the Reasoner finishes, the Talker weaves the analysis into its reply at a natural moment in the next turn, rather than abruptly producing a block of conclusions.

There are three options for handling user input while the Reasoner is still running: QUEUE (wait in line for the Reasoner to finish, suited to task scenarios), INTERRUPT (immediately interrupt and rerun, suited to short exploratory tasks), and PARALLEL (the two agents truly run in parallel, the Talker replying immediately while the Reasoner runs in the background — conversation scenarios must use this). Make the three a config so the product can choose per scenario.

Applicability

• Real-time conversation: Tutoring, customer service, and personal assistants where first response and deep analysis have different latency budgets.
• Voice agents: Phone and voice assistants where prolonged silence breaks the interaction.
• Advisory scenarios that gather information while chatting: While the Talker chats with the user about preferences and asks follow-ups, the Reasoner runs matching analysis in the background on the information already collected, so the analysis is ready by the time the chat ends.

Known failure modes

• The Talker gets clever and guesses the answer: If the Talker prompt does not firmly nail down "do not give concrete advice," it rushes to offer conclusions, which conflict with the Reasoner's deep analysis and waste the Reasoner's run. This is the most common failure mode of the dual-process design.
• The Reasoner has no timeout or cancel: A background task can continue after the user changes topic. Add a configured timeout and active cancellation tied to the conversation state.
• The belief state is not persisted across sessions: When the user returns next time, the Talker starts from scratch and all of last session's Reasoner analysis is lost. Persist it to Redis / PostgreSQL.
• Stiff bridging: The Reasoner finishes and "abruptly drops a block of analysis," which feels jarring to the user. Use the prompt to make the Talker find a natural moment in the conversation to insert it.
• Forcing the dual-process design onto asynchronous tasks: In scenarios where the user submits a task and leaves (writing documents, batch processing), there is no need for a Talker; just let the Reasoner run slowly. Adding a Talker is over-engineering.

Verification and metrics

• Talker response latency p99: Compare with the single-agent first-response baseline and the product's interaction budget.
• Talker overreach rate: Sample whether the Talker gives concrete conclusions before the Reasoner finishes. Fix violations in the output schema, prompt, or permissions.
• Belief hit rate: Verify that later turns retrieve and correctly use confirmed belief state without stale or cross-user contamination.
• Per-turn cost (note the structure): The dual-process design runs "two tiers at once," so per-turn cost is slightly higher than the single expensive tier alone (the Talker part is added), but in exchange latency drops sharply. This is another Pareto choice on the cost-latency-quality triangle, to be assessed against business tolerance.

Reference implementation

User speaks →
                If first turn: create belief state, asynchronously trigger Reasoner (non-blocking)
                Talker replies within interaction_budget (fast model, no unverified advice)
                If Reasoner has finished (belief status = updated) → Talker weaves the analysis naturally into the reply
            Reasoner in background (more capable model):
                Deep analysis → write belief state (structured conclusions + recommendations)
                With configured timeout + cancel when the user changes topic
            belief state: persisted across sessions, writes take a lock
            Return Talker reply + the background-maintained belief
            

Four points for implementation: the Talker prompt firmly nails down "no concrete advice"; the Reasoner async task has a timeout and cancel; the belief state is persisted to Redis for reuse across sessions; writes to the shared state take a lock to prevent race conditions.

Illustrative scenario

Consider a study-abroad advisory agent. When a user asks which school fits better, the Talker first acknowledges the comparison and asks what outcome matters most. The Reasoner evaluates grades, research experience, and interests in the background and writes its conclusion to the belief state. On the next turn, the Talker incorporates the result alongside the user's new preference. A tutoring system can use the same split with separate teacher and student trace views. First-response latency, final quality, and human override should be measured independently on real sessions.

Related patterns

• Complexity Routing (R2): The dual-process design is the architectural extreme of routing. Ordinary routing "picks one tier to run" (a single-point-in-time decision); the dual-process design "runs two tiers at once" (a two-time-dimension decision), pushing "tier selection" all the way to "splitting the agent."
• Iterative Hypothesis Validation (R4): Both sit in the Loop column. Iteration is a single agent looping with itself to validate hypotheses; the dual-process design is two agents collaborating, separately handling "speaking" and "thinking."
• Chain of Thought (R1): The deep reasoning on the Reasoner side is essentially a complete chain of thought; the Talker side deliberately does not do deep reasoning.
• Hierarchical Memory pattern: The belief state persists across sessions, which shares its lineage with the memory module's "User-layer belief persistence."

Design conclusion

The essence of Talker-Reasoner is not performance optimization but splitting the agent's persona into two — one handling real time, one handling depth. What the Talker gives is not a preview of the Reasoner; it is content of an entirely different nature, two mental modes collaborating.