AI for Data Collection and Literature Review

Today

• You take the same directed-agent workflow past data analysis, into collecting data and finding literature.
• This is where a made-up fact causes the most harm, so checking the source matters even more.
• The plan for the session:
  • what the agent can reach
  • collecting data
  • finding literature
  • break
  • discussion

What it can and cannot touch

• The agent works only with what it can reach:
  • your files and your code: always
  • the open web: often
  • library databases, your Zotero, and journal APIs: only once you connect them
• There are two ways to reach an outside app. You connect it once with MCP, or you let the agent operate it by clicking, which is called computer use.

Connecting to other apps (MCP)

• To reach an outside app, you connect it once, and then the agent can use it.
• MCP is the standard way to make that connection, and one setup works across services like Zotero, OpenAlex, and GitHub.
• You set a connection up once, and it keeps working after that.
• Today you just watch one in a demo.

Computer use: the agent clicks like a person

• Some sources have no API and no connector, and the only way in is to click through a website.
• A computer-use agent takes a screenshot, moves the mouse, types, and clicks, the way you would.
• Codex now has this built in, so it can drive a browser and control your desktop apps.
• Claude Code does not have it yet, and Anthropic's version is a separate Chrome extension.

When computer use is worth it

• The case for it is a government or survey portal with no API, where you must set filters and download a file by hand.
• You describe the goal, and it clicks through the portal and pulls the file.
• Use it only when an API or a script cannot do the job.

Its limits are real

• It is slow, because it works one screenshot at a time.
• It is unreliable on long click-throughs, and it spends your usage fast.
• Text on a page can fool it into following instructions, so you never point it at anything sensitive.

The two services we use

• We use two services for literature work:
  • OpenAlex. A free, open index of more than 250 million scholarly works you can search by topic, citation, or metadata.
  • Zotero. Your own library, which the agent can read once you connect it.
• The flow is simple. You find papers by topic, filter them, follow their citations, export the ones you keep to Zotero, and then the agent reads your library while you write.

The agent can also collect data

• The same reach that finds papers can also bring in data.
• Three common sources, and the agent handles all three:
  • a web page with a table you want, such as a state agency's statistics page
  • an API that returns data, such as the Census or a city open-data portal
  • a file to download and unpack, such as a CSV inside a ZIP
• You still make the calls: which source, which variables, and how much.

Collection is the hard part, so check it

• Gathering data is where these agents are weakest.
• On a social-science replication benchmark, agents scored about 96 at running an analysis and about 31 at finding the data it needed.
• Expect broken scrapes and wrong fields, and check every pull against the source.

Source: Nguyen et al., "ReplicatorBench" (2026), arXiv:2602.11354.

Example: pulling from an API

• You say what you want in plain words: "Get county population from the Census API for my state, 2010 to 2020, as a CSV."
• The agent writes the request, runs it, and shows you the first rows.
• If the API needs a free key, you paste yours in once and it uses it from then on.
• You read the columns and confirm they are the ones you asked for.

Example: scraping a table from a page

• You point it at the page: "From this URL, pull the table of unemployment by month into a CSV."
• The agent reads the page, finds the table, and saves it.
• Watch for the traps it should flag: a table split across pages, footnotes mixed into cells, or a site that asks you not to scrape.
• When a site's terms forbid scraping, you stop and find another source.

Keep the raw pull, and log where it came from

• Save the raw result once, before any cleaning, and never overwrite that copy.
• Have the agent write the source, the date, and the exact query next to the file.
• Months later, that note is how you answer "where did this number come from."

Check what came back

• Open the raw file and read the first few rows yourself.
• Compare a handful of values against the source page or the API by hand.
• Move the data into your analysis only after it matches.

When you will do it again, make it a Skill

• A pull you repeat, such as grabbing this month's new records, is worth packaging.
• Turn the steps into a Skill, the same way you did on Wednesday, so next time is one command.
• The Skill travels too, so a labmate can run the same pull with their own key.

Subagents, in one slide

• A subagent is a delegated worker. It gets its own separate context window, does one assigned task, and returns a short report.
• The main conversation receives only the report, and the full text of each paper stays in the subagent's own context.
• Five papers read in parallel are five separate context windows, plus yours, which stays clean.
• You invoke them in plain language. Asking for the work "in parallel, using separate subagents" is enough, and there is nothing to configure.

The contract each subagent needs

• Tuesday's lesson returns at team scale. "Read these papers and take notes" leaves every subagent to invent its own note format.
• Anthropic's report on its multi-agent research system (2025) found that without clear instructions, subagents "misinterpreted the task or performed the exact same searches as other agents."
• A workable delegation names three things:
  • Objective. What each note is for: feeding the comparison.
  • Output format. The five named fields, in a named file.
  • Boundary. One paper each, and no agent touches another's file.
• The demo prompt is long because it is a contract, and each clause closes one of these failures.

What parallelizes, and what it costs

• Independent pieces parallelize, and steps that share state or feed each other do not.
• The cost. Anthropic measures multi-agent runs at roughly 15 times the tokens of a single chat interaction. Parallelism buys speed and a clean context, and it bills accordingly.
• Tomorrow's build day can reuse the pattern for robustness checks: one subagent per specification, each returning one coefficient row for a single comparison table.

Choose your task

• Choose the task you actually need this month:
  • (a) Point the agent at a folder of PDFs, and get a structured annotated bibliography in notes/.
  • (b) Triage recent papers against your research question: relevant, maybe, no.
  • (c) Build a reading list on a topic, with verified metadata.
• Whichever you choose, the output lands in your repository, in notes/.

The hard rule

• Add one line to your AGENTS.md before you start:

• What checking means, concretely:
  • the DOI resolves
  • title, authors, year, and venue match the actual paper
  • the claim you cite it for is actually in the paper
• The agent can do the first two checks for you, and the third one is yours.

Where are the lines?

• Where is AI help with writing legitimate in your field?
• Drafting and thinking: which parts must stay yours?
• What do authorship and acknowledgment conventions expect?
• What do your target journals require you to disclose today?

Tomorrow

• The final session is a build day: 100 minutes on one small website or app from your own project.
• Think tonight about which one you want: a webpage of your results, one command that reruns everything, a small tool, or a smarter agent.