You ask Antigravity for a Next.js 16 component, and back comes code with next/router — an API that was retired versions ago. Or React 19 server components mysteriously sprouting useEffect blocks. Over the last month this has been my single most common "almost-but-not-quite" moment with the agent.
The reason isn't mysterious. AI models have a training cutoff; libraries keep shipping. Antigravity has built-in web fetching and document tools, but unless you nudge the agent toward fresh sources, it will quietly default to whatever it remembers from training. In this article I want to walk through the three mechanisms I actually use day to day to keep the agent honest about library versions. Not a grand framework — just things you can drop in tomorrow.
A quick reframe: it's not "doesn't know," it's "doesn't recall"
Before getting to the techniques, one observation that changed how I think about this.
The Gemini family inside Antigravity, and Claude when you bridge it in, usually did see fairly recent documentation during training. The trouble is that once a few outdated snippets land in the conversation, the model anchors on them. The problem is less "the model doesn't know" and more "the conversation never gave it a reason to recall." Reframed that way, the fix becomes obvious: drop a fresh source into the conversation so the model has no choice but to lean on it.
Mechanism 1: Pipe in versioned official docs through Context7 MCP
The first piece I reach for is Context7 MCP, maintained by Upstash. Hand it library@version and it returns the matching slice of official documentation through MCP, ready for the model to consume.
Here is how it sits in my Antigravity mcp.json:
// ~/.antigravity/mcp.json
{
"mcpServers": {
"context7": {
"command": "npx",
"args": ["-y", "@upstash/context7-mcp"],
"env": {}
}
}
}Once it's wired up, you just add a phrase like use library docs for nextjs@16 to your prompt. Context7 pulls the relevant docs in the background, and the model treats them as part of the conversation. I like that it doesn't break my flow — no separate browser tab, no copying snippets back and forth.
A real exchange from earlier this week:
You: Write the smallest possible example of reading a cookie on the server with the Next.js 16 App Router. use library docs for nextjs@16
Agent: (Context7 pulls the v16 cookies() reference)
→ Returns code using the stabilized async cookies() shape from 16.x
For deeper setup, including how to send several libraries at once, I wrote up the full configuration at Hooking Antigravity to Context7 MCP for Always-Fresh Library Docs.
Two things to watch
- Not every library is indexed by Context7. Smaller packages may not be available
- If you skip the version, Context7 picks what it considers "latest." That's not always what you mean — I always pin
library@versionto keep things deterministic
Mechanism 2: Hand the agent the official URL directly
When Context7 doesn't cover what I need, my fallback is almost embarrassingly simple: paste the documentation URL straight into the prompt. Antigravity's agent recognizes URLs and will fetch them with its built-in browsing tool right there in the turn.
Read https://nextjs.org/docs/app/api-reference/functions/cookies and update src/lib/auth.ts to follow the v16 async API.
That single line is enough to make the agent fetch the page, and then refactor the file to match. The trick is to be specific about the goal before the URL. If you only say "read this," you tend to get a long-winded summary back. State what you want changed first, then paste the link.
I lean on this whenever I'm writing release notes or update posts for one of my apps. For example, when iOS 26 dropped, I would paste Apple Developer's "What's New in iOS 26" page and ask the agent to summarize it in plain language. Faster than trawling through it myself.
Pitfall: keep it to one or two URLs
In practice, dropping five or more URLs into the same prompt scatters the agent's attention. Bound the scope too — "focus on chapter 3 of this page" — and the answers stay sharp.
Mechanism 3: Pin the project's current state in AGENTS.md
The third lever is the quietest but most effective: put a short AGENTS.md at the project root that spells out the dependency versions and the APIs you do not want used.
# AGENTS.md
## This project's environment
- Next.js: 16.0.x (App Router only — no Pages Router)
- React: 19.0.x (Server Components by default; minimal `use client`)
- Tailwind: v4 line
- TypeScript: 5.6 or higher
## Do not use
- `next/router` (removed in v16)
- `fetch` inside `useEffect` (do it in Server Components instead)
- `getServerSideProps` / `getStaticProps` (replace with App Router equivalents)
## Code generation rules
- Use the `@/` import prefix
- End every file with one trailing blank line
- Top-level await is allowed in async modulesAntigravity reads this file automatically at the start of every conversation. The practical payoff is that you stop having to type "use Next.js 16, please" every single session. I treat AGENTS.md as the project's CV — the first thing I update when I bump a major version.
For the writing details, the existing AGENTS.md guide for project-specific Antigravity context and the more advanced Mastering custom rules and project config in Antigravity work well as a pair. Read them together if you want to see how AGENTS.md and rules complement each other.
How I actually combine them — my current default
These three pieces aren't alternatives to each other; they play different roles. My default split looks like this:
- Routine feature work:
AGENTS.md(Mechanism 3) is enough on its own - Adopting a new library: I pull docs through Context7 MCP (Mechanism 1) before writing anything
- Surviving a major version bump: I paste the release notes URL directly (Mechanism 2) and let the agent diff against my code
- Investigating an obscure error: a search-engine URL plus the exact stack trace tends to outperform either MCP or
AGENTS.mdalone
Because Mechanism 3 quietly does the heavy lifting, I reach for the other two less often than you might expect. Conversely, projects that don't have an AGENTS.md force the model to guess from scratch every time, and the rate at which it falls back to old APIs noticeably climbs.
A small habit that pays off
When I'm in the middle of a long session and start to feel the agent drifting toward older patterns, I do one of two things. Either I open AGENTS.md and add a single line that captures whatever it just got wrong (so the same drift doesn't repeat tomorrow), or I paste the relevant doc URL once mid-conversation to re-anchor the context. Both take less than thirty seconds and usually rescue the rest of the session. The cost of not doing it is rewriting the same code two or three times, which is the slow leak that erodes the productivity gains of an AI IDE in the first place.
What changes once these are in place
If you put even a minimal version of all three in place — a five-line AGENTS.md, Context7 in your mcp.json, and the habit of pasting URLs — the texture of your sessions changes in a few ways worth naming:
- The agent stops volunteering deprecated imports unprompted
- You spend less time saying "use the v16 way" because the project itself is saying it
- When you do hit a genuine knowledge gap, you have a clear next move (paste the URL) rather than a vague feeling that the agent is stale
None of this requires deep configuration. The combined setup time is under fifteen minutes, and most of that is opening the right page on each library's documentation site
One thing to do today
Thanks for reading this far. You don't need all three pieces at once. The highest-return investment, by a clear margin, is just writing an AGENTS.md.
Open a project, drop an AGENTS.md at the root, and copy five or six lines from your package.json dependencies listing the major libraries and their versions. That single change measurably reduces the chance the agent quietly retreats to an older API tomorrow. Context7 and URL pasting can join the workflow later, when a specific situation calls for them.