To build a research agent, you set up one repeatable pattern: gather information from defined sources, verify it, then synthesize a summary you can trust. In practice that means deciding the exact research question, constraining the sources, adding a step that cites where every claim came from, fixing the output format, scheduling the runs, and testing on a topic you already know before you rely on it. This tutorial walks each step with a worked weekly-digest example so a non-developer can follow it end to end.

The trap this avoids is familiar. Someone asks a chatbot to "research X," gets a fluent paragraph with no sources, and has no way to tell what is true. A research agent fixes that by gathering and checking first, and by refusing to dress up a guess as a fact.

What a research agent actually is
What a research agent actually is

What a research agent actually is

A research agent gathers information from defined sources, verifies it, and synthesizes a summary that cites where each claim came from. It is not a chatbot that answers from memory, and it is not a plain summarizer that compresses whatever it is handed. The defining feature is the verify step. A research agent can show its work; a chatbot cannot.

The whole job reduces to three stages, and naming them is the lesson that outlasts any particular tool:

Most tutorials jump straight to tools and prompts and skip the middle stage. That is a mistake, because verification is precisely what separates a research agent from a summarizer. A summarizer that is handed a wrong source produces a confident wrong summary. A research agent that is told to cite and to flag uncertainty produces a summary you can audit. If you want the conceptual underpinning of why an agent that decides which sources to read and how to weigh them is doing real work, how agents reason covers it, and how agents use tools explains the search-and-fetch step in more depth.

What you need before you build

You need three things before the build makes sense: a precise research question, a defined source scope, and a fixed output format. Vague inputs produce vague agents, so spend a few minutes here before anything else.

A precise question. "Research the market" is not a research question; it is a wish. "What did our three named competitors ship and announce in the past seven days?" is a question an agent can answer and you can check. One agent should answer one question well. If you find yourself listing five unrelated questions, that is five agents, not one.

A defined source scope. Decide where the agent is allowed to look: a specific search query, a named list of sites, a set of documents you upload, or a combination. Bounded sources do two things at once. They cut cost, because the agent reads less, and they cut the chance of a stray, unreliable source slipping into the answer. An unbounded "search the whole web" instruction is the single biggest cause of noisy, unverifiable research output.

A fixed output format. Choose the shape of the result before you run it: a five-bullet digest, a comparison table, a one-paragraph brief, or a short memo. The format is part of the spec, not a styling choice you apply afterward. An agent that knows it must produce exactly five bullets with a citation on each is far easier to trust and reuse than one told to "summarize."

Build your research agent in 7 steps

Define the question, set the sources, add the verify step, fix the output format, add guardrails, schedule the runs, then test on a known topic. Each step below maps to one decision you make once and reuse on every run.

Step 1: Define the research question precisely

Write the single question the agent exists to answer, in one sentence, with the boundaries baked in. Include the scope of time ("the past seven days"), the subjects ("these three companies"), and what counts as relevant ("product launches, funding, and pricing changes; ignore general industry commentary"). Narrow beats broad every time. A tightly scoped question is what lets the agent know when it is done and lets you check whether it answered correctly.

Step 2: Set the source scope

Name where the agent looks. That might be a specific search query, a short list of trusted sites, a company's own newsroom and changelog, or documents you upload directly. Bounded sources are the main lever for both quality and cost: fewer, better sources mean cleaner answers and cheaper runs. If a topic genuinely needs broad web search, keep the time window tight to compensate, and lean harder on the verify step that follows.

Step 3: Add a verification step

This is the step that makes it a research agent. Require the agent to attach a source link or citation to every claim, and instruct it to flag anything it could not confirm rather than smoothing it over. The rule to state plainly is "say when you are unsure." Grounding each claim in a retrieved source, instead of letting the model answer from memory, is the established way to reduce hallucination, and it is the difference between output you can audit and output you have to take on faith. For the deeper mechanics, see how to control hallucination.

Step 4: Fix the output format

Specify the exact shape of the result so it is usable without editing. "Five bullets, each one sentence, each with a source link, ordered by importance" is a format. "A summary" is not. The tighter the format, the more interchangeable the runs become, which matters once the agent runs every week and you want this Monday's digest to look exactly like last Monday's so you can scan it in seconds.

Step 5: Add guardrails

Set the rules that keep the agent honest and bounded: prefer recent sources over stale ones, weight reputable sources above anonymous ones, and require the "say when unsure" behavior to be explicit rather than implied. Add a spending limit so an unexpected loop or an unusually large source cannot run up a surprise bill. Guardrails are not bureaucracy; they are what make a recurring agent safe to leave running unattended.

Step 6: Set the trigger or schedule

Decide when the agent runs. Some research is on demand: you ask, it runs once, you read the result. Most useful research is recurring, for example every Monday at 8am before the team meets. A recurring schedule is what turns a one-off lookup into a standing intelligence feed. If you are wiring up a repeating run, scheduling recurring runs covers the timing options, and writing a prompt for a recurring agent covers keeping the instruction stable across runs.

Step 7: Test on a known topic

