T-Search: an open agentic retriever for hard search

Introduction

Today we are releasing T-Search, an open-weight agentic retriever for hard multi-step search. Given a question and a fixed corpus, it plans and runs a multi-round search and returns a ranked list of evidence chunks, each with a short justification, deliberately not a finished answer. It is a 35B-parameter mixture-of-experts (~3B active per token) built on Qwen3.6-35B-A3B, trained with supervised fine-tuning and then reinforcement learning on a pure recall reward. The result: 61.3 Recall@10 with three parallel rollouts fused, averaged across seven English and Russian benchmarks, ahead of GLM-5.1, Kimi-K2.6, and DeepSeek-V4-Flash, and +19.8 points over its own base model.

• Model: t-tech/T-Search, plus FP8 and NVFP4 quantizations (Apache-2.0).
• Benchmarks: TRuST and SynthComp (ODC-BY).
• Harness: turbo-llm/t-search-harness on GitHub.
• Everything in one place: the T-Search collection.

Why build a retriever rather than another end-to-end agent? Ask a hard question and most retrieval systems fail quietly: they hand back ten plausible documents, and not one of them holds the single line the answer depends on. A fluent model then turns that near-miss into a confident mistake. Hard questions do not hand you the search terms. Answering them means finding an intermediate entity the question never names, following it from one source to the next, and filtering out documents that look right but are not. The hard part of “deep research” is not writing the answer, it is gathering the right evidence. That is the problem T-Search attacks, and only that problem.

Final-answer requirements like format, citations, tone, and product rules differ for every team, while the work of finding the right context barely does. So T-Search does the reusable part and hands the evidence to whatever generator you already trust. That makes it a component, and it changes how you measure it. The yardstick is retrieval quality, Recall@10: of the gold evidence chunks a question depends on, the share that land in the top ten T-Search returns. Measured that way, on retriever-isolation benchmarks like BrowseComp-Plus, T-Search beats much larger open models, and its own base, by a wide margin.

Below, we walk through why long searches degrade and the context management that prevents it, the agent loop itself, the synthetic-data factory and RL recipe behind it, and the full results.

Context management

The central enemy of a long-running search agent is not running out of tokens. It is context rot: as tool outputs pile up, the accumulated noise starts to degrade the model’s judgment well before the window is full. Every irrelevant chunk the agent read three searches ago is still sitting in context, competing for attention with the one line that actually matters. For a retriever, whose entire job is to not lose that line, this is fatal.

So the real design question is: how do you keep working on a hard question without letting the window rot? We looked at the common answers and rejected each for a specific reason.

• Discard everything and start over. Simple, and it even shows measurable benchmark gains, but each round becomes an essentially independent attempt. Expensive tool-call results are lost and re-fetched every round (some systems, like DeepSeek-V3.2 (DeepSeek-AI, 2025), simply drop the first 75% of history). For a retriever this throws away exactly the evidence you paid to find.
• Summarize the history. Compress everything seen so far into a short note. Summarization is lossy in the worst possible way: it smooths over a caveat, drops a negation, or turns a weak signal into a confident fact. When the answer rests on a single qualified line, a summary is where that qualification dies. (This is the approach in agents like Claude Code and Codex, where it fits their use case better than ours.)
• External memory. Push history into a separate store queried through tools, as in MemGPT (Packer et al., 2023). Workable, but it adds a retrieval problem inside your retrieval problem.
• Directly edit the context. Give the model a tool to prune its own window (Chroma’s Context-1 (Bashir et al., 2026) does this with a prune-chunks tool). Closer to what we want, but we wanted the pruning decision fused into the search loop itself.

Our answer sits between those extremes: a relatively small, fixed working window; rounds that imitate a longer context; explicit, model-controlled saving of the chunks that matter; and quiet dropping of everything that does not. Nothing important is silently rewritten, and nothing irrelevant is allowed to accumulate.

