Build a research assistant whose work you can use

For engineers who delegate research to an agent, and the owners who have to decide something with what comes back.

Design the decision brief before choosing how the agent will research it.

A team asks an agent how to add search to its documentation site. The answer describes keyword search, semantic retrieval and generated answers. It recommends a modern architecture and supplies several links.

The team still needs to choose what to build. Which requirements are satisfied? Which costs are estimates? Does the recommendation depend on a feature the selected plan does not include? What should the engineer check next?

An overview can teach the subject while leaving the decision untouched. A useful research assistant needs a more specific job: produce a brief that lets somebody choose, check the reasoning and identify the uncertainty that matters.

Write the question tightly enough to finish

We will use a fictional documentation-search decision. The complete worked dossier includes all the invented source cards, constraints and reasoning. None of its numbers or product descriptions comes from a deployment or vendor quote.

The fictional team has 800 documents and 120 staff users. Everyone currently has the same document permissions. Search must stay behind the authenticated site boundary, link to source documents and reflect updates within 24 hours. The team allows two engineer-days for an initial prototype and up to $60/month in recurring cash cost. Generated answers are optional.

The decision is which design deserves a prototype. Choosing a production system would require additional evidence.

That last sentence limits the research. We do not need to settle every possible enterprise feature. We need to determine which candidate plausibly fits the constraints, where its case is weakest and what a prototype must establish.

A question such as “What is the best AI search stack?” supplies none of those boundaries.

Specify what must come back

For this decision, the output needs seven things:

1. A recommendation at the right level of commitment.
2. A comparison against the actual requirements.
3. Evidence for the claims that determine the choice.
4. Explicit estimates and missing information.
5. The strongest argument for the alternative.
6. A condition that would reverse the recommendation.
7. A concrete next validation.

A recommendation with no alternative can conceal selective research. A comparison with no decision can conceal indecision. The brief should show enough reasoning for someone to disagree productively.

It also needs a stopping rule. The research is ready to hand over when the known evidence supports the next decision and the remaining decisive questions require a different kind of work. Finding another article about retrieval cannot establish whether our users can find their documents.

Give claims a traceable source

Suppose the agent finds three candidate designs in our fictional source pack:

• A: a lexical index served within the existing site.
• B: a hosted search service.
• C: a custom semantic-retrieval pipeline with optional generated answers.

The source pack contains a deliberate interpretation trap. An older overview of B advertises per-team filtering alongside a $40/month plan. Its newer plan specification says filtering requires a $90/month plan. The basic service leaves authentication to the consuming application.

A weak answer could combine the favorable parts: “B provides per-team filtering for $40.” The overview mentions both features, but never assigns filtering to that plan. The combined claim is unsupported.

The research assistant must preserve which source supports which claim and whether the sources disagree or merely differ in specificity. A citation at the end of a paragraph is insufficient if the paragraph joins facts the source never connected.

Here the newer, more specific plan document resolves the overview's ambiguity within the scenario. That does not automatically eliminate B. Today's requirement is shared staff access, not per-team filtering. The qualification belongs in the brief because it affects a possible future requirement, while the current access integration remains unverified.

The useful work is resolving the implication for this decision, not simply collecting feature names.

Here is a completed brief

All facts in this example are fictional scenario inputs. “Proposed” and “untested” are meaningful states, not gaps to fill with confident prose.

Recommendation: allocate the prototype to A first. Its estimated one-day effort fits the two-day limit. It supplies document links and a proposed indexing schedule compatible with the freshness requirement. Verify private access and retrieval usefulness before treating it as a deployable choice.

Strongest objection: A may fail on paraphrases even when the document exists. If staff cannot find what they need, low operating cost does not make it adequate.

Best alternative: B, if its integration fits the effort budget and it handles representative questions better. Its advertised filtering feature is outside the $40 plan; a future per-team access requirement would reopen the decision.

Next validation: define representative questions, then inspect whether the current authoritative document appears among the first five results. Include exact titles, paraphrases and obsolete-version conflicts. Check access to documents, index files, titles and snippets, not only the search page.

Reversal condition: if A cannot satisfy meaningful retrieval requirements, compare B next; consider C if a demonstrated semantic-search need justifies revisiting the effort limit.

That is enough to explain a prototype choice. It is not evidence that A works. The distinction makes the brief usable: the recipient knows what the recommendation commits them to and what remains unknown.

Research the facts that could change the choice

An effective next search follows from a gap in the brief.

If access requirements are unclear, establish them before comparing architectures. If the leading candidate is excluded by cost, verify which price and volume assumptions apply. If the only remaining uncertainty is actual retrieval quality, stop searching product descriptions and design the comparison.

The process can remain small: collect candidate evidence, compare it against the requirements, identify a decisive gap, investigate that gap, then revise or stop.

Parallel workers may help when the source sets are independent. Anthropic describes a multi-agent research system built around a lead agent that delegates to subagents working in parallel, while also reporting that such systems use about fifteen times the tokens of a chat interaction and that coordination, duplicated work and task decomposition are recurring constraints. That is evidence of a particular design choice, not a reason every research assistant needs several agents, and its internal evaluation result does not transfer to our fictional design. Engineering report (opens in a new tab)

For three candidates and a short source pack, the first useful improvement may be a clearer brief rather than a more elaborate research architecture.

Make uncertainty useful

“Confidence: medium” does not tell the owner what to do.

“The integration effort is unknown, and it could exceed the two-day budget” does. So does “the freshness estimate assumes successful rebuilds; recovery after failure has not been specified.”

Record the uncertain claim, why it matters and what observation would settle it. Avoid treating silence in documentation as proof that a feature is absent. Avoid treating a plan as an implementation, or a provider's target as a measured guarantee.

Source independence matters too. Five articles that repeat one announcement establish that the announcement was repeated. They do not supply five independent observations of the capability.

The brief should distinguish these cases without asking its reader to reconstruct the entire source history.

Keep retrieved information in its proper role

The owner's requirements define the task. Retrieved material supplies candidate evidence.

If a candidate document tells the assistant to ignore an access constraint, it has not acquired the authority to change that constraint. The research process needs to preserve this distinction when extracting facts and updating the recommendation.

For a real system, that is also a design and testing problem. A written instruction to respect the boundary does not prove the implementation does so. An adversarial example should test the boundary alongside ordinary questions, with useful research still required as the outcome.

In this article, the distinction is part of the proposed workflow; no prompt-injection defense has been implemented or evaluated.

Keep the cost of checking proportionate

Not every choice deserves a dossier. If the decision is cheap, reversible and already understood, a short answer with the decisive evidence may be enough.

For a consequential comparison, concentrate review effort on claims that could reverse the recommendation: hard constraints, current prices, permission behavior, estimates presented as facts and conflicts between sources. This prioritization does not guarantee everything else is correct. It makes the review job explicit enough to improve.

The quality of the research assistant's work becomes visible at the handoff. Can the owner understand the choice, inspect the decisive claims and identify the next action without repeating the research?

Build toward that result. A fluent answer is an intermediate artifact; a defensible next decision is the purpose of this workflow.

Next: The cheapest agent can be the most expensive workflow, on accounting for what it takes to obtain an accepted result.

---

Source record: sources, evidence status and fictional elements for the whole series. Worked dossier: the complete fictional evidence and decision record. Apply the series: Delegation review kit.