AI Agents for Knowledge Workers

Sean Davis

AI Agents for Knowledge Workers

What they are, how they work, and how to work well with them

Sean Davis, MD, PhD

2026-07-22

You already know the hard part

You use chatbots. You write prompts. You judge whether the answer is any good.

That intuition transfers directly. This session adds three things:

what changes when the AI can act in your files, not just chat
what is actually happening under the hood — context and tokens
a few habits that make these tools safer, cheaper, and sharper

Anchor to what they already do. Nearly everyone in the room uses ChatGPT/Claude/Gemini as a chat window. The goal today is not “learn to program” — it’s to understand a new interface and a handful of mental models. Stay tool-agnostic throughout: the concepts hold across every major tool, and the handout covers specific options.

PRESENTER KEYS — s speaker view · f fullscreen · o overview · g go-to-slide c draw on this slide · b blank board · x cycle ink colour · del clear slide backspace clear all · d download drawings · q laser pointer · ? all keys (Drawings live only in this browser session unless you press d.)

TIMING (50-60 min slot). The deck runs long if you show everything; that is deliberate, so you can pick per audience. Planned shape: Parts 1-3 + demo ……… ~35 min (demo ~10 of it) Part 4 (extensions) …… ~8 min Where this is going …… ~7 min Wrap-up + Q&A ………… ~10 min

If you are behind after the demo, cut in this order: 1. “Model vs. agent” (Part 1) — nice-to-have, not load-bearing 2. “Shell and tools” (Part 4) — this audience already knows it; the overview figure covers it 3. “Multi-agent systems” (co-scientist / Virtual Lab) — keep Biomni and the two cancer papers, which are closer to home 4. “What a good session looks like” — it restates the takeaways slide Never cut: the demo punchline (check a row), privacy/PHI, or takeaways.

Part 1 — From chatbot to agent

Two ways to use the same model

Your work is file-shaped

So much of research life lives in files:

manuscripts, grant applications, protocols, reviews
folders of PDFs — papers, applicant CVs, reports
sample sheets, metadata tables, marker-gene lists, data dictionaries
analysis scripts and notebooks; slide decks and meeting notes

A chatbot reasons about a snippet you paste. An agent reasons about the documents as they actually are.

“Take this list of 40 DOIs, fetch the open-access PDFs, extract the platform and cell counts from each, and flag the two whose methods disagree with their abstracts.”

What agents do for knowledge work

This is the center of the talk. Walk each card slowly — each one is a real prompt pattern:

Deep research: “Search PubMed for recent work on CAF subtypes in pancreatic cancer; read the top sources and write a one-page synthesis with citations, noting where they disagree.”
PDF extraction: “These 40 postdoc applicant CVs are PDFs — extract degree, methods experience, and first-author papers, score against rubric.md, and give me a ranked CSV.” (Same loop as the paper demo, different folder.)
Slides: “Turn outline.md into a 12-slide deck with speaker notes” — exactly how this deck was built.
Document editing: “Tighten this Aims page, flag claims needing citations, and list inconsistencies with the project summary.”
Brainstorming: “Given these three papers and my draft, propose follow-up experiments and push back on my weakest framing.”

The thread: give it the real material, not a description of the material.

The right mental model

A capable, fast, tireless trainee — not an oracle.

reads quickly, drafts well, follows instructions, never gets bored
also: makes mistakes, needs clear direction, benefits from supervision

You are the attending. You sign the note.

from doing every task → delegating with clear instructions
from remembering context → providing context explicitly
from working alone → reviewing output before it counts

Model vs. agent — one quick distinction

The model (the LLM) is the reasoning engine: reads, plans, writes.
The agent is the layer around it: tools, memory, permissions, a loop.

Different products are mostly different agent layers over similar models. Learn the concepts once; the skills transfer across tools.

Live demo — let’s watch one work

The task I actually had

I needed ten papers on one topic — real, open access, and downloadable — to demo on.