The visualization below contrasts the three strategies on the same stream of searches. Watch how the decisive chunk survives under rounds-with-memory but is smoothed away by summarization and thrown out by discard-all.

The window the model reasons over stays clean from the first search to the last, no matter how many rounds a question takes. That is the condition a recall-hungry retriever needs, and the next section walks through the loop that implements it.

The agent loop

T-Search runs over a fixed, pre-indexed corpus, a deliberate choice that makes retrieval quality reproducible and the agent itself measurable. Inside that corpus the model acts through exactly three tools:

Rounds

A single question can take dozens of searches to resolve. Pouring all of that into one ever-growing context window is exactly the context rot we just walked through. Instead, T-Search works in rounds. The round cap is a configuration knob (our released setup uses five), and each round is an ordinary ReAct loop with a budget of 32,768 tokens. When the model calls save_and_advance, the next round opens with a fresh window holding only the question and the evidence saved so far; everything else is dropped. Rounds simulate a much longer working context while keeping each individual window short and clean.

Within a round the model always sees three things: the original question, the evidence it has saved so far, and the coverage picture. That last one is not computed for the model: at every save_and_advance and finalize_ranking call, the model itself declares two lists, covered_concepts and unresolved_concepts, and the harness rejects the call if the lists overlap or if both are empty. From there it decides whether to search again, save and advance, or finalize.

Guardrails

Left unconstrained, an agent finds shortcuts that look like progress but are not: skip a round’s actual searching and call save_and_advance anyway, declare a question covered without real evidence to finalize early, or keep polling the same easy query as filler. A handful of hard rules close each of those:

To watch the loop at work, here are four real episodes T-Search solved on English BrowseComp-Plus, ordered easy to hard, reconstructed from the full run transcripts: every query the agent issued, what it chose to save and why, the coverage it declared at each step, and the final ranking. Search effort tracks the real difficulty of a question rather than its length: the easiest is done in two searches and a single round, while the hardest takes five rounds and forty-eight searches to run down the final piece of evidence.

Each finalized ranking is one rollout. You can run T-Search once, or run any number of rollouts in parallel and fuse their rankings with Reciprocal Rank Fusion (Cormack et al., 2009) (top-10). Fusion trades latency, since you wait for the slowest rollout, for a clear recall gain, and it is the difference between the two T-Search rows you will see in the results.

The synthetic data factory

A recall-optimized retriever needs training questions that are genuinely hard to search: multi-hop, verifiable, and grounded in a fixed corpus, at a scale no team can hand-write. So we built a factory for them.

Every question begins as a cell: a combination of a mechanic, a form, and an answer type, sampled from a taxonomy with weights tuned for even coverage. The mechanic is what actually makes a question hard to search:

• traverse an entity chain: hop from a named thing to an unnamed one and onward;
• intersect independent constraints: the answer is the one item satisfying several unrelated conditions;
• reason over time: renamings, status changes, “the current version of…”;
• gather many candidates, then compare them on a found property;
• do a small calculation mid-reasoning.

A sampled cell is handed to a generator as an explicit specification, which composes a question together with its set of supporting gold chunks.

Adversarial validation

A generated question is worthless if it can be answered the wrong way: by guessing, by reading the question too literally, or by a single lucky search. So every candidate runs a cheap-to-expensive gauntlet, and later stages actively try to solve it by shortcuts the question wasn’t meant to allow. Only about 60% survive, roughly 67,000 generated and roughly 40,000 kept.

1. Solvability: the full set of support chunks must uniquely derive the answer.
2. No surface leak: neither the answer nor the key intermediate entities may be named directly (or nearly so) in the question.
3. No broad-query shortcut: feeding the whole question as a single search query must not surface the needed documents at the top.
4. Chunk necessity: remove each support chunk in turn and re-check; anything decorative is dropped, leaving a minimal sufficient set.
5. Full agent run: if a strong agent solves it too easily, it is too simple, and it goes back for rework.

