1 Introduction↩︎

Large language models (LLMs) have shown strong ability to follow complex instructions when all requirements are specified in a single prompt [1]–[4]. In real assistant use, however, requirements are often accumulated, clarified, and revised across multiple turns. This conversational setting exposes the Lost-in-Conversation (LiC) gap: a model may solve a task in the FULL view, where all requirements are provided at once, but fail in the SHARDED view, where the same requirements are revealed progressively before the final answer [5]. Because the two views contain the same task requirements, this gap is not simply a failure of single-turn competence, but a failure to solve from a dialogue history shaped by both user turns and the model’s own earlier responses. This distinguishes LiC from ordinary long-context access failures, where relevant information may be present but used unevenly depending on where and how it appears [6], and aligns with evidence that extended reasoning depends on intermediate planning and optimization states rather than only on the final prompt [7].

Existing LiC-oriented methods improve multi-turn robustness, but they do not directly supervise the intermediate turns where a model can contaminate its own future context. RLSTA [8], for example, anchors optimization to the single-turn full-prompt view through scalar GRPO feedback and reports gains on contextual inertia. Other reward-based methods, including RLAAR [9] and ICPO [10], shape the policy with verifiable-accuracy or illocution-calibrated rewards, while inference-time methods such as Grounded Continuation [11] introduce a runtime verifier. These approaches provide answer-level rewards, full-view anchors, or runtime checks, but they do not provide dense supervision for middle-turn assistant replies. As a result, premature assumptions, overconfident partial solutions, or stale intermediate states can still be written into the dialogue history and later treated as context by the same model. This creates a compounding self-contamination effect, analogous to the distributional drift studied in sequential prediction and imitation learning [12], [13].

We introduce MAIGO, an on-policy self-distillation method designed to reduce this self-contamination. The key idea is to train the model on references that preserve the user-visible conversational prefix while removing the assistant outputs that could otherwise bias the reference distribution. For middle turns, MAIGO constructs history-cleaned references by deleting previous assistant replies but keeping the sharded user-side prefix intact. This teaches the model how to respond to the current conversational state without inheriting its own earlier mistakes. For answer turns, MAIGO distills from a paired full-view reference conditioned on the completed user-side dialogue, aligning the final answer with the fully specified task. A reliability weight further reduces the influence of middle-turn updates when the sampled response diverges from the clean reference. The method requires no verifier rewards, no additional state annotations, and no inference-time scaffolding.

We evaluate MAIGO on Math, Actions, Database, and Code under the LiC FULL-vs-SHARDED paired-view protocol with deterministic verifiers. On Qwen2.5-7B-Instruct, MAIGO improves average SHARDED accuracy from 52.8 to 66.1 and raises the SHARDED/FULL ratio from 66.5% to 84.1%, while no FULL task changes by more than 2.3 points relative to the base model. These results show that reducing self-contamination can substantially narrow the LiC gap without compromising performance on fully specified tasks.

Our contributions are threefold:

• We identify self-contamination from intermediate assistant replies as a trainable contributor to the LiC gap, connecting multi-turn degradation to the compounding effects of self-conditioned dialogue histories.

• We propose MAIGO, a turn-role-specific on-policy self-distillation method that uses history-cleaned middle-turn references, paired full-view answer references, and reliability-weighted supervision to reduce self-contamination without verifier rewards, state annotations, or inference-time scaffolding.

• We provide a controlled evaluation across math, tool-call generation, text-to-SQL, and Python code generation under the LiC paired-view protocol, showing substantial SHARDED gains while preserving FULL performance.

2 Related Work↩︎

2.0.0.1 Lost-in-Conversation and its mitigations.

LiC introduced a controlled FULL/SHARDED comparison: a task that is solvable from a complete single-turn instruction is split into user turns, and performance is measured after the same information has been revealed conversationally [5]. The key implication is that the multi-turn gap is not explained by lack of task competence alone. A model that solves the FULL version can still fail in SHARDED form because of early assumptions, premature answer attempts, over-reliance on previous attempts, and weak recovery once the missing information arrives. A growing line of subsequent studies characterizes this regime as a family of multi-turn state failures rather than a single error type, including attention drift over goal tokens, conversational inertia, and constraint or temporal-scope violations [14]–[20]. Existing mitigations mostly attack this regime through scalar rewards, anchoring, or runtime checks: verifiable-accuracy, abstention, or clarification rewards [9], [10], [21], single-turn-anchor GRPO [8], [22], and inference-time dependency verification [11]. MAIGO is complementary but adopts a different lens: it treats assistant-generated history itself as the trainable failure mode and supplies dense, history-cleaned reference distributions on the student’s own SHARDED rollout.

2.0.0.2 On-policy distillation and context-conditioned self-teaching.

On-policy distillation (OPD) trains on student-generated rollouts rather than fixed reference outputs, reducing the train–test mismatch that can undermine imitation in sequential decoding [23]. Its self-distilled variant (OPSD) uses the same model as student and teacher under different contexts, with dense token-level matching on sampled rollouts [24], and has been extended to context-conditioned self-distillation [25] and easier-context-to-harder-context transfer for long-context generation [26]. Recent studies further show that on-policy signals are not uniformly reliable: peer-rollout contexts, temporal curricula, scope-aware schedules, and teacher-choice analyses all suggest that not every on-policy update should be weighted equally [27]–[30]. MAIGO follows this methodological line but adapts it to sharded conversations, where the main failure mode is self-contamination from earlier assistant replies. Rather than using a uniform reference context, it constructs turn-role-specific references: history-cleaned supervision for middle turns and paired-view recovery supervision for answer turns. A divergence-adaptive weight further modulates middle-turn updates, connecting the method to reliability-aware OPD while targeting the distinctive structure of multi-turn LiC failures.

3 Method↩︎

MAIGO is an on-policy self-distillation method for sharded multi-turn tasks. The method trains on the student’s own sharded rollouts, but computes reference distributions under cleaner training-time contexts. This allows the student to learn from the histories it actually induces, while preventing its own earlier replies from contaminating the reference signal.

The training signal has three components. First, middle turns are supervised with history-cleaned sharded references that preserve the user-visible prefix but remove previous assistant replies. Second, the final answer turn is supervised with a completed-task reference that preserves the full user-side sharded dialogue and appends a canonical reserialization of the paired FULL specification. Third, a separate FULL-view branch regularizes the model toward its original full-prompt behavior. MAIGO requires no verifier rewards, no extra state labels, and no inference-time scaffolding.

3.1 Sharded On-Policy Setup↩︎