Before you trust the agent, run it on a subject you already understand cold and check two things: did it get the facts right, and did the citations actually support the claims? This known-topic test is the simplest, most reusable trust check there is. If the agent fumbles a topic you can grade by hand, it will fumble the ones you cannot. Only after it passes that test should you let its output flow into anything that matters.

Worked example: a weekly competitor-and-news digest

Here is the whole pattern in one concrete agent. The outcome: every Monday morning, gather the past week's notable news and product updates for three named competitors, verify each item against its source link, and deliver a five-bullet digest with a citation on every bullet.

Mapped to the seven steps, the spec looks like this:

On a describe-outcome platform, you do not wire those seven steps together by hand. You state the outcome in plain words, including the verify rule and the schedule, and the agent runs the gather, verify, and synthesize stages for you, returning the finished digest in about 60 seconds per run. This is the same job as tracking competitors automatically, with the build pattern spelled out so you can adapt it to any topic, not just competitors.

Verifying sources and keeping it honest

A research agent earns trust only if every claim traces to a source. Three habits keep it honest, and all three are worth stating explicitly in the outcome you describe rather than assuming the agent will infer them.

Require citations. No claim ships without a source link. This is the single rule that converts a fluent-but-unaccountable summary into something you can check in seconds. When a bullet has a link, verifying it is a click; when it does not, you are back to trusting a paragraph from memory.

Flag uncertainty instead of guessing. Language models can produce fluent text that is simply wrong, and the failure is hardest to catch when the writing is confident. Instruct the agent to say "could not confirm" or "no source found" rather than filling the gap. An honest blank is more useful than a polished error, because you know exactly where to look yourself.

Keep a human in the loop on anything consequential. For a digest you skim, the agent's verified output is usually enough. For anything you publish, send to a customer, or make a decision on, a person should read it before it goes out. The agent does the gathering and checking that used to eat an afternoon; the human does the final judgment that should never be fully delegated. Keeping a human review step in the flow is how you get the speed without surrendering the accountability.

Guardrails and cost

Bound the source scope and the run frequency, and you control both quality and cost at the same time. A research agent that reads three named sources once a week is cheap and reliable. One that crawls the open web on every page load is expensive and noisy. The two levers are the same lever.

On a pay-per-run model, the economics are easy to reason about. A weekly digest agent runs roughly four or five times a month, so its cost is the cost of those few runs, which lands in single-digit dollars for a typical scope. You are not paying for idle capacity between runs; you pay when it actually does the work. To make the cost ceiling concrete, set a spending limit so an unexpected loop or an unusually large source cannot run up a bill while you are not watching. Setting a spending limit is a five-minute step that removes the main reason people hesitate to leave an agent running.

Run frequency is the other dial. Daily is right for fast-moving topics; weekly suits most competitive and market research; monthly fits slow domains. Match the cadence to how fast the underlying information actually changes, and you avoid paying for runs that surface nothing new.

Building a research agent on Gravity

Gravity is an AI agent platform. You describe the research job in plain words and an expert-built agent runs it, so the "build" here is describing the outcome and its rules, not writing orchestration code or wiring a pipeline.

In practice you state the question, name the sources or upload the documents, set the output format, add the verify rule and any guardrails, and choose the schedule. From there the agent handles the gather, verify, and synthesize stages and hands back the finished result, typically in about 60 seconds per run. You review the output and act on it; you do not log into a stack of tools or maintain the connections yourself, because Gravity runs the agent and carries that work.

Pricing is pay per use: one dollar equals 1,000 credits, and you pay only when the agent runs. For a weekly digest that runs a handful of times a month, that is single-digit dollars, with no charge for the time it sits idle between runs. A research agent is a strong second or third agent to build, since the gather-verify-synthesize pattern transfers directly to other jobs. If this is your first one, setting up your first AI agent walks the basics, and once it works you can chain it into a larger workflow or chain multiple agents so research feeds directly into a decision or a draft.

FAQ

What is a research agent in AI?

A research agent gathers information from defined sources, verifies it, and produces a cited summary. Unlike a chatbot answering from memory, it shows where each claim came from, which is what makes its output something you can act on. The defining feature is the verify step: a research agent can show its work.

How do I make a research agent verify its sources?

Build in an explicit step that requires a source link or citation for every claim, and instruct the agent to flag anything it cannot confirm rather than guessing. Verification is the step that turns a plain summarizer into a research agent. State it as a hard rule in the outcome you describe, not an afterthought.

Do I need to code to build a research agent?

No. On a describe-outcome platform you state the research outcome in plain words: the question, the sources, the format, and the schedule, and the agent runs it. The gather, verify, synthesize pattern is the same whether you build it with no code or in a developer framework, so the structure transfers either way.

How much does it cost to run a research agent?

On a pay-per-run model, a recurring research agent runs a handful of times a month and typically costs single-digit dollars. On Gravity, pricing is one dollar for 1,000 credits and you pay only when the agent runs. Cost scales with how broad your sources are and how often it runs, both of which you control.

Can a research agent be wrong?

Yes, which is why verification and a human review step matter. Test the agent on a topic you already know cold, require citations for every claim, and review the output before acting on anything that carries weight. An agent that says when it is unsure is far safer than one that fills gaps with confident guesses.