Every team that wants agents to do research eventually reaches the same fork. You can assemble your own research agent from a model, a search source, a page fetcher and some orchestration code, or you can call a deep research API that takes a question and returns a cited report. Both work. They fail differently, cost differently and leave you with very different amounts of control over what happens in between. This guide is for the people who will own the decision and live with its consequences: what you would actually be building, what buying hides, how the two compare on five axes, and a checklist to settle it.
What “building” really means
A demo research agent fits into an afternoon: a loop that searches, reads a few pages and writes a summary. A research agent your team can rely on is a different object. These are the components you end up owning:
| Component | What it does | What tends to break |
|---|---|---|
| Planner | Turns a question into ordered steps and sub-questions | Plans that drift from the question or never stop |
| Search | Finds candidate sources | Stale or low-quality results, provider changes |
| Fetch and parse | Gets readable text out of pages and files | Scripts, paywalls, redesigns, scanned PDFs |
| Extraction | Pulls specific facts into fields | Values guessed instead of marked unknown |
| Synthesis and citation | Writes the answer and ties claims to passages | Citations that do not support the claim |
| Evaluation | Checks quality on a fixed set of questions | Usually skipped, then badly missed |
| Operations | Limits, retries, logging, cost tracking | Runaway runs and unexplained bills |
Demos spend their time in the first three rows. Production effort goes into the last three. If your estimate leaves out evaluation and operations, it is an estimate for the demo. Research agents that hold up walks through the components one by one.
What buying gives you, and what it hides
A deep research API packages all of the above behind one call. You get a working system immediately, the provider absorbs breakage in search and parsing, and quality can improve without any work on your side. For many teams that is the right trade.
The price is visibility. Questions to put to any provider before you commit:
- Can you see the plan the system followed, or only the final report?
- Can you restrict which sources it may use, and is that restriction enforced or merely advisory?
- Are citations at the passage level with retrieval dates, or links to whole pages?
- Does the output separate supported findings from questions it could not answer?
- What happens to your question and any material you send: retention, use for training, location?
- How is a run priced, and can you cap a single run before it starts?
Comparing providers on these points is the subject of choosing a deep research API. This page stays with the build-or-buy question itself.
Five axes that decide it
Control
Building gives you every lever: which sources, how deep, when to stop, what format. Buying gives you the levers the provider exposes. The useful question is how often you will need a lever that is not on offer. If your research is general, such as market overviews or background on a topic, the exposed levers are usually enough. If it is narrow and repetitive, such as the same twenty regulators or the same filing types every week, you will want control over sources and extraction.
Evidence
Research output is only as useful as your ability to check it. Whichever route you take, insist on claim-level citations, retrieval dates and an explicit list of what was not found. Building makes this easy to enforce; buying turns it into a selection criterion you have to test for.
Maintenance
A built agent is a product whose dependencies change under you: search providers alter their responses, sites redesign, models behave differently after an upgrade. Someone has to own the evaluation set and the on-call rota. A bought service moves that burden to the provider and replaces it with a different one: their changes arrive on their schedule, and your results can shift without a single line of your code changing.
Cost model
Building costs engineering time, up front and ongoing, plus variable spend on models, search and fetching. Buying is usually charged per request or per unit of work, with little fixed cost. Research runs vary a great deal in length, so on both routes the important question is not the average cost but whether you can bound the worst case. A hard ceiling per run and per day matters more than the unit price; see put a ceiling on agent spend.
Governance
This axis is often missing from the comparison and later becomes the deciding one. Who approved this research question? Which sources was it allowed to use, and did it stay inside that list? Where did our documents go? Can we show the trail to an auditor or a client? A home-built agent answers these only if you build the answers in. A bought API answers them only as far as its logs and its contract reach.
A third option: govern the work, choose the parts
The choice is less binary than it looks. Many teams buy the parts that change fastest, such as search and parsing, and build or adopt the layer that holds the rules: the plan, the source list, the approvals, the evidence and the record. That layer is where your organization's specific requirements live, and it should not need replacing when a search provider or a model does.
GoCux sits in that layer for research on a team's material. A research plan there consists of the question, its ordered steps and a source allowlist. Drafting one only records it; someone approves it before anything runs, and the run cannot reach beyond what was approved. An allowlist left empty admits no source at all. If the question changes, the right move is a revised plan rather than a quietly expanded one, as a changed question needs a new plan explains. Findings backed by quotations are kept apart from questions nothing answered, work draws on visible credits under a daily cap, and every request, decision and outcome sits on one trail the team can read. GoCux is not a web search engine, so open-web material arrives through an authorized browsing or export step rather than a crawl. Governance describes the gate and the trail in more detail.
Patterns that work
- Buy first, build the evaluation. Start with an API, but write your own question set and scoring from the first week. When you hit limits, you will know exactly which ones.
- Build around a narrow domain. Where sources are known and stable, a purpose-built agent with a fixed allowlist and strict extraction rules is often simpler than a general one.
- Keep the rules outside the engine. Approvals, source lists, spend limits and the audit record should not depend on which research engine sits underneath, so that you can swap it. Governance that survives a model change makes the same argument for models.
Decision checklist
Answer these together with the people who will run the system, not only the people who will build it.
- Is our research general, or narrow and repetitive? General leans towards buying; narrow leans towards building or a governed layer.
- Do we need to restrict sources, and must that restriction be enforced rather than requested?
- Can every claim in the output be traced to a passage with a retrieval date?
- Does the output list what was not found, separately from what was?
- Who owns the evaluation set and reruns it after every change?
- Who is on call when results degrade, and how would we notice?
- Can we cap the cost of a single run and of a day, and what happens at the cap?
- Where do our questions and documents go, and does that match how we classify that data?
- Who approves a research question before it runs, and is that approval recorded?
- If the engine changed tomorrow, which of our rules would survive?
If questions seven to ten have no owner yet, choosing between building and buying is premature. Settle those first; after that, either engine can be swapped in without rewriting how the team works.
Bring this workflow into your workspace.
Set the scope. Review the evidence. Approve the steps that need it.