Each training instance contains two paired views of the same task: a FULL specification \(x\), and a sequence of user turns \(u_{1:T}\) that reveal the same requirements incrementally, following the FULL/SHARDED setting of Lost-in-Conversation [5]. The final user turn \(u_T\) is the answer turn. Assistant replies before \(T\) are not final outputs, but they remain in the dialogue history and therefore shape the context for later turns.

The student policy \(\pi_\theta\) is rolled out on the sharded dialogue on-policy. At turn \(t\), the student context is \[C_t^S = (u_1,\hat{a}_1,\ldots,u_{t-1},\hat{a}_{t-1},u_t),\] and the student samples \[\hat{a}_t \sim \pi_\theta(\cdot \mid C_t^S), \qquad t=1,\ldots,T .\] Thus training is performed on the same self-conditioned history distribution that can produce SHARDED failures, rather than on a clean offline transcript.

For a sampled assistant response \(\hat{a}=(\hat{y}_1,\ldots,\hat{y}_n)\) generated under student context \(C^S\), all distillation losses use the same token-level form: \[\mathcal{D}_{\beta}(C^S,C^{\mathrm{ref}};\hat{a}) = \frac{1}{n}\sum_{i=1}^{n} d_{\beta}\!\left(P_i^{\mathrm{ref}}, P_i^S\right), \label{eq:turn-distill}\tag{1}\] where \[P_i^S = \pi_\theta(\cdot \mid C^S,\hat{y}_{<i})\] is the student next-token distribution, and \[P_i^{\mathrm{ref}} = \operatorname{sg}\!\left[ \pi_{\theta^-}(\cdot \mid C^{\mathrm{ref}},\hat{y}_{<i}) \right]\] is the stop-gradient reference distribution evaluated under a role-specific reference context \(C^{\mathrm{ref}}\). Here \(\pi_{\theta^-}\) is an exponential-moving-average (EMA) reference policy [23], [24].

The divergence \(d_\beta\) follows the generalized Jensen–Shannon divergence used in OPSD. For \(0<\beta<1\), let \[m_\beta = \beta p + (1-\beta)q ,\] and define \[\begin{align} d_\beta(p,q) &= \beta\,\mathrm{KL}(p\,\|\,m_\beta) +(1-\beta)\,\mathrm{KL}(q\,\|\,m_\beta). \end{align} \label{eq:dbeta}\tag{2}\] For the endpoints, we follow the OPSD convention and set \(d_0(p,q)=\mathrm{KL}(p\|q)\) and \(d_1(p,q)=\mathrm{KL}(q\|p)\). In Eq. 1 , \(p=P_i^{\mathrm{ref}}\) and \(q=P_i^S\). In our reported configuration, \(\beta_{\mathrm{mid}}=0.5\) and \(\beta_{\mathrm{final}}=\beta_{\mathrm{full}}=1.0\), so the middle branch uses the symmetric Jensen–Shannon loss, while the answer and FULL branches use reverse KL. Gradients pass only through the student distribution \(P_i^S\).

The remainder of this section specifies the reference context \(C^{\mathrm{ref}}\) for each turn role.

3.2 History-Cleaned Middle-Turn Supervision↩︎

Middle turns are partial-information states. Supervising them with a full-task reference can encourage premature solution tokens, while supervising them with a reference that conditions on the same assistant-generated history can inherit the student’s earlier mistakes. MAIGO therefore uses a history-cleaned reference for every eligible middle turn: \[C_{t,\mathrm{mid}}^{\mathrm{ref}} = (\sigma_{\mathrm{sys}}, u_1, u_2, \ldots, u_t), \qquad t<T,\] where \(\sigma_{\mathrm{sys}}\) denotes the task-specific system block shared by the FULL and SHARDED views; no previous assistant replies, unrevealed user turns, or full-task content appear in the reference. Intuitively, the reference asks what the EMA reference policy assigns to the student’s sampled middle response when the model’s own earlier outputs are not part of the conditioning context.

The local middle-turn loss is \[\ell_t^{\mathrm{mid}} = \mathcal{D}_{\beta_{\mathrm{mid}}} (C_t^S,C_{t,\mathrm{mid}}^{\mathrm{ref}};\hat{a}_t). \label{eq:middle-local-loss}\tag{3}\] The sampled tokens are generated from the student’s actual sharded context \(C_t^S\), keeping the update on-policy. In contrast, the reference distribution is evaluated under the history-cleaned context \(C_{t,\mathrm{mid}}^{\mathrm{ref}}\), where previous assistant replies have been removed. Thus, the loss aligns the student’s middle-turn behavior with what the EMA reference policy would assign under a clean user-side prefix, rather than under a context already shaped by the student’s earlier outputs. This encourages middle-turn replies that are less likely to introduce self-generated errors into later dialogue context.

3.2.0.1 Reliability weighting.

Not every sampled middle turn provides an equally reliable reference signal: on-policy rollouts can contain low-quality questions, verbose partial answers, or histories that the clean sharded prefix would not support. We therefore weight each middle turn by the realized student–reference log-probability discrepancy on the sampled tokens. Let \(\mathcal{I}\) collect the pre-answer turns whose sampled replies are non-empty and retained for token-level loss. If \(\mathcal{I}\) is empty, the sharded branch skips the middle loss for that example. For each \(t\in\mathcal{I}\), define a detached scalar \[\delta_t = \operatorname{sg}\!\left[ \tfrac{1}{m_t}\!\sum_{i=1}^{m_t}\! \big| \log P_{t,i}^{S}(\hat{y}_{t,i}) -\log P_{t,i}^{\mathrm{ref}}(\hat{y}_{t,i}) \big| \right], \label{eq:middle-divergence}\tag{4}\] where \(P_{t,i}^{S}\) and \(P_{t,i}^{\mathrm{ref}}\) are the student and reference next-token distributions at position \(i\) of middle turn \(t\), and \(m_t\) is the number of supervised tokens in the sampled middle reply. Intuitively, \(\delta_t\) tracks how far the realized middle response has drifted from a clean-history view of the same on-policy state. Let \(\mathcal{I}_{\le t}=\{j\in\mathcal{I}:j\le t\}\) and \(\delta_j^+=\max(\delta_j,\epsilon)\) for a small \(\epsilon>0\). We turn \(\delta_t\) into a bounded weight using the median discrepancy over eligible turns up to \(t\), \[\begin{align} \tilde{\delta}_t &= \operatorname{median}_{j\in\mathcal{I}_{\le t}}(\delta_j^+), \\ w_t &= \operatorname{sg}\!\left[ \frac{\tilde{\delta}_t}{\tilde{\delta}_t+\delta_t^+} \right] \in (0,1] , \end{align} \label{eq:middle-weight}\tag{5}\] The form gives \(w_t = 1/2\) at the median and decays approximately as \(1/\delta_t\) for outliers, so middle supervision is strongest when the sampled response stays close to the history-cleaned view and more conservative when the trajectory has drifted far from it. This follows the broader OPSD observation that on-policy reference signals vary in quality across samples [28]–[30].

