Why
Mistral's Agentic Search launch (post, docs) published a useful decomposition of where retrieval-quality gains actually came from on their benchmarks (FinanceBench, OfficeQA Pro; defaults, no tuning):
- one-shot RAG → iterative search loop: +47–53pp accuracy — the big lever;
- loop → loop + navigation tools (
open/navigate/read/grep): +7–9pp;
- reranking / query rewriting: optional extras, not part of the headline numbers.
Their architecture puts the loop in the caller (an MCP toolset any agent drives), not in the retrieval engine — the same bet as ADR-0012's dumb adapters. And B2 already exposes their tool surface: b2 search --json (hybrid + D2 evidence verdict, now with --exclude for follow-up queries), plain-Markdown files an agent reads and greps directly, plus neighbors/explain/similar for the typed graph they don't have.
Two caveats make this an experiment rather than a conclusion:
- Their corpora are 147-page SEC filings and ~89k pages of scanned Treasury tables. Their own "indexed retrieval is the right starting point" list (direct lookups, short clean documents, predictable questions) describes a personal vault — so the transfer is exactly what's untested.
- Loop gains scale with the calling model's tool use.
ask's default is llama3.2-class local — the class that executes loops worst.
The experiment
Same question set, two arms, scored with the existing harness (read docs/evals/README.md process rules before touching corpus/labels/metrics):
- (a) one-shot:
b2 ask as shipped (flow ④: condense → retrieve at ASK_PASSAGES → answer).
- (b) loop: a capable tool-using agent driving
b2 search --json + reading the hit files, bounded hop count, --exclude on re-queries. No B2 code changes — the loop lives in the agent.
Worth reporting per arm: accuracy (the harness's containment/judged scoring), tokens, wall-clock, hops used.
Decision criteria
Why
Mistral's Agentic Search launch (post, docs) published a useful decomposition of where retrieval-quality gains actually came from on their benchmarks (FinanceBench, OfficeQA Pro; defaults, no tuning):
open/navigate/read/grep): +7–9pp;Their architecture puts the loop in the caller (an MCP toolset any agent drives), not in the retrieval engine — the same bet as ADR-0012's dumb adapters. And B2 already exposes their tool surface:
b2 search --json(hybrid + D2 evidence verdict, now with--excludefor follow-up queries), plain-Markdown files an agent reads and greps directly, plusneighbors/explain/similarfor the typed graph they don't have.Two caveats make this an experiment rather than a conclusion:
ask's default is llama3.2-class local — the class that executes loops worst.The experiment
Same question set, two arms, scored with the existing harness (read
docs/evals/README.mdprocess rules before touching corpus/labels/metrics):b2 askas shipped (flow ④: condense → retrieve atASK_PASSAGES→ answer).b2 search --json+ reading the hit files, bounded hop count,--excludeon re-queries. No B2 code changes — the loop lives in the agent.Worth reporting per arm: accuracy (the harness's containment/judged scoring), tokens, wall-clock, hops used.
Decision criteria
askdesign is validated with evidence on a personal-vault corpus; Ranking: cross-encoder reranker over the fused top-N (+ query expansion seam) #28 (cross-encoder reranker) and Search fusion tuning: RRF weighting + stopword filter for short queries #105 (fusion tuning) stay parked on the same evidence (Mistral's numbers say iteration recovers from weak first results more cheaply than better first results — but that claim should be measured here, not imported).serveHTTP adapter — a third dumb adapter over the façade #24serve) adapter — each tool oneVaultcall, thin-adapter rules intact. Still no loop insideb2-core, andask's local-model path stays one-shot.