How a brief is made
A brief is a bounded, cited answer — not a summary of one page and not a list of links. This is the acceptance contract for the research engine.
Production status: live. This page separates the shipped product contract from continuous hardening targets. Numerical SLOs remain engineering targets until a reproducible evaluation is linked; that qualification is about measurement, not product availability. See the agent contract.
Use the research tool only when it changes the answer
Fresh research has a cost in time, money, and model context. WebBrief is selected only when current external evidence could materially change an answer or decision. Local repository facts, stable knowledge, and casual low-stakes lookups stay on the direct path.
The client makes one initial call. A complete result is reused; one deeper pass is allowed only for a reported material gap or an explicit user request. Raw records, live inventory, exhaustive extraction, and actions route to specialized connectors. The exact machine policy is published at agent-policy.json.
The production speed path
The ResearchBrief v1 hardening path starts with metadata and short, query-relevant passages. Source adapters should run concurrently behind individual deadlines; results are canonicalized, deduplicated, and fused before any full-page work begins. The engine fetches only the best two or three documents when snippets do not provide enough evidence, then stops as soon as the question's material facets are covered.
This avoids the slowest pattern found in the Scout reference pipeline: downloading several pages one by one and then sending each page through a separate model call. Batch extraction, bounded concurrency, provider timeouts, partial results, and cache-aware freshness keep one slow source from holding the answer hostage.
The design follows capabilities exposed by current primary APIs: Exa offers instant, fast, and deep search modes plus query-focused highlights; Tavily exposes explicit fast and ultra-fast search depths; Firecrawl supports concurrent batch scraping and cache-age controls.
Sources and source independence
Each query selects source classes for the question: official documentation and changelogs, GitHub issues and discussions, general search, papers, news, and public community discussion. A single provider is not mistaken for a single source, and syndicated copies of one underlying announcement do not count as independent corroboration.
Primary evidence wins. First-party documentation, source code, filings, and original papers outrank commentary for factual claims. Recency is a ranking signal shaped by the topic's volatility, not a universal filter; every source records both publication and retrieval time.
Triangulation and disagreement
Claims are decomposed before writing. Important claims seek two independent sources; a claim with only one adequate source is explicitly attributed and receives lower confidence. Search results, error pages, login walls, and model-generated summaries are never silently promoted to primary evidence.
Disagreement is content. Credible conflicting evidence is represented in conflicts, cited on both sides, and summarized in the brief. Missing coverage produces status: partial and a concrete next action instead of a confident guess.
Citation and output contract
Every ResearchBrief v1 response must satisfy the same deterministic gates:
- a direct bottom line and a 640-token maximum for
brief_md, - inline [n] markers resolving to contiguous, dated source records,
- every factual claim counted and cited before
statuscan becomplete, - explicit coverage, confidence, conflicts, limitations, and material gaps,
- per-stage timings and a stable trail URL for the full evidence manifest.
The compact response contract is ResearchBrief v1. Full passages and provider traces remain in the linked trail rather than consuming the caller's context. Clients adopting v1 return the brief as structured content with the same output schema and a text fallback while preserving compatibility with the live compact response.
Continuous quality evaluation
Schema validity is necessary but not sufficient. The fixed evaluation corpus separately measures retrieval relevance, answer faithfulness, answer relevance, citation correctness, and citation completeness. These dimensions follow the primary RAGASand ALCE research rather than one opaque “quality score.”
- 100% schema-valid responses and citation-marker resolution,
- 100% citation completeness for briefs labeled complete,
- ≥95% citation entailment on a human-audited evaluation set,
- zero known error, login, or empty pages accepted as evidence,
- blind answer-quality comparison against a documented search-and-fetch baseline.
Targets remain targets until the prompts, corpus, raw traces, judge configuration, and human audit are published in the evaluation repository.
Latency budgets, not vague speed claims
Quick and deep are separate service levels. The engineering SLOs are: progress or acknowledgement within 1 second at p95; quick briefs at ≤5 seconds p50 and ≤12 seconds p95; deep briefs at ≤30 seconds p50 and ≤90 seconds p95. A quick request reaches a 15-second deadline and returns an honest partial result rather than waiting indefinitely.
Every response reports total, planning, search, fetch, synthesis, validation, and cache-saved milliseconds. We publish achieved numbers only after cold-cache and warm-cache runs meet the same corpus and concurrency protocol.
Privacy and retention boundaries
Agents send only task-relevant context, never an entire private conversation by default. The v1 hardening architecture requires separate query, evidence, and synthesis caches; authorization and visibility checks on every trail lookup; and cache partitioning for private or licensed evidence.
Retention, deletion, and provider data use must stay aligned across the running service and its customer-facing policies. Any stronger claim, including a zero-retention mode, requires runtime and provider verification before publication.
How tokens are counted
The bound applies to returned brief_md, measured with the production model tokenizer before a response leaves the server. Structured provenance is compact and the detailed trail stays out of band, so an audit remains available without turning every answer into another context dump.
Baseline comparisons count the same tokenizer and include every search, fetch, and tool result that enters the host model. Long raw context is not assumed harmless: the primary Lost in the Middle study found that retrieval from long contexts can degrade based on evidence position.