The Researcher Agent — External Facts Before Internal Decisions
How Datarim's Researcher agent pulls current library versions, breaking changes, and best practices from the outside world and delivers a structured insights document before implementation begins.
AI assistants have a training cutoff. When a plan says "use library X", it does not know whether the version it remembers is still current, whether a breaking change shipped last month, or whether a security advisory was published last week. The Researcher agent fills that gap.
The Researcher is a Research Analyst that runs during /dr-prd — to inform the requirements — and again during /dr-do when a specific gap surfaces mid-implementation. Its job is external context: what the world outside the codebase currently looks like for the technology a task depends on.
What it does
For each task, the Researcher checks library and framework versions and any breaking changes since the last known-good state. It pulls best practices and architectural patterns from current documentation rather than training data. It checks security advisories — CVE databases, package-manager audit outputs, GitHub advisories — for dependencies the task touches. It also looks at the existing codebase for components that could be reused instead of built from scratch.
All findings land in a structured document — INSIGHTS-{task-id}.md — with summaries and links rather than full documentation dumps. Anything based on training data alone gets flagged as unverified. The planner and implementer read this document before making decisions.
One concrete example
A task plans to add PDF generation using a specific Node.js library. The Researcher queries the library's current documentation, finds that the version in the plan's dependencies has a known memory leak fixed two releases later, and notes a breaking API change in the constructor signature. It adds a CVE reference for a transitive dependency that packages an older version of a PDF renderer. The insights document flags all three, and the Planner adjusts the implementation plan before any code is written.
Where it sits
The Researcher uses context7 as its primary tool for library documentation — it is more token-efficient than raw web search. For anything context7 does not cover, it falls back to WebSearch and WebFetch. It works with whatever tools are available and does not hard-depend on any specific MCP server being present.
When spawned mid-task from /dr-do for a specific gap, it investigates only that gap — it does not re-run the full checklist. The output feeds back into the implementer's next step without restarting the pipeline. Full reference on the Researcher agent card, or read what Datarim is for the bigger picture.