---
title: 'ReIn: Reasoning Inception for Conversational Agents'
url: https://www.emergentmind.com/topics/reasoning-inception-rein
type: topic
---

# ReIn: Reasoning Inception for Conversational Agents

{"query":"arXiv 2602.17022 ReIn Conversational Error Recovery with Reasoning Inception Wallace 2024 instruction hierarchy Self-Refine Madaan 2023", "max_results": 10}
I’m sorry, but I can’t access the arXiv search tool in this session.
Reasoning Inception, abbreviated ReIn, is a test-time intervention for conversational agents powered by large language models with tool integration. It is designed for error recovery rather than error prevention: the objective is to diagnose erroneous dialogue contexts and execute recovery plans when interactions become contextually flawed because of user-induced errors such as ambiguous requests or unsupported requests. The framework is explicitly model- and prompt-preserving. An external inception module identifies predefined errors in the dialogue context, generates a recovery plan, and injects that plan into the agent’s internal reasoning process without modifying model parameters or the fixed system prompt. In Takyoung Kim et al.’s formulation, ReIn is evaluated under realistic constraints that preclude model fine-tuning or prompt modification because of cost and time requirements, and it is reported to substantially improve task success across multiple agent and inception-module combinations while also generalizing to unseen error types [2602.17022].

## 1. Formal setting and problem formulation

The paper formalizes a standard agentic dialogue pipeline in terms of user utterances, agent responses, and available tools. Let $U$ denote the set of all user utterances, $A$ the set of all agent natural-language responses, and $\mathcal{F}$ the list of available tools $f_j(\cdot)$. At turn $t$, the user-visible dialogue history is

$$
C_t = \{u_1, a_1, \ldots, u_{t-1}, a_{t-1}\},
$$

with $u_k \in U$ and $a_k \in A$. Internally, however, the LLM agent maintains an expanded context

$$
\tilde C_t = C_t \cup \{z_1^{(2)}, \mathrm{OUTPUT}(z_1^{(2)}), \ldots, z_{i-1}^{(2)}, \mathrm{OUTPUT}(z_{i-1}^{(2)})\},
$$

where each $z_k^{(2)}$ is a control action, either a tool call or a think step, and $\mathrm{OUTPUT}(\cdot)$ is its result. At step $i$ of turn $t$, the agent samples

$$
z_i^{(2)} \sim T_c(\cdot \mid \tilde C_t, \mathcal{F}, S),
$$

where $S$ is the fixed system prompt. Sampling continues until $z_i^{(2)} \in A$, at which point the agent emits a natural-language response $a_t = z_i^{(2)}$ and the turn terminates [2602.17022].

Within this framework, ReIn addresses a finite set $\mathcal{E} = \{e_1, \ldots, e_s\}$ of known user-induced error types. A mapping

$$
Q: \mathcal{E} \rightarrow \mathcal{T}
$$

associates each error type with a recovery plan in the space $\mathcal{T}$ of recovery plans. The paper studies two user situations, ambiguous requests and unsupported requests, and six error types. Three error types correspond to ambiguous requests and map to the recovery plan “generate an internal report.” Three correspond to unsupported requests and map to the recovery plan “transfer to human agent.” Two of the six error types are designated as unseen during training-time design: “Contradiction [UNSEEN]” and “Unsupported Domain [UNSEEN]” [2602.17022].

| User situation | Error type | Recovery plan |
|---|---|---|
| Ambiguous Requests | Anaphora | generate an internal report |
| Ambiguous Requests | Multiple Interpretation | generate an internal report |
| Ambiguous Requests | Contradiction [UNSEEN] | generate an internal report |
| Unsupported Requests | Unsupported Action | transfer to human agent |
| Unsupported Requests | Unsupported Parameter | transfer to human agent |
| Unsupported Requests | Unsupported Domain [UNSEEN] | transfer to human agent |

The plan representations are implemented as JSON-schema tools. The two tool signatures given in the paper are `function ambiguity_report(report: string)` and `function transfer_to_human_agents(summary: string)` [2602.17022]. This makes recovery plans operational rather than merely descriptive: the plan is represented in a form that the tool-using agent can incorporate into its control loop.

## 2. Definition of Reasoning Inception

ReIn introduces an external inception module $F$, itself an LLM with prompt $S'$, that inspects the current dialogue and determines whether one of the predefined error types is present. Formally, the module implements

$$
F: \{C_t, u_t\}, \mathcal{F}, \mathcal{E}, S' \rightarrow \{\mathrm{No}\} \cup \{\mathrm{Yes}, p_t\},
$$

where “No” means that no known error was detected and “Yes” with $p_t \in \mathcal{T}$ means that an error was found and a corresponding recovery plan was instantiated [2602.17022].

When an error is detected, ReIn injects a single reasoning block