Feedback from each stage, which chunk was superfluous, where wording leaked, which query found a shortcut, flows back to the composer, which fixes the question and resubmits. The same factory produced the public SynthComp benchmark: an English version built over Essential-Web and a Russian version over FineWeb2 and Russian Wikipedia, each with fixed indices.

Training

T-Search starts from Qwen3.6-35B-A3B, a mixture-of-experts model with 35B total parameters and roughly 3B active per token, and is trained entirely on synthetic bilingual search tasks. Training has two stages, supervised fine-tuning and then reinforcement learning, and each is run separately for English and Russian and then merged, so the two languages do not interfere during learning but their gains end up in a single checkpoint.

flowchart LR
  A["Synthetic search tasks"] --> S1["SFT · EN"]
  A --> S2["SFT · RU"]
  S1 --> D["DARE merge"]
  S2 --> D
  D --> R1["RL · GSPO · EN"]
  D --> R2["RL · GSPO · RU"]
  R1 --> M["SLERP merge"]
  R2 --> M
  M --> T["T-Search"]

Supervised fine-tuning

The SFT data is collected by running a strong teacher model on the fixed index and recording its trajectories. The unit of training is the round, not the whole episode: one long trajectory becomes several compact samples, each a self-contained (question + saved memory + a series of searches + an end decision) with a different task state.

Two choices matter here. First, the harness automatically detects erroneous actions and masks them out of the loss, but it deliberately keeps the teacher’s recovery: when the teacher makes a mistake, gets an error signal, and corrects course, that self-correction is exactly the behavior we want to teach. Second, we did not filter only on high-recall trajectories. Keeping the hard tail, episodes where the teacher decomposes the problem well but stumbles near the end, preserves the difficult cases the model most needs to learn from. A datamix pass then balances round number, completion method, question difficulty and mechanic, and chunk completeness, so common easy patterns do not drown out the rare, important late-round ones.

Reinforcement learning

RL runs directly on full search trajectories with real tool calls over a fixed local index: the model formulates queries, reads results, saves chunks, and finalizes, end to end. Roughly 2,000 questions per language, never seen during SFT, are held out for this stage. For every question the policy samples a group of eight rollouts; each is scored by the recall reward, and a group-normalized advantage replaces a learned value function. Clipping is asymmetric (0.2 low, 0.28 high) and the router runs in fp32.

We moved from vanilla GRPO (Shao et al., 2024) to GSPO (Zheng & others, 2025), for a reason specific to mixture-of-experts. GSPO computes its importance ratio at the sequence level rather than per token, which averages out the token-level discrepancies in expert routing between the generation pass (vLLM) and the training pass (Megatron-Core). That single change let us drop routing replay entirely, and the training telemetry backs it up: the rollout-to-train perplexity ratio converges to about 1.01, so the two engines stay consistent with no replay at all. The alternatives did worse. CISPO was unstable on rollouts containing tool calls: in some configurations the model broke its own tool-call syntax, which dragged reward down. A value-based PPO variant added instability from the value head without any recall gain.

Reward

The reward is deliberately blunt: recall of the gold evidence set. We match the chunk_ids the agent emits in finalize_ranking against the reference set and take recall. No LLM judge, no text comparison. Precision and F1 are computed too, but only as diagnostics, never as the training signal.

That last point is not an aesthetic preference. It is a lesson learned the hard way.

Rewarding precision or F1 quietly trains a worse agent. The model discovers that the safest way to keep precision high is to search less and finalize early, so the reward number climbs while real coverage falls. It becomes lazy and conservative.

Recall is the right signal because the error cost is asymmetric: a downstream reader tolerates a distractor far better than a missing fact. One more honest detail: we also tried a language-match multiplier that up-weights Russian queries against the Russian corpus (x1.2) and down-weights Russian queries against the English one (x0.5), hoping to counter the model’s English-query drift. It did not stably change recall and is not part of the released recipe.

What RL adds on top of SFT