By hand that is an afternoon: search, skim, check each licence, download, give up around paper six, and end with a folder nobody else can reuse.

So the preparation for this demo was the demo:

Ask a literature database for candidates
Keep only the ones that actually download
Curate for a real disagreement
Save the list, not the PDFs

This slide exists because the demo otherwise looks like it started from a tidy CSV that fell from the sky. It didn’t — and the messy part is the part worth teaching.

Step 2 is the one to lean on. “Open access” in a database record does not mean “I can fetch it”: four publishers in my candidate set (AACR, BMJ, Wiley, Science) return 403 to a scripted request. The agent found that by trying every link and reporting the failures — exactly the verification habit from the mental-model slide.

Step 3 was mine, not the agent’s: I chose papers that disagree with each other so the synthesis step has something real to find. Say that out loud — the agent fetched and checked; deciding what makes a good teaching set was a human judgment.

Step 4 is why the repo holds a 3 KB list instead of 114 MB of PDFs.

Where the candidates came from

semanticscholar.org — free, ~200M papers. Beyond title and abstract, every record carries the DOI and says whether an open-access PDF exists, where it is, and under which licence.

This page is laid out for human eyes. Your agent would rather have the same search as data.

Every search is also an API call

A website is built for eyes. An API is the same data served for programs — you send a query, you get back records with labelled fields.

{ "title": "Tumor microenvironment remodeling
            after neoadjuvant immunotherapy…",
  "year":  2023,
  "venue": "Genome Medicine",
  "externalIds": {
      "DOI": "10.1186/s13073-023-01164-9" },
  "isOpenAccess": true,
  "openAccessPdf": {
      "url":     "https://genomemedicine…",
      "license": "CCBY" } }

No scraping, no copy-paste — and that record is row 1 of our CSV.

This is the slide for the half of the room who have never thought about an API. Keep the definition concrete: a website is for eyes, an API is the same thing for programs. Every field is labelled, so a program can use it without guessing.

Walk the four fields on the left, then point at them in the real response on the right: the DOI is the permanent identifier; isOpenAccess and license say whether we may take it; openAccessPdf.url is the actual file. Those four are the entire reason the demo works.

Say plainly that this response is real and lightly trimmed — the ellipses are mine, for the slide.

Practical, if asked: Semantic Scholar’s API is free and needs no key for light use; it rate-limits instead, which I hit while preparing this, and keys are free for heavier work. PubMed and Europe PMC have equivalent APIs, so the pattern generalises to whatever corpus you care about.

And the connection forward: this is the MCP idea from Part 4 arriving early. I never taught the agent what Semantic Scholar is — it had a tool for it, and the tool speaks this.

If someone asks “couldn’t I just ask a chatbot for ten papers?” — yes, and some of them would not exist. Going through a literature API is what makes every record a real one with a resolvable DOI.

What we start with: a reference list

papers.csv — 10 open-access single-cell papers on the tumor microenvironment and immunotherapy response.

doi	year	journal	short_name
10.1186/s13073-023-01164-9	2023	Genome Medicine	nsclc-neoadjuvant-ici
10.1038/s41590-022-01215-0	2022	Nature Immunology	gbm-immune-evolution
10.7150/thno.60540	2022	Theranostics	gastric-proinvasive-caf
…			(7 more)

No PDFs yet. Just DOIs — the way a reference list actually arrives.

Act 1 — “go get them”

“Read papers.csv. Download each open-access PDF into papers/, named by short_name. Then tell me which ones failed and why.”

Watch the loop: read the list → fetch → check it’s actually a PDF → report what broke.

Act 2 — “now read them”

“Read the PDFs in papers/. Build extraction.csv — cancer type, platform, number of cells, key finding, main limitation. Then write a one-page synthesis: where do these papers agree, and where do they disagree? Cite by DOI.”

Same loop, bigger job: plan → open a paper → extract → next → synthesize.