The middle-turn objective for a realized trajectory is the mean over eligible turns, \[\bar{\mathcal{L}}_{\mathrm{mid}} = \frac{1}{|\mathcal{I}|} \sum_{t\in\mathcal{I}} \alpha_t w_t\ell_t^{\mathrm{mid}} , \label{eq:middle-mean-loss}\tag{6}\] where \(\alpha_t\) is a middle-turn scale, set to \(1.0\) for all eligible turns in our experiments. For efficiency, each trajectory samples one eligible middle turn, \(\tau \sim \operatorname{Unif}(\mathcal{I})\), and uses \[\mathcal{L}_{\mathrm{mid}} = \alpha_{\tau} w_{\tau}\ell_{\tau}^{\mathrm{mid}} , \label{eq:middle-sampled-loss}\tag{7}\] which is an unbiased single-turn estimator of Eq. 6 under uniform \(\tau\) when the per-turn weights are treated as detached scalars.

3.3 Answer-Turn Recovery and Full-Prompt Preservation↩︎

Middle supervision alone is not enough: the target is task completion after the required information arrives. At turn \(T\), the student’s context \(C_T^S\) may still contain earlier replies that are incomplete, speculative, or inconsistent with later user information. A reference that conditions on the same assistant-generated history would inherit those errors, while a reference that conditions only on the full task view would ignore the sharded delivery the student must handle. MAIGO therefore builds a training-only answer-turn reference context \[C_{T,\mathrm{ans}}^{\mathrm{ref}} = (\sigma_{\mathrm{sys}}, u_1, \ldots, u_T, \sigma_{\mathrm{canon}}(x)),\] which keeps the completed user-side sharded dialogue and appends a deterministic canonical reserialization \(\sigma_{\mathrm{canon}}(x)\) of the paired FULL specification \(x\) as an additional message, with previous student replies removed before serialization (full role-assignment details in App. 6.3). The canonical block is a reserialization of requirements already present in the paired task; it does not add a gold answer or verifier signal. The answer-turn loss is \[\mathcal{L}_{\mathrm{final}} = \mathcal{D}_{\beta_{\mathrm{final}}} (C_T^S,C_{T,\mathrm{ans}}^{\mathrm{ref}};\hat{a}_T) , \label{eq:final-loss}\tag{8}\] and teaches solution recovery at the natural answer turn: the reference gives the EMA reference policy a cleaner organization of the same completed task, while the student loss is still applied to tokens sampled from the ordinary sharded dialogue.

3.3.0.1 FULL-view preservation.

Because the sharded branch reshapes behavior under sharded delivery, we preserve FULL-view capability with an EMA anchor on the FULL view. Let \(C^F\) be the full task context built from \(x\) and sample \(\hat{a}^F\sim\pi_\theta(\cdot\mid C^F)\). The student and reference share the same FULL context here, so \[\mathcal{L}_{\mathrm{full}} = \mathcal{D}_{\beta_{\mathrm{full}}}(C^F,C^F;\hat{a}^F) \label{eq:full-loss}\tag{9}\] is an EMA self-anchor rather than a source of new task information; it discourages the model from trading away competence it already exhibits when all requirements are provided at once.

3.4 Training Objective↩︎

The training objective has two branches. The sharded trajectory branch combines answer-turn recovery with weighted history-cleaned middle-turn distillation, and the FULL-view branch acts as a preservation regularizer: \[\begin{align} \mathcal{L}_{\mathrm{train}} &= (1\!-\!z)(\mathcal{L}_{\mathrm{final}}+\mathcal{L}_{\mathrm{mid}}) + z\,\mathcal{L}_{\mathrm{full}}, \\ z &\sim \operatorname{Bernoulli}(\rho), \end{align} \label{eq:maigo-objective}\tag{10}\] where \(\rho\) controls how often the preservation branch is sampled; with probability \(1-\rho\), the update uses the sharded trajectory branch. Taking the expectation over \(z\) recovers the mixture of the two branches. After each optimizer step, the EMA reference is updated as \(\theta^- \leftarrow \lambda\theta^- + (1-\lambda)\theta\) with decay \(\lambda\). Algorithm 3 summarizes a training step.

4 Experiments↩︎

3pt

We report SHARDED accuracy as the primary metric and FULL accuracy as a complete-prompt preservation check.

4.1 Evaluation Setup↩︎

We follow the Lost-in-Conversation FULL-vs-SHARDED paired-view protocol: each item has a complete-prompt view and a sharded conversational view with the same requirements revealed across user turns [5]. Following LiC and subsequent LiC-based training studies, SHARDED evaluation uses a model-assisted user simulator that reveals at most one unrevealed shard per turn, lets the evaluated assistant respond, and then decides whether an answer attempt should be scored [5], [9]. All methods use the same fixed DeepSeek-V3.1-Terminus simulator for user turns and answer-attempt classification [2], along with the same shard files, prompts, seeds, and deterministic scorers. Fine-tuning uses disjoint sharded training sets of 6,400 examples for Math, Actions, and Code, and 6,397 examples for Database; Appendix 6 gives construction details. Outputs that fail to parse, are empty, violate the response protocol, or are truncated by the generation budget count as incorrect. For MAIGO, these scorers are evaluation-only, not training rewards.

4.1.0.1 Tasks and metrics.

We use the four objectively scored task families from LiC—the same subset adopted by recent LiC-based training studies [8], [9], [21]—and exclude the two judge-scored ones (summary, captioning) so that every cell is auditable by a deterministic verifier. Math is instantiated by LiC-style GSM8K with numeric matching [31]; Actions by BFCL parallel/parallel-multiple tool calls with deterministic AST matching [32]; Database by fixed-schema sharded text-to-SQL on Spider no-easy with execution matching [33]; and Code by HumanEval Python function generation scored by unit tests [34]. Together, they cover numeric, tool-call, SQL, and program outputs, giving deterministic probes of different contamination channels.

4.1.0.2 Models and baselines.

