Run agents · Your App Cloud
Build an AI research agent
Give an agent one question and the sources you choose. Have it draft a brief that cites a passage for each finding, marks its inferences, and lists open questions.
Built around a purpose
One question, a closed set of sources, a brief you can trace.
For people who must answer one question from a pile of material and hand the answer to someone who decides. That might be an analyst writing a board paper, a grant writer checking the evidence for a proposal, or a program lead comparing reports before a vote.
For illustration: a food bank in Fresno, California is asking whether to add a weekday evening distribution, and its board votes next month. The collection holds 12 months of visit counts by day, a volunteer availability survey, two published studies on food insecurity among shift workers, the county bus timetable, notes from three partner-agency meetings and the warehouse lease.
A four-part brief for the board: an answer with each sentence labeled as source or inference, the passages behind it, the points where the survey and the meeting notes disagree, and the questions no source answered, such as how many Saturday visitors would switch to an evening slot.
This agent needs Pro. It runs a language model inside the app and keeps sources, findings and briefs as stored records, which are backend capabilities. Free publishes frontend-only static apps. Model and service usage is metered separately.
Pin down the question and the decision
Write the question the way the person deciding will read it, and note the decision and its date. Then list what the answer must cover, such as demand, volunteers, building hours and transit for a new evening distribution, and what is out of scope.
Label each source as you add it
Add the files to the collection and give each one a label, a date and an origin, such as "Partner meeting, June, unreviewed notes". Describe in Studio that the agent may use only this set, and that anything else it needs goes on the list of open questions.
Pull findings with page references
Ask for a findings table before any prose. Each row holds one statement, the source label, the page or section, and a short quote. The lease clause on building access hours, for example, should appear as one row, quoted as written.
Draft the brief in four parts
Have the agent write the answer, the evidence, where sources disagree, and what is still open. Ask for a label on every sentence of the answer: source, with its finding, or inference, with the findings it combines. If the volunteer survey and a partner's notes disagree on who could staff evenings, the brief should show both.
Trace, correct and save the brief
Read the brief against the findings table, fix or delete anything that does not hold, and add your review note. Save it with its source list as a dated record, so next quarter's rerun sits beside it instead of replacing it.
Scope the first version
What a first version includes.
Question record
The question, the decision it informs, who decides, the date the brief is due, and a short list of what is in and out of scope.
Source list
One record per source with its label, origin, date, the period it covers, and a trust note such as published study, internal count or unreviewed notes.
Findings table
One row per statement taken from a source, with the page or section and a short quote. Filter it by source to see what each one contributed.
Source or inference labels
A label on each sentence of the answer. An inference lists the findings it combines, so a reader can test the reasoning as well as the citations.
Disagreements and open questions
Where two sources point different ways, both positions with their passages. Below them, every point the question needs that no source covers.
Saved briefs
Each brief kept as a dated record with the sources it used and your review note. On Pro you can also run the question on a schedule you set, such as the week before each board meeting, and review every new brief before it circulates.
Test it in the preview
Before you share it.
- Pick five statements from the brief at random and open the passage each one cites. The passage should support the statement as written, including qualifiers such as "in the pilot year" or "weekday routes only".
- Read every sentence labeled inference and confirm it names the findings it rests on. A claim with no label and no finding behind it is a defect: fix the instructions in Studio and run the question again.
- Take the volunteer survey out of the collection and rerun. The brief should list volunteer availability as an open question, not estimate it.
- Compare the brief's source list with what you added. Every cited source should be one you supplied. A citation to a report you never added means the brief can't be used as it stands.
- Add a source that contradicts one already in the set, such as an updated bus timetable with a later last departure. The brief should report both versions with their dates rather than pick one without saying so.
- Sign in to the app as someone who isn't preparing the brief, such as a board member, and confirm the partner meeting notes and the findings table stay closed to you.
Together in your app cloud
The pieces behind the possibility.
Choose the models and services that support the experience you want to create.
Language models
Reason, write, and understand
File storage
A home for your documents and media
Database
Keep data and context for apps and agents
Authentication
Give the right people access
Shape the details
Make it work for your world.
- Show each finding's source date and trust note beside it. A two-year-old published study and last month's unreviewed meeting notes can both be right, about different times, and the person deciding should see which kind of source each part of the answer rests on.
- When a finding depends on a number from a table, such as the share of visits on each weekday, open the original page before it goes into the answer. A misread column can flip a conclusion that a misread sentence would only blur.
- Partner meeting notes can name individual clients. Keep them in a collection of their own, limited to the people preparing the brief through the access you describe for each collection (Pro). Ask for findings that quote the notes without names, and spot-check a few before the brief circulates.
A little more context
Good questions.
Can it look up sources on the web?
Assume it doesn't. This guide works from a closed set you add yourself, and that closed set is what lets you trace every statement. When the brief needs something the set lacks, it should appear as an open question. Find that material yourself, check it, and add it with its date and origin.
What can it read?
It works from the text of the sources you add to the collection, such as reports, studies, survey summaries, meeting notes and a lease. Before you rely on a brief, open two or three sources in the preview and compare the imported text with the original, tables and figure captions included. Anything that did not come through is a gap to fix or to list in the brief.
How do I check a brief?
Ask someone who didn't set up the question to review it. They read the answer first, trace a sample of sentences through the findings table to their passages, and read the disagreements before accepting the conclusion. Rerun the checks above whenever you change the agent's instructions. To sort hundreds of comments into themes instead, see the feedback guide linked below.
When is a knowledge base the better fit?
When many people ask recurring questions of the same documents, such as a handbook. A research agent takes one question and a collection gathered for it, and produces a brief that someone acts on. If your sources are receipts or forms whose details you want as records, the document organizer guide below fits better.
Explore Pricing for plans, included capabilities, and usage details.
Keep exploring.
Your ideas, up and running
Your next idea has a home.
Build an app. Run an agent. Make it yours.
Start building