Both stages earn their keep. Evaluated in the released harness with the default retriever, the base model averages 41.5 Recall@10. SFT, which teaches the round loop, the tool contract, and the recovery behavior the base model lacks, lifts that to 49.0. RL raises it to 56.0, the released model. The contributions are comparable (+7.5 from SFT, +7.0 from RL), and the RL gain is positive on every benchmark, largest exactly where search is hardest:

RL changes behavior, not just the score. Over training the agent learns to search harder instead of finalizing early, roughly doubling its search calls per episode. On held-out questions its best-of-4 answer accuracy climbs from 0.47 to 0.65 in English and from 0.37 to 0.51 in Russian over about 70 optimization steps.

The reward climbs steadily over training as the agent learns to search more deliberately and stop at the right time:

Results

Because T-Search is a retriever, we evaluate it the way retrievers should be evaluated: Recall@10 over fixed corpora, so the number reflects the evidence the agent gathered rather than the eloquence of some downstream answer model. The suite spans seven benchmarks: English and Russian versions of BrowseComp-Plus (Chen & others, 2025) and SealQA (Pham & others, 2025), our own SynthComp (En/Ru), and the hand-built Russian TRuST.

The headline: T-Search leads on average with three rollouts fused, and even a single rollout (55.96) beats every larger open model we tested. The gap is widest exactly where search is hardest: on English BrowseComp-Plus, T-Search reaches 72.65 against 53.48 for Qwen3.5-397B-A17B, a model an order of magnitude larger. Training the right stage on the right reward beats scaling the whole model.

Latency-quality trade-off

Both knobs that raise recall, more rounds and more fused rollouts, cost latency. Fusion runs its rollouts in parallel, so a three-rollout run costs the slowest of the three rather than their sum, but it still costs more than running one. We measured the trade-off on a 35-question subset, repeating each configuration 13 times (3 warm-up, 10 measured), sweeping the round cap over 1, 3, and 5, and timing per-query wall-clock latency end to end.

The interactive frontier chart at the top of this post traces the full picture: each point is one configuration (round cap 1, 3, or 5), each line one model as its round cap grows.

T-Search sits on the efficient frontier: the larger baselines need several times the latency to approach even the single-rollout T-Search configuration. Applications that can tolerate the extra latency should fuse three rollouts; latency-sensitive deployments can run a single rollout and still beat every larger baseline above.

Retriever robustness

Because context-gathering is decoupled from generation, the search backend is a knob you can turn without retraining the agent. Holding the agent fixed and swapping the retriever shows the effect clearly: adding an LLM reranker on top of Qwen3-Embedding-8B lifts the average to 62.9, the best configuration we measured. BM25 is interesting here: weak on BrowseComp-Plus but the strongest backend on SynthComp and TRuST, where exact-term matching pays off. When the number moves, it is the retriever moving, not the agent degrading, which is exactly the modularity we designed for.

Released benchmarks

TRuST and SynthComp are released alongside the model. TRuST is 324 hard Russian questions with short, unambiguous answers, hand-authored and verified by fifteen annotators across eight topics and five challenge types, built on the BrowseComp-Plus methodology. SynthComp is the synthetic benchmark from the factory above: 395 questions each in English and Russian, over fixed indices. Both ship ready to reproduce these numbers.

Limitations

T-Search is trained for its own harness. The rounds, the tool contract, the guardrails, the coverage prompt: the model learned to operate inside that loop, and its quality can shift in a different setup. Use it with the released harness, and validate on your own index before trusting the numbers. If the agent breaks on a case, open an issue on the harness repository with the question and index.

Release

T-Search is a retriever, trained to do one job well: come back with the evidence a hard question depends on, and leave the writing to whatever model you already trust.

If you want to run it yourself: the model and its FP8 and NVFP4 quantizations are on Hugging Face under Apache-2.0, TRuST and SynthComp ship under ODC-BY, the training and inference loop is open on GitHub as turbo-llm/t-search-harness, and the T-Search collection has everything in one place.