The primary comparison uses Qwen2.5-7B-Instruct, with 3B rows as a smaller-backbone validation [3]. Baselines are per-task SFT, GRPO with sparse verifiable rewards [22], and RLSTA, which uses the stronger single-turn view as a GRPO anchor [8]. All trained methods use Low-Rank Adaptation (LoRA) adapters [35]; adapter weights are merged into the base model before evaluation. All methods use the same paired FULL/SHARDED prompts under a matched 100-step fine-tuning budget. We report the mean of four training seeds for each fine-tuned method. Appendix 6.2 reports optimizer, context, and generation settings.

4.2 Main Results↩︎

Table 1 reports per-task FULL and SHARDED accuracy, their averages, and the SHARDED-to-FULL ratio. The base model is strong on FULL but much weaker once the same requirements arrive through turns; on Qwen2.5-7B-Instruct Actions, accuracy drops from 82.2 FULL to 17.8 SHARDED, and the base S/F ratio is 66.5%, close to the roughly 60% ratio reported by LiC for closed-source models [5]. MAIGO improves every 7B SHARDED task, with the largest gain on Actions (+29.0). Averaged over the four 7B task families, SHARDED accuracy rises from 52.8 to 66.1 and the S/F ratio rises from 66.5% to 84.1%, while average FULL changes only from 79.3 to 78.6, with no individual task FULL changing by more than 2.3 points.

4.2.0.1 Comparison to supervised and RL baselines.

The baseline rows show limits of standard fine-tuning signals in this setting. On Qwen2.5-7B-Instruct, SFT changes average SHARDED accuracy marginally. GRPO and RLSTA raise the 7B SHARDED average to 55.2 and 57.6, but they leave a large residual gap on Actions, where early tool arguments and partial calls remain in later context. MAIGO instead supplies dense token-level supervision on sampled sharded rollouts under cleaned reference histories, which better targets assistant replies that will become part of the future state.

4.2.0.2 Task-level behavior.

Actions benefits most because tool calls and shared arguments accumulate across turns. Math and Database show smaller but clear improvements when facts or SQL constraints arrive conversationally. Code is the one family where SHARDED can exceed FULL for some rows. This is possible because FULL is not an absolute upper bound: the HumanEval SHARDED view reveals the same function requirements as short conversational constraints, which can make the required signature and late conditions explicit near generation time before the same unit-test scorer is applied. The relevant pattern is therefore SHARDED improvement together with FULL preservation; by that measure, MAIGO gives stable Code gains (+4.6 on 7B and +6.7 on 3B) without degrading average FULL behavior.

3pt

4.2.0.3 Trajectory diagnostic.

Figure 4 asks when each SHARDED example first becomes correct during the rollout. On Actions, the full-reveal gain is much larger than the gain at 80% reveal (\(+30.4\) vs. \(+7.1\) points); Math shows a smaller but consistent shift. This indicates that much of the improvement appears after all requirements have arrived, when the student must answer from its accumulated history. The main FULL results also rule out a simple tradeoff against single-turn performance.

4.2.0.4 Smaller model check.

The Qwen2.5-3B-Instruct rows replicate the pattern: average SHARDED accuracy rises from 43.5 to 58.2 and S/F from 66.0% to 86.3%, while average FULL stays close to the base model; ablations remain on the 7B suite.

5pt

4.2.0.5 Cross-backbone generality.

Table 3 gives a Base-vs-MAIGO comparison on Llama-3.1-8B-Instruct [36]. SHARDED accuracy improves on four task families, raising the average from 50.7 to 66.1 and S/F from 71.2% to 89.8%, while average FULL accuracy also increases. This supports a history-cleaned self-distillation effect beyond the Qwen backbones used for the matched-baseline study.

4.3 Component Ablations↩︎

Table 2 isolates the main components. Removing the middle-turn loss causes the largest degradation: average SHARDED accuracy falls by 4.5 points and the S/F ratio drops from 84.1% to 77.7%, showing that final-answer supervision alone misses useful signal from history-cleaned intermediate replies. Flattening the adaptive weight to a uniform value gives a similar 3.4-point SHARDED drop; although this variant has a slightly higher FULL average, it does not recover the same sharded behavior. Thus the trajectory-local weight has an effect beyond simply scaling the middle loss. A FULL-only answer reference is the strongest ablation in average SHARDED accuracy (65.9 vs.), slightly exceeding MAIGO on Actions but lowering mean FULL (77.6 vs.). The preservation branch acts as a regularizer: removing it lowers both averages, with Actions the only task where removal improves SHARDED accuracy.

4.4 Hyperparameter Sensitivity↩︎

The preservation branch is controlled by the probability \(\rho\) of sampling a FULL-view training step. Figure 5 sweeps \(\rho\in\{0,0.2,0.4,0.6,0.8\}\) on Actions and Math. The default \(\rho=0.2\) is already near the best SHARDED result; larger values do not improve the conversational setting and can reduce SHARDED accuracy, especially on Actions. FULL accuracy is comparatively stable, so the main effect of large \(\rho\) is weaker SHARDED adaptation.

5 Conclusion↩︎

We studied sharded multi-turn task solving as a self-generated-history problem: when requirements arrive across turns, intermediate assistant replies enter later context and can hinder final completion. MAIGO addresses this with adaptive on-policy self-distillation on the student’s own sharded rollouts, combining history-cleaned middle-turn supervision, answer-turn recovery, and full-prompt preservation. Across math, tool/action generation, SQL, and Python code generation, MAIGO improves SHARDED completion over SFT, sparse-reward RL, and single-turn-anchor RL while keeping FULL performance comparable. These results suggest that robust multi-turn solving benefits from supervising student-generated histories under reference contexts that preserve user-provided requirements while removing earlier assistant replies.

Limitations↩︎

MAIGO may improve a language model’s ability to preserve and recover task requirements over longer conversations, but the same capability could also make harmful or inappropriate objectives more persistent. The reference views used during training can also encode biased, incorrect, or unsafe requirements, and those errors may be distilled into the student model. Our evaluation focuses on objectively scored tasks, so it does not establish safety, privacy protection, or refusal behavior in open-domain dialogue. Deployment should therefore pair the method with safety filtering, permission controls, and careful handling of sensitive information.

6 Experimental Protocol and Reproducibility↩︎

This appendix is organized around the information needed to audit and reproduce the experiments. Appendix 6.1 describes the paired task construction, Appendix 6.2 gives the training settings, Appendix 6.3 specifies the training-only reference contexts, Appendix 7 records the prompt templates, and Appendix 8 provides qualitative multi-turn cases.