The punchline: check a row

Open extraction.csv. Pick one row. Open that PDF. Verify.

number of cells → is that the number in the paper, or the number in the abstract?
“main limitation” → the authors’, or the agent’s opinion?

You would do this to a trainee’s first draft. Do it here.

What you just saw

It went from a reference list to a synthesis without you touching a PDF
It planned, then worked one paper at a time — not one giant answer
Every step was visible and interruptible
The output landed in files you keep — a CSV and a document, not a chat bubble
And we checked a row before believing it — that’s the job now

Part 2 — What’s under the hood

The model reads tokens, not words

The context window is a budget

More context is not always better

“Lost in the middle”¹; degradation with input length is reported across frontier models.

Part 3 — Working well with an agent

A notes file as memory

One task per conversation

Small playbooks beat one giant file

Privacy, PHI, and trust

Consumer chat accounts are not for PHI. De-identify first, or don’t paste it.
Institutional deployments differ — a BAA-covered tool may be approved where a personal account is not. Ask; don’t assume.
Your IRB, compliance office, and data-use agreements outrank anything on these slides.
And for everything it produces: verify before it counts. You sign the note.

If the data truly cannot leave, run the model on your own hardware — the round trip never crosses your institution’s boundary.

Non-optional slide for this audience; better to answer before they ask. Keep it practical, not fearful: today’s demo used open-access papers precisely because that’s the safe pattern — public or de-identified material flows freely, and the sensitive-data question is an institutional one, not a slide-deck one. The trust half is the attending framing again: hallucination is real, citations must be spot-checked, and the professional signature never transfers.

THE LOCAL-MODEL ANSWER — expect this question, and it is a good one. You can run the model itself on your own hardware, so the text never leaves the machine at all. Ollama and LM Studio are the usual runners; both expose an OpenAI-compatible endpoint, which is the trick that makes them work with ordinary agent tools rather than needing special ones. opencode (opencode.ai) is a terminal agent that documents exactly this — point it at localhost and it drives a local model instead of a hosted one — and several other open-source agents take the same endpoint.

Four honest caveats to say in the same breath:

Local removes the transmission risk, not the governance one. PHI on your laptop is still PHI: institutional policy, disk encryption, device management, and IRB all still apply. Ask; don’t assume local means allowed.
Check the harness, not just the model. The tool wrapped around it may still send telemetry or crash reports somewhere.
Capability gap. Open-weight models are genuinely good at the extraction and summarising work in today’s demo; they are still behind frontier models on hard multi-step reasoning. Match the model to the task.
Hardware. A useful local model wants a real GPU or an Apple Silicon machine with a lot of RAM. It is free in licence, not in equipment.

The one-line version for the room: if the blocker is “our data cannot leave the building,” that is now a solvable engineering problem — talk to whoever runs your research computing, because they may already have this.

Part 4 — How an agent reaches further

Four ways to extend one agent

Shell and tools: it can just run things

You already know this layer — it’s your terminal.

samtools, bedtools, Rscript, grep, git
read a file, list a directory, fetch a URL

The novelty isn’t the commands. It’s that the agent writes them, runs them, reads the error, and tries again — the loop you do by hand.

Skills: give it your lab’s know-how

A skill is a folder with instructions — loaded only when relevant.

“how we screen abstracts for this review”
“our scRNA-seq QC thresholds, and why”
“the figure conventions for our papers”

Written once. Shared by the whole lab. Versioned like a protocol.

People are already sharing these — genomics skill collections exist today, and are young enough that yours could matter.

Connect back to the notes-file slide in Part 3 — same idea, modular. The framing that lands for scientists: a skill is a protocol for the agent. Your lab already writes protocols so a new student does the thing the same way twice; this is that, for a collaborator that happens to be software.

