Context7 and the Council: How I Ground AI Agents in Current Docs

The model isn’t the problem. The context is two years stale.

The agent is confident and fast, and it writes code against an API that shipped two years ago. The function was renamed, the config moved, the recommended pattern changed. The output looks right and fails in review. People conclude the model “isn’t good enough yet.” Usually the model is fine.

I fixed most of this in my own setup with two cheap moves, and the second one is the interesting part.

Move one: fetch current docs before planning, not after failing

There is a class of tool now, served over the Model Context Protocol, whose only job is to hand the model up-to-date documentation for a named library. I wired in Context7. Before the agent commits to an approach for an Astro page or a Supabase policy, it pulls the current docs for exactly those libraries and grounds the plan in them.

The payoff was immediate and concrete. The first real query pulled Astro’s current content-collections setup, the src/content.config.ts file with a glob() loader. My agent’s training-era memory would have written the older src/content/config.ts shape and produced a plausible, broken plan. One fetch, one avoided rewrite.

Privacy matters here for anyone with a sensitive codebase: only the library name and the topic leave the machine, never your code.

Move two: turn the experts into a panel, not a footnote

Fetching docs is table stakes. The leverage comes from who reads them.

I built what I call a council. It is a plain table of personas, each one a review lens with a mandate: an Astro Architect, a Database Counsel, a Payments Counsel, a Security Counsel, and so on. Each persona is pinned to the specific library docs it cares about, resolved once and cached so there is no lookup tax at planning time.

When I plan a substantive task, the relevant counsels get convened. In a normal session that is inline: the agent reads each lens, pulls that counsel’s current docs, and folds the guidance into the plan. Under Claude Code’s heavier “ultracode” mode it runs as a real multi-agent workflow, one agent per counsel, each grounded in its own docs, each critiquing the draft plan from its single angle. A final pass synthesizes their findings into concrete plan changes.

This is the same idea good engineering orgs already use. You do not ask one senior to sign off on a design; you put the database person, the security person, and the domain owner in the room, each looking for the failure mode they are trained to see. The council is that review, run before any code exists, with each reviewer holding the current manual.

What the build itself taught me

Two things surfaced that no amount of upfront research would have caught.

First, the docs tool was not named what the plan said it was. My research said the call would be get-library-docs. The installed version exposed query-docs. I only found out by running it after a restart. The lesson is old and keeps being true: verify the integration against the running system, not the write-up.

Second, the agent could not widen its own permissions. When it tried to add the new tool to its own allowlist, the guardrail refused and asked for me. That is the correct behavior, and it is worth knowing before you design any agent workflow that assumes self-configuration.

Why this matters if you are adopting AI agents

The discourse treats agent reliability as a model-quality problem you wait out. In practice a large share of it is a context-engineering problem you can solve now: ground the agent in current facts, and structure its review so more than one lens sees the plan before code is written. That is governance you can build this quarter, not a capability you wait for.

Rolling agents out across a team? I share the council table structure free. Worth a look before you design the workflow.