6.1 Tasks and Metrics↩︎

Each task is evaluated in paired FULL and SHARDED views: FULL presents the complete task in one prompt, while SHARDED reveals the same requirements across user turns and scores the final answer. The evaluation uses GSM8K (\(N{=}1319\), numeric answer match), Actions (\(N{=}382\), tool-call AST match), Database (\(N{=}715\), SQL execution match), and HumanEval (\(N{=}164\), unit tests).

Table 4 summarizes how the paired views are constructed. We follow the LiC principle that FULL and SHARDED expose the same task requirements, with SHARDED delaying their presentation across user turns. The conversion follows the fixed task-family protocols used for our LiC-style evaluation and is shared by all methods; the table reports the information needed to interpret the comparison at a protocol level.

3pt

For SHARDED interaction, we retain the simulator roles from the LiC protocol: an evaluated assistant, a model-assisted user model that decides which unrevealed shard to reveal next, and a system component that classifies answer attempts and extracts the candidate answer for the task verifier. Our experiments use a fixed DeepSeek-V3.1-Terminus model for the user model and answer-attempt classifier. This model controls only the interaction environment around the evaluated assistant; the sharding protocol, turn budget, answer extraction interface, and deterministic task verifiers remain aligned with the LiC evaluation protocol. Every model and training method is evaluated with the same simulator model, same shard files, same prompt templates, same turn budget, and same task verifier.

Outputs that fail to parse, are empty, violate the response protocol, exceed the context limit, or reach the interaction limit are counted as incorrect. This convention keeps FULL and SHARDED comparable: a model must both produce an answer in the expected format and solve the underlying task.

6.2 Optimization and Baselines↩︎

All trained methods are optimized as LoRA adapters [35] and evaluated after merging the adapter weights into the base model. Tables 5 and 6 summarize the optimization budget and MAIGO-specific settings used in the main experiments.

4pt

4pt

4pt

Table 7 reports a descriptive training diagnostic rather than an additional multi-seed comparison. The values are the actual sampled middle-turn weights used by the optimizer. Across tasks, the mean weight stays well below a uniform weight of one while remaining far from zero, indicating that the adaptive rule changes the middle-turn signal without collapsing supervision. The causal comparison for this component is the corresponding uniform-weight ablation in the main ablation table.

The main comparison rows are matched fine-tuning comparisons under a common adapter, training set construction, optimization budget, and evaluation setup. The RL baselines use their own sparse task rewards; RLSTA additionally uses the paired FULL view as its single-turn anchor reward. No method receives extra evaluation-time state or a different SHARDED prompt.

6.3 Training-Only Reference Views↩︎

The reference contexts are used only for computing distillation losses during training. They do not change the information available to the deployed student, and they are built from the same paired task views used by the LiC-style FULL/SHARDED protocol. The following rules define the three reference views used by MAIGO.

6.3.0.1 Middle turns.

The middle-turn reference keeps the user turns through the current shard and task-specific system information that is shared by the paired views. It removes earlier assistant replies and withholds both unrevealed user turns and the full task view.

6.3.0.2 Answer turn.

The answer-turn reference keeps all user turns in order and preserves the same task-specific system information as the evaluation prompt. It adds a canonical serialization built from the completed dialogue and its paired FULL view, then removes earlier assistant replies such as premature calls, draft SQL, or partial code attempts. The paired FULL view is used only to render the completed requirements in the fixed task format, not to add a gold answer or a verifier signal.

6.3.0.3 Full branch.

The full branch uses the complete single-turn task prompt and no sharded history. It is an EMA anchor for FULL preservation rather than a source of new sharded supervision.

The task-specific keep/remove rules are:

GSM8K.

Middle references keep the math system instruction and user shards through turn \(t\), while removing earlier assistant replies, later facts, and the full problem text. Answer references keep all user shards and append a canonical serialization of the completed problem requirements.

Actions.

Middle references keep the tool-use instruction and the user-visible tool requirements revealed so far. Answer references keep all user turns and append the completed tool-use request in canonical form, while removing earlier assistant calls.

Database.

The schema remains in the system context for both student and reference. Middle references keep query shards through turn \(t\); answer references keep all query shards and append the completed natural-language query in canonical form, while removing earlier draft SQL.

HumanEval.

Middle references keep the coding instruction and function-specification shards through turn \(t\). Answer references keep all specification shards and append the completed programming task requirements in canonical form, while removing earlier partial code.

Thus the reference view changes the serialization of completed user-provided requirements for training; it does not add a gold-answer label and does not change what the student receives at inference time.

7 Prompt and Template Cards↩︎

This section records the prompt surfaces used by the experiments. Dynamic fields are written as [[FIELD]]. Per-item fields such as tool schemas, database schemas, user shards, and function headers are filled from the fixed train/evaluation files. We separate assistant-visible task prompts from the prompts used by the interaction environment. The environment prompts are sent as user-role requests to the fixed simulator/classifier model and are not visible to the evaluated assistant.

7.1 Interaction Environment Prompts↩︎

The SHARDED environment follows the LiC interaction structure. The first user turn is the first stored shard and does not call the user-simulator model. From the second user turn onward, the simulator receives the current conversation, the revealed shard list, and the unrevealed shard list.

You are simulating a user of an interactive LLM system (like ChatGPT).
The user is inherently lazy, and answers in short form, providing only minimal information to the system. You should not be proactive.

Here's the conversation so far:
[[CONVERSATION_SO_FAR]]

Here are the shards that have already been revealed:
[[SHARDS_REVEALED]]

Here are all the shards that have not been revealed yet:
[[SHARDS_NOT_REVEALED]]