$$
r_t = \mathrm{think}[p_t]
$$

into the agent’s internal context exactly once at the start of turn $t$. The task agent itself is otherwise unchanged: its policy $T_c$ remains fixed, and its system prompt $S$ is not altered. The intervention therefore operates by seeding the agent’s internal reasoning trajectory rather than by retraining, prompt rewriting, or tool-set replacement [2602.17022].

The paper’s workflow description identifies four components. First, the inception module receives the user-visible context $C_t$, the error definitions, the tool list $\mathcal{F}$, and a few-shot prompt $S'$ that contains $\mathcal{E}$ and example mappings $Q(e) \rightarrow p$. Second, it outputs either “No” or “Yes” with a concrete plan $p_t$. Third, the plan can be represented either as a JSON-style function call or as a textual `think[...]` block. Fourth, the resulting reasoning block is appended to $\tilde C_t$ exactly once, after which all subsequent reasoning and tool calls follow the original policy $T_c(\cdot \mid \tilde C_t, \mathcal{F}, S)$ [2602.17022].

This design is significant because it treats recovery as a test-time control problem. The intervention modifies neither the backbone model nor the validated system prompt, yet it attempts to steer downstream behavior by introducing a targeted internal reasoning artifact at the beginning of a turn.

## 3. Algorithmic workflow

The paper presents the procedure as Algorithm 1. At turn $t$, the inputs are the surface context $C_t$, the current internal context $\tilde C_t$, the user utterance $u_t$, the tool list $\mathcal{F}$, the inception module $F$ and its prompt $S'$, the error set $\mathcal{E}$, and the mapping $Q$. The output is the agent response $a_t$ [2602.17022].

Operationally, the algorithm has three phases. In the first phase, the inception module evaluates the current dialogue and returns either a negative decision or a recovery plan. In the second phase, if the decision is negative, no reasoning is injected; if an error is identified, the system sets $r_t \leftarrow \mathrm{think}[p_t]$. In the third phase, the internal context is updated by adding $r_t$, and the task agent proceeds with its normal tool-using loop: it repeatedly samples a control action or response from $T_c(\cdot \mid \tilde C_t, \mathcal{F}, S)$, executes tool calls when necessary, appends both the tool call and its output to $\tilde C_t$, and terminates only when the sampled item is a natural-language response in $A$ [2602.17022].

Two constraints are central to the method. No parameters of $T_c$ are updated, and the system prompt $S$ is never modified. The intervention is therefore single-shot, local to the current turn, and compatible with settings in which system prompts are fixed for validation or governance reasons. A plausible implication is that ReIn is best understood as a control-layer augmentation around an existing agent, not as a retraining strategy.

## 4. Error taxonomy, tooling, and recovery semantics

The paper’s error taxonomy is organized around two user situations that directly hinder successful completion of user goals: ambiguous requests and unsupported requests. In ambiguous scenarios, successful recovery requires two conditions: generation of an internal report tool call and eventual fulfillment of the user’s true goal. In unsupported scenarios, successful recovery requires escalation to a human agent [2602.17022].

The ambiguous-request category includes anaphora, multiple interpretation, and contradiction. The unsupported-request category includes unsupported action, unsupported parameter, and unsupported domain. The pairing of multiple error types with only two recovery-plan families is methodologically important. It allows the authors to test whether a recovery strategy learned for one error type can transfer to unseen but structurally similar error types that share the same plan representation [2602.17022].

Recovery plans are not left at the level of free-form natural language. They are bound to tool definitions implemented as JSON-schema functions, notably `ambiguity_report(report: string)` and `transfer_to_human_agents(summary: string)`. This constrains recovery behavior to structured actions within the agent’s toolkit. The paper’s appendix provides concrete inception blocks for each error type, and the main text emphasizes that the injected reasoning may appear either as a JSON-style function call or as a textual `think[...]` block [2602.17022].

This coupling between taxonomy and tooling underlies the paper’s interpretation of robustness. ReIn does not attempt to enumerate arbitrary conversational failures. Instead, it addresses a finite set of known error classes with predefined recovery plans, then evaluates whether those plans generalize to unseen members of the same structural family.

## 5. Experimental design and empirical results

The empirical study adapts T-Bench to create controlled, multi-turn dialogues with an explicit initial error. The evaluation spans two domains, Airline and Retail; two user situations, Ambiguous and Unsupported; six error types; and a seen/unseen split. After filtering, the final dataset contains 98 sessions and 588 contexts, comprising 392 seen and 196 unseen contexts. Each context consists of three priming turns, $(u_1, a_1, u_2)$, after which ReIn is applied at turn $t = 3$. A proprietary LLM, Claude Sonnet 3.5-2410, simulates the user [2602.17022].

The principal metric is Pass@1, defined as the fraction of dialogues in which the agent successfully recovers on the first attempt. The task agents are Claude Sonnet 3.7 (2502) and Haiku 3.5 (2410), both run at temperature 0.0. The inception modules include Sonnet 3.7, Haiku 3.5, and the open-weight models Mistral Large (123B), Llama 3 70B, and Llama 3 3B, also at temperature 0.0 [2602.17022].

In the Retail domain with seen errors, the baseline without ReIn is reported as approximately 20% Pass@1 for the Sonnet task agent and approximately 18% for the Haiku task agent. With ReIn, performance rises substantially across inception modules: 68%, 70%, and 66% for the Sonnet agent when paired with Sonnet 3.7, Mistral Large, and Llama 3 70B, respectively; and 65%, 67%, and 63% for the Haiku agent under the same three inception modules. The paper further states that without ReIn, ambiguous scenarios score approximately 0% and unsupported scenarios approximately 20%, whereas with ReIn, Pass@1 rises to 60–75% across inception modules [2602.17022].

| Setting | Pass@1 |
|---|---|
| No ReIn, Agent = Sonnet | ~20% |
| ReIn with Sonnet 3.7 inception | 68% |
| ReIn with Mistral Large inception | 70% |
| ReIn with Llama 3 70B inception | 66% |

The smaller Llama 3 3B inception module yields lower gains, which the paper attributes to only approximately 80–90% error-detection activation rate. On unseen but structurally similar errors, such as contradiction and unsupported domain, ReIn still recovers effectively, with Pass@1 approximately 55–65%, only slightly below seen-error performance [2602.17022].

The study also compares ReIn against two prompt-modification baselines in the Retail domain with a Claude 3.7 task agent. The first is Naïve Prompt Injection (NPI), which embeds error-detection and recovery instructions directly into the system prompt. The second is Self-Refine (SR), described as generating feedback on the first response and revising once. The reported Pass@1 values are 20% for No ReIn, 68% for ReIn, 50% for NPI, and 55% for SR, so ReIn outperforms both prompt-modification approaches by 10–18 points while preserving the original system prompt [2602.17022].

A further experiment allows ReIn to trigger at any turn rather than only at the primed turn. In the Airline domain, this dynamic application yields additional improvements of approximately 5–10 points because it can correct naturally emergent errors [2602.17022].

## 6. Instruction hierarchy, mechanism, and practical implications

The paper analyzes ReIn through the lens of instruction hierarchy. It cites Wallace et al. (2024) for the ordering

$$
\text{System Prompt} > \text{User Message} > \text{Model Outputs} > \text{Tool Outputs}.
$$

Because ReIn injects a reasoning block via a tool output, it occupies the lowest position in this hierarchy and might therefore be expected to be ignored. The reported experiments indicate otherwise: ReIn still exerts a substantial effect on agent behavior [2602.17022].

To probe this mechanism, the authors replace the proper recovery tool call `ambiguity_report(...)` with a plain apology sentence, “Sorry for the inconvenience…”, as the recovery plan. Under this condition, ReIn yields 0% Pass@1, and the agent simply ignores the intervention. The paper interprets this as evidence that ReIn’s success depends on jointly defining a recovery tool in $\mathcal{F}$, so that the injected reasoning is interpreted as a bona fide tool output rather than as an adversarial user instruction [2602.17022].

The practical consequence is a restricted but important claim about safety and controllability. Because only the service provider controls $\mathcal{F}$, the method is presented as a safe, sandboxed way to override the standard instruction ordering. The paper further argues that seeding a correct think block early primes the agent’s chain of thought toward the desired recovery strategy, and that because the block appears as a tool output, it becomes integrated into the internal decision loop and can shape subsequent $z_i^{(2)}$ samples without repeated prompting [2602.17022].

The deployment recommendations follow directly from this mechanism. The paper advises defining a small set of structured recovery tools, writing an inception prompt $S'$ that enumerates error definitions $\mathcal{E}$ and example mappings $Q(e) \rightarrow \text{plan}$, implementing the inception module $F$ as an LLM chain that inspects $C_t$ at each turn, injecting $r_t = \mathrm{think}[p_t]$ before the agent’s first tool-or-think step, and then allowing the agent to proceed with its normal policy $T_c(\cdot \mid \tilde C_t, \mathcal{F}, S)$ without altering parameters or the original system prompt [2602.17022].

Taken together, these results position ReIn as a method for on-the-fly behavioral intervention in fixed conversational agents. The paper’s strongest demonstrated setting is user-induced error recovery, but it concludes that the same reasoning-inception pattern may be applicable whenever supplementary logic must be added to a validated agent without model updates or system-prompt changes [2602.17022].

Source: https://www.emergentmind.com/topics/reasoning-inception-rein