Verified as of July 2026, if asked for specifics (URLs are in the handout): - the SKILL.md convention itself is public (github.com/anthropics/skills) - GoekeLab/awesome-genomic-skills — a genomics lab’s curated index of bioinformatics skill collections, which is the best single starting point - google-deepmind/science-skills — genomics, structural biology, cheminformatics - mims-harvard/ToolUniverse — Zitnik lab, wires up ~1,000 biomedical tools

Honest framing for the room: this ecosystem is real and growing fast, but it is young — many overlapping 2026-vintage repos of uneven provenance, and some adoption claims that are marketing rather than measurement. That is an opportunity, not a warning: the conventions for how a lab packages its methods knowledge are being set right now.

MCP: plug it into other systems

Model Context Protocol — one standard connector, so a tool built once works in any agent.

literature: PubMed / NCBI Entrez
genomics resources and cohort portals
your own institutional systems

The agent stops being limited to what’s on your laptop.

Keep the protocol talk light — the point is the shape: instead of every AI product building its own PubMed integration, someone builds a PubMed MCP server once and every agent can use it.

Verified as of July 2026, if asked (URLs in the handout): - Anthropic ships a life-sciences connector set with PubMed, BioRender, Synapse, and 10x Genomics Cloud (github.com/anthropics/life-sciences) - BioMCP (github.com/genomoncology/biomcp) is the broadest community one — a single server covering PubMed/PubTator, ClinVar, MyVariant, gnomAD, CIViC, OncoKB, cBioPortal, and ClinicalTrials.gov. That list should get this room’s attention. - there is a community registry (biocontext.ai/registry) for browsing more

I deliberately keep specific repo names off the slide — anything named here is likely wrong within a year. Say instead: “look for a server for the resource you care about; if none exists, that is a very tractable project for a bioinformatics-capable lab, and the ecosystem is young enough to matter.”

Caveat worth stating out loud: an MCP server is code you are trusting with your session and your credentials. Prefer servers published by the organization that owns the resource, or read the source.

Subagents: delegate with a clean desk

A subagent is a fresh agent with its own context window and a narrow job.

one reader per paper — ten papers at once, no cross-contamination
a citation checker whose only job is: does this reference exist, and does it say what the sentence claims?
a skeptic asked to argue against your conclusion

Remember context rot? This is the structural fix: many small windows instead of one enormous one.

Where this is going

Agents built for biomedical research

Stanford · Science 2026²

~150 tools, ~60 databases, mined from the literature across 25 subdomains
Given a goal, it composes its own workflow — gene prioritization, drug repurposing, rare-disease diagnosis

Multi-agent systems that propose — and test

Google · Nature 2026³

Agents debate and rank hypotheses. It proposed KIRA6 for AML — a compound no human had pointed it at — and it killed leukemia cells in vitro at far lower doses than healthy cells.

Stanford + CZ Biohub · Nature 2025⁴

An LLM “PI” runs meetings with LLM scientists; 92 nanobodies designed, two validated at the bench.

AI Agents for Knowledge Workers

You already know the hard part

Part 1 — From chatbot to agent

Two ways to use the same model

Your work is file-shaped

What agents do for knowledge work

The right mental model

Model vs. agent — one quick distinction

Live demo — let’s watch one work

The task I actually had

Where the candidates came from

Every search is also an API call

What we start with: a reference list

Act 1 — “go get them”

Act 2 — “now read them”

The punchline: check a row

What you just saw

Part 2 — What’s under the hood

The model reads tokens, not words

The context window is a budget

More context is not always better

Part 3 — Working well with an agent

A notes file as memory

One task per conversation

Small playbooks beat one giant file

Privacy, PHI, and trust

Part 4 — How an agent reaches further

Four ways to extend one agent

Shell and tools: it can just run things

Skills: give it your lab’s know-how

MCP: plug it into other systems

Subagents: delegate with a clean desk

Where this is going

Agents built for biomedical research

Multi-agent systems that propose — and test

Closer to home: agents in cancer research