Jiachi Liu from the Next.js team published a post on building Next.js for an agentic future on February 12, 2026. The post covers a year of work and one cancelled product. Its conclusion fits in a sentence: coding agents fail on Next.js apps because they can't see what the app is doing, so the framework has to show them.
The problem: agents can't see the browser
The team watched developers hit an error in the browser, copy the details, paste them into Cursor or Claude Code and ask for a fix. Often they skipped the copy step and typed "fix the error." The agent then fetched the page HTML and found nothing wrong.
The HTML can't show runtime exceptions, browser console errors, failed async work, which layout segments rendered or which routes exist. A human sees those in the overlay. An agent working from a terminal sees none of them.
The first fixes were small. The overlay's copy button started capturing structured error data, and Next.js began forwarding browser logs to the terminal. In 16.2 that forwarding became the default.
Vector: the agent they shut down
Next the team tried an agent inside the framework. Vector was an in-browser chat, similar to react-grab: you clicked an element, saw its source and asked for a change. It carried Next.js best practices to keep the model from making things up.
It worked, and the team shut it down anyway. Developers already used general agents such as Cursor and Claude Code on all their projects, and Vector only covered Next.js. Pointing at an element was handy, but people didn't need it daily. The team kept two ideas from Vector, structured visibility and framework knowledge, and built them into Next.js itself.
That decision is worth copying. If your team builds an internal AI tool that duplicates what a general agent does, ask what it knows that the general agent doesn't, and expose that instead.
MCP: the dev server answers questions
Around the Next.js 16 release in October 2025, the team added an MCP endpoint to the dev server at /_next/mcp. It exposes errors, routes, rendered segments and logs. The companion next-devtools-mcp package finds running dev servers and talks to them.
claude mcp add next-devtools npx next-devtools-mcp@latest
| Tool | What it does |
|---|---|
| nextjs_index | Scans common ports for Next.js 16+ dev servers and lists their tools |
| nextjs_call | Calls one runtime tool, such as errors, routes or logs |
| nextjs_docs | Points the agent to the docs in node_modules/next/dist/docs/ |
| browser_eval | Checks for the agent-browser CLI and returns setup steps |
The endpoint is on by default in Next.js 16, so the agent needs no config in your app. The package also ships prompts for upgrades and Cache Components migrations.
Three needs, three features
The post's main lesson is to treat agents as users and ask what they need, when, and in what format. The team's answers map to features:
- Visibility. Agents read the terminal, so Next.js logs Server Action calls and forwards browser errors there.
- Knowledge. Agents don't know APIs newer than their training data, so Next.js ships a compressed docs index in
AGENTS.mdand structured workflows as Next.js skills. - Discovery. Agents need to find the running app, so the dev server exposes MCP.
Vercel measured the knowledge piece. In its evals, bundled docs through AGENTS.md reached a 100% pass rate, while skill-based retrieval peaked at 79%. The team's explanation: agents often fail to notice when they should search. Context that sits in the prompt from the start beats context they have to ask for.
People need the same things
Each of those features helps a new hire as much as an agent. Logs in the terminal, routes you can list and docs that match your installed version are good debugging infrastructure. The agent framing gave the team a reason to build it.
You can apply the same test to your own repo. An agent, like a new teammate, reads what you leave lying around:
<!-- AGENTS.md -->
- Run `bun run dev`. The app serves on localhost:3000.
- Posts live in src/content/blog/*.mdx. The loader in src/lib/content/blog.ts validates frontmatter.
- Run `bun run build` before you open a PR. It also rebuilds the search index.
Three lines like these save the agent a dozen failed guesses, and they save your next hire an afternoon.
What the team plans next
The team wants next dev to provide this context with no setup. Until then, npx @next/codemod generates the docs index for an existing project, and the team keeps expanding its evals to more Next.js 16 APIs.
This week
- Add
next-devtools-mcpto your agent and ask it to list the routes of your running app. - Run
npx @next/codemod@latest agents-md, or on 16.2 and later, addAGENTS.mdby hand. - Write the three facts a newcomer asks about first into that file.
- Before you ask an agent to fix an error, check that it can see the error.
Volodymyr Chornous