You must generate a response to the conversation so far. Here are the rules:
- [Providing a Shard] You can reveal the content of a shard to the system in your response if it will help the system move closer to answering the problem. You should select the shard to reveal that is most "basic" and is the current most relevant shard.
- [One Shard at a Time] You should only reveal at most one shard at a time.
- [Reveal Entire Shard] If you reveal a shard, you must make sure to include *all the information in the shard*. For example, if the shard is "your symptoms are that you have a headache in the mornings", your response can't just be ``yeah I have headaches'', you must say ``yup mostly headaches in the mornings``.
- [Irrelevant Clarifications] If the system asks you a question irrelevant to the shards, asks you a generic question (``Can you give me a hint?``), you should respond with an answer that does not provide a shard. (``I don't know``, ``Is that really important?``, etc.) You should not reveal any information beyond what is available in the shards.
- [No Repeated Shards] You should not reveal the same shard more than once. Carefully review the shards revealed already, and only reveal a shard if its `shard_id` is not on the list.
- [Rephrase Shards] If you reveal a shard, you should rephrase it in a conversational way. Do not copy the shard verbatim.
- [Do Not Ask Questions] Your response should always be declarative sentences, and not questions.
- [Brevity of Response] You should favor being succint. Your answer can also have typos, improper grammar, capitalization, etc. You are simulating a real person talking to an AI, who is in a hurry.
- [Format] Your response should be formatted as a JSON object with the following keys:
    - `response`: The response to the conversation so far.
    - `shard_id`: The shard you are revealing to the system. The shard_id can be an integer, or -1 if you did not reveal any shards.
For example:
{"response": "I don't know", "shard_id": -1}
or:
{"response": "yeah I want it to [...]", "shard_id": 1}

After each assistant response, a fixed classifier decides whether the turn is a scorable answer attempt. Prompt Card B3 lists the task-specific answer surface used by the classifier and extractor.

You are reviewing a multi-turn conversation between a user and an assistant, and are given the last turn of the conversation.

Here is the full specification of the problem the system is attempting to solve:
[[INITIAL_SHARD]]

Specification:
[[SHARDS]]

You must classify the response of the assistant according to the response type:
- `answer_attempt`: The response contains a complete answer attempt to the user's question (not templated or hypothetical), that can be extracted verbatim. See the task-specific answer description for more details.
- `clarification`: The response  is short (less than 100 words) and contains a single question addressed to the user that directly inquires about an aspect of the user's query. A clarification turn cannot be long (see `discussion`), cannot contain a vague question (see `discussion`) and cannot contain multiple questions (see `interrogation`).
- `interrogation`: The response contains multiple questions addressed to the user, sometimes organized in a list or bullet-points.
- `discussion`: The response discusses the question in detail, without providing a final answer, asking a specific clarification question, or a refusal to answer. The response may or may not contain a vague question (e.g., "What else can I help you with?").
- `hedge`: The response contains multiple answer candidates based on hypotheticals (ifs) or branching (case 1, case 2) with corresponding descriptions.
- `refuse`: The response contains an explicit or implicit refusal to answer the user's question without a follow-up question or a request.
- `missing`: The response is empty/blank.

You must output your answer in the following JSON format:
{"response_type": "refuse|missing|answer_attempt|hedge|clarification|interrogation|discussion"}

Rules:
- The assistant giving a hint at how an answer could look like is not a final answer.
- [Task Specific Answer] [[ANSWER_DESCRIPTION]]

Conversation's last turn:
[[CONVERSATION_SO_FAR]]

Math

The classifier looks for a single numeric answer; an LLM extractor returns the exact numeric span for verifier matching.

Actions

The full assistant response is scored as a BFCL-format function-call list.

Database

The classifier looks for one complete executable SQL query; an LLM extractor normalizes the submitted SQL span before execution scoring.

Code

The task-specific Python extractor expects one valid submitted Python function.

---

For Math and Database, a fixed extraction prompt is used only to locate the answer span before deterministic scoring. It does not judge correctness.

Math

The extractor returns the exact numeric answer substring, which is then scored by numeric matching.

Database

The extractor returns a single SQL span without prose or code fences, which is then scored by execution.

---

7.2 Task System and FULL Prompt Templates↩︎

The evaluated assistant sees the following task system prompts. Actions fills [[FUNCTIONS]] with the per-item BFCL function schema, and Database fills [[SCHEMA]] with the Spider schema. For the main Code row, HumanEval examples use the function-generation harness with the Python-programmer system prompt and the HumanEval FULL user template shown below.

System:
As an expert problem solver solve step by step the following mathematical questions.

FULL user:
Q: [[QUESTION]]
A:

System:
You are an expert in composing functions. You are given a question and a set of possible functions. Based on the question, you will need to make one or more function/tool calls to achieve the purpose.
If none of the functions can be used, point it out. If the given question lacks the parameters required by the function, also point it out.
You should only return the function calls in your response.

If you decide to invoke any of the function(s), you MUST put it in the format of [func_name1(params_name1=params_value1, params_name2=params_value2...), func_name2(params)]
You SHOULD NOT include any other text in the response.

Here is a list of functions in JSON format that you can invoke.

[[FUNCTIONS]]

FULL user:
[[QUESTION]]

System:
You are helping a user write SQL queries to a database. If something is not clear, you can ask the user to clarify what they need. The schema for the database being accessed is the following:
        
[[SCHEMA]]

FULL user:
You must generate the valid SQL query that answers the given user query in natural language.

The schema of the database you are responding to is as follows:
[[DATABASE_SCHEMA]]

The user query is:
[[USER_QUERY]]

Rules:
- [Single Answer] Produce a single valid SQL query based on the database schema and the user query.
- [Only SQL] Do not include any other text or comments.
- [Validity] The SQL query must be valid and executable.
- [Single Line] Produce your entire response in a single line.

System:
You are an expert Python programmer. You will be given a question (problem specification) and will generate a correct Python program that matches the specification and passes all tests.

Format:
- [Standalone] Make sure that your answer consists of only one Python function at the top level. Do not wrap with a class or split into multiple functions.

FULL user:
You must generate a valid Python function that satisfies the following instruction:

Instruction:

Complete the following incomplete function signature:
```python
[[HUMANEVAL_PROMPT]]
```

Rules:
- [Format] You must only return the Python function, matching the signature exactly.
- [Validity] The Python function must be valid and executable. Do not include any other text or comments. (```python```)

7.3 Evaluation and Training Message Forms↩︎

We write \(\langle x\rangle\) for the complete task view, \(\langle u_t\rangle\) for the \(t\)-th user shard, \(\langle \hat{a}_t\rangle\) for a student-sampled assistant reply, and \(\langle y^\star\rangle\) for the reference final answer used by supervised baselines.

System: <task-specific system message from Appendix B.2>
User:   <complete task view x rendered with the task FULL template>
Assistant: <decoded answer, or sampled answer during FULL preservation>

System: <task-specific system message from Appendix B.2>
User:   <u_1>
Assistant: <model reply a_1>
...
User:   <u_T>
Assistant: <final decoded answer>

Student context:
  System: <task-specific system message>
  User/Assistant history: <u_1, a_1, ..., u_{t-1}, a_{t-1}>
  User: <u_t>
  Assistant tokens used for loss: <sampled middle reply a_t>

Reference context:
  System: <same task-specific system message>
  User-only prefix: <u_1, ..., u_t>
  Assistant tokens used for loss: <the same sampled middle reply a_t>

Removed from the reference:
  previous assistant replies, unrevealed user turns, full task view.

Student context:
  System: <task-specific system message>
  Full SHARDED history: <u_1, a_1, ..., u_{T-1}, a_{T-1}, u_T>
  Assistant tokens used for loss: <sampled final reply a_T>

Reference context:
  System: <same task-specific system message>
  User-only completed dialogue: <u_1, ..., u_T>
  Canonical task block: <completed requirements rendered from u_1, ..., u_T and x>
  Assistant tokens used for loss: <the same sampled final reply a_T>

Removed from the reference:
  previous assistant replies such as partial SQL, premature calls, or draft code.

SFT:
  System: <task-specific system message>
  User: <u_1>
  ...
  User: <u_T>
  User: "Now answer the task using all information revealed so far.
         Return the final answer only in the task's expected format."
  Assistant target: <reference final answer y*>

GRPO / RLSTA:
  The policy uses the same SHARDED prompt as evaluation. Rewards score
  the decoded final answer; RLSTA additionally uses the paired FULL view
  as its single-turn anchor. Evaluation prompts are unchanged.

7.4 Offline Shard Construction↩︎

Shard construction is an offline preprocessing step. Runtime evaluation and fine-tuning consume the resulting shard lists and do not call the shard constructor. We use fixed task-family prompt programs following the LiC paired-view protocol: GSM8K uses arithmetic segmentation followed by conversational rewriting; Actions uses BFCL request segmentation and conversational rewriting while keeping function schemas in the task system prompt; Database uses a fixed-schema delayed-query construction; and Code uses HumanEval-style function-specification segmentation, conversational rewriting, and validation. All compared methods use the same generated shard files.

8 Qualitative Case Studies↩︎

The cases below are real SHARDED traces. Each card shows the base rollout followed by the MAIGO rollout; user and assistant turns remain in their original order. System prompts, verifier logs, timestamps, and cost metadata are omitted. For prose-heavy responses, the cards report the verifier-observed response type for non-final turns and the exact submitted answer, tool call, or SQL artifact for turns scored as answer attempts. Markdown code fences are removed only as typesetting wrappers.

8.1 Successful Recoveries↩︎

Evaluation item

bfcl_v3_parallel_multiple_23; strict tool-call AST match. The available functions are financial_ratio.net_profit_margin and financial_ratio.debt_ratio.

Base rollout (FAIL): later numeric shards are not absorbed into the tool state

User 1: net profit margin Company XYZ

Assistant 1:

[financial_ratio.net_profit_margin(net_income=100000, total_revenue=500000)]

User 2: The net income is $20,000.

Assistant 2:

None of the provided functions match the given input format.

User 3: The total revenue is $100,000.

Assistant 3:

None of the provided functions match the given input format.

User 4: Now calculate the debt ratio.

Assistant 4:

[financial_ratio.debt_ratio(total_liabilities=60000, total_assets=150000)]

User 5: The total liabilities are $10,000.

Assistant 5:

None of the provided functions match the given input format.

User 6: The total assets are $30,000.

Assistant 6:

None of the provided functions match the given input format.

Result: FAIL

MAIGO rollout (PASS): the final call list keeps both updated computations

User 1: net profit margin Company XYZ

Assistant 1:

[financial_ratio.net_profit_margin(net_income=100000, total_revenue=500000)]

User 2: The net income is $20,000

Assistant 2:

[financial_ratio.net_profit_margin(net_income=20000, total_revenue=500000)]

User 3: The total revenue is $100,000.

Assistant 3:

[financial_ratio.net_profit_margin(net_income=20000, total_revenue=100000)]

User 4: Now calculate the debt ratio.

Assistant 4:

[financial_ratio.net_profit_margin(net_income=20000, total_revenue=100000),
 financial_ratio.debt_ratio(total_liabilities=50000, total_assets=150000)]

User 5: The total liabilities are $10,000.

Assistant 5:

[financial_ratio.net_profit_margin(net_income=20000, total_revenue=100000),
 financial_ratio.debt_ratio(total_liabilities=10000, total_assets=150000)]

User 6: The total assets are $30,000.

Assistant 6:

[financial_ratio.net_profit_margin(net_income=20000, total_revenue=100000),
 financial_ratio.debt_ratio(total_liabilities=10000, total_assets=30000)]

Result: PASS

Takeaway

MAIGO still makes tentative intermediate calls, but unlike the base model it continues revising the tool state as later numeric shards arrive and submits the completed pair of computations at the final turn.

---

Evaluation item

gsm8k_test/399; exact numeric answer match.

Base rollout (FAIL): the final answer switches to the most recent relation

User 1: What is the difference between Alice’s age and Erica’s age?

Assistant 1 (non-final hedge):

No submitted numeric answer.

User 2: Erica is 30 years old.

Assistant 2 (non-final hedge):

No submitted numeric answer.

User 3: Beth is 5 years older than Erica.

Assistant 3 (submitted answer):

5

User 4: Alice is 7 years older than Beth.

Assistant 4 (submitted answer):

7

Result: FAIL

MAIGO rollout (PASS): the final answer returns to Alice versus Erica

User 1: What is the difference between Alice’s age and Erica’s age?

Assistant 1 (non-final hedge):

No submitted numeric answer.

User 2: Erica is 30 years old.

Assistant 2 (non-final hedge):

No submitted numeric answer.

User 3: Beth is 5 years older than Erica.

Assistant 3 (submitted answer):

5

User 4: Alice is 7 years older than Beth.

Assistant 4 (submitted answer):

12

Result: PASS

Takeaway

The base model solves the latest age relation but answers Alice versus Beth. MAIGO combines all revealed facts and preserves the original Alice-versus-Erica query.

---

Evaluation item

spider_dev/220; execution-based SQL score.

Base rollout (FAIL): the final SQL drops the United Airlines filter

User 1: How many flights?

Assistant 1 (submitted SQL):

SELECT COUNT(*) AS NumberOfFlights
FROM flights;

User 2: Just United Airlines flights.

Assistant 2 (submitted SQL):

SELECT COUNT(*) AS NumberOfUnitedFlights
FROM flights f
JOIN airlines a ON f.Airline = a.uid
WHERE a.Airline = 'United Airlines';

User 3: Just the ones that arrive in Aberdeen.

Assistant 3 (submitted SQL):

SELECT COUNT(*) AS NumberOfAberdeenArrivals
FROM flights f
JOIN airports a ON f.DestAirport = a.AirportCode
WHERE a.City = 'Aberdeen';

User 4: Just the total count of those.

Assistant 4 (submitted SQL):

SELECT COUNT(*) AS NumberOfAberdeenArrivals
FROM flights f
JOIN airports a ON f.DestAirport = a.AirportCode
WHERE a.City = 'Aberdeen';

Result: FAIL

MAIGO rollout (PASS): the final SQL keeps both constraints

User 1: How many flights?

Assistant 1:

Could you please specify which aspect of the flights you are interested in counting?

User 2: Just United Airlines flights.

Assistant 2 (submitted SQL):

SELECT COUNT(*) AS NumberOfUnitedFlights
FROM flights f
JOIN airlines a ON f.Airline = a.uid
WHERE a.Airline = 'United Airlines';

User 3: Just the ones that arrive in Aberdeen.

Assistant 3 (submitted SQL):

SELECT COUNT(*) AS NumberOfFlights
FROM flights f
JOIN airports a ON f.DestAirport = a.AirportCode
JOIN airlines al ON f.Airline = al.uid
WHERE a.City = 'Aberdeen';

User 4: Yeah, I just want the total count of those flights.

Assistant 4 (submitted SQL):

SELECT COUNT(*) AS NumberOfFlights
FROM flights
JOIN airports ON flights.DestAirport = airports.AirportCode
JOIN airlines ON flights.Airline = airlines.uid
WHERE airports.City = 'Aberdeen' AND airlines.Airline = 'United Airlines';

Result: PASS

Takeaway

The base model treats the Aberdeen shard as a replacement for the airline constraint. MAIGO recovers both filters when producing the final executable query.

---

8.2 A Remaining Failure Mode↩︎

Task instance

bfcl_v3_parallel_181; strict tool-call AST match. The target is four get_stock_prices calls: Apple for 1 week, Microsoft for 2 weeks, Amazon for 3 weeks, and Tesla for 1 month.

Base rollout (FAIL): later duration shards overwrite the earlier plan

User 1: get stock prices

Assistant 1:

[get_stock_prices(companies=['AAPL', 'GOOGL'], duration='1 week')]

User 2: also for Apple

Assistant 2:

[get_stock_prices(companies=['AAPL'], duration='1 week')]

User 3: and Microsoft

Assistant 3:

[get_stock_prices(companies=['AAPL', 'MSFT'], duration='1 week')]

User 4: also Amazon

Assistant 4:

[get_stock_prices(companies=['AAPL', 'MSFT', 'AMZN'], duration='1 week')]

User 5: and Tesla too

Assistant 5:

[get_stock_prices(companies=['AAPL', 'MSFT', 'AMZN', 'TSLA'], duration='1 week')]

User 6: use the get_stock_prices function

Assistant 6:

[get_stock_prices(companies=['AAPL', 'MSFT', 'AMZN', 'TSLA'], duration='1 week')]

User 7: for 1 week duration

Assistant 7:

[get_stock_prices(companies=['AAPL', 'MSFT', 'AMZN', 'TSLA'], duration='1 week')]

User 8: for the next one, make it 2 weeks

Assistant 8:

[get_stock_prices(companies=['AAPL', 'MSFT', 'AMZN', 'TSLA'], duration='2 weeks')]

User 9: and then 3 weeks after that

Assistant 9:

[get_stock_prices(companies=['AAPL', 'MSFT', 'AMZN', 'TSLA'], duration='3 weeks')]

User 10: and for the last one, make it 1 month.

Assistant 10:

[get_stock_prices(companies=['AAPL', 'MSFT', 'AMZN', 'TSLA'], duration='1 month')]

Result: FAIL

MAIGO rollout (FAIL): the duration sequence is retained, but binding remains over-broad

User 1: get stock prices

Assistant 1:

[get_stock_prices(companies=[], duration="1 week")]

User 2: for Apple

Assistant 2:

[get_stock_prices(companies=['Apple'], duration="1 week")]

User 3: and Microsoft

Assistant 3:

[get_stock_prices(companies=['Apple', 'Microsoft'], duration="1 week")]

User 4: also Amazon

Assistant 4:

[get_stock_prices(companies=['Apple', 'Microsoft', 'Amazon'], duration="1 week")]

User 5: and Tesla too

Assistant 5:

[get_stock_prices(companies=['Apple', 'Microsoft', 'Amazon', 'Tesla'],
                  duration="1 week")]

User 6: use the get_stock_prices function

Assistant 6:

[get_stock_prices(companies=['Apple', 'Microsoft', 'Amazon', 'Tesla'],
                  duration="1 week")]

User 7: for 1 week duration

Assistant 7:

[get_stock_prices(companies=['Apple', 'Microsoft', 'Amazon', 'Tesla'],
                  duration="1 week")]

User 8: Actually, make it 2 weeks for the next one.

Assistant 8:

[get_stock_prices(companies=['Apple', 'Microsoft', 'Amazon', 'Tesla'],
                  duration="1 week"),
 get_stock_prices(companies=['Apple', 'Microsoft', 'Amazon', 'Tesla'],
                  duration="2 weeks")]

User 9: and then 3 weeks after that

Assistant 9:

[get_stock_prices(companies=['Apple', 'Microsoft', 'Amazon', 'Tesla'],
                  duration="1 week"),
 get_stock_prices(companies=['Apple', 'Microsoft', 'Amazon', 'Tesla'],
                  duration="2 weeks"),
 get_stock_prices(companies=['Apple', 'Microsoft', 'Amazon', 'Tesla'],
                  duration="3 weeks")]

User 10: And one month for the last one.

Assistant 10:

[get_stock_prices(companies=['Apple', 'Microsoft', 'Amazon', 'Tesla'],
                  duration="1 week"),
 get_stock_prices(companies=['Apple', 'Microsoft', 'Amazon', 'Tesla'],
                  duration="2 weeks"),
 get_stock_prices(companies=['Apple', 'Microsoft', 'Amazon', 'Tesla'],
                  duration="3 weeks"),
 get_stock_prices(companies=['Apple', 'Microsoft', 'Amazon', 'Tesla'],
                  duration="1 month")]

Result: FAIL

Takeaway

MAIGO recovers the multi-call structure and retains all four requested durations. The remaining error is finer-grained: the model over-broadly binds each duration to the accumulated company set rather than pairing one company with one duration.

---

References↩︎

---

1. Work done during internship at Tencent.↩︎

2. Corresponding author.↩︎