Three ways teams manage product context for AI

A teardown of three setups we keep seeing: what each is good at, and where each one breaks down.

You've got your own AI setup dialed in. Then a new engineer joins, opens the same repo, fires off what looks like a reasonable prompt, and gets back something subtly wrong because their context isn't your context. That's the real problem. Not "which model is best." It’s whether the whole team is working off the same understanding of what your product actually means.

Teams are solving it in roughly three ways. None is wrong, but they fail in different places. Which failure you can live with is the actual decision.

Worth naming up front, because it shapes all three: The Pragmatic Engineer's 2026 survey of 900+ engineers found that AI amplifies whatever engineering culture is already in place. The teams that got real value had already written down their decisions and practices before any agent showed up. So the question underneath this teardown isn't which tool. It's where your AI gets its understanding of the product, and who’s responsible for keeping that understanding accurate.

Context lives in markdown checked into the repo: CLAUDE.md, .cursorrules, a /docs folder the agent reads. The AI picks it up natively, it's version-controlled next to the code, and an engineer can update it in the same PR that changes the thing it describes.

This shines when the team is small and the context is engineering context. No new tool, no adoption tax, and the guidance sits inches from the code it governs. For one or two repos and a handful of people, it's often genuinely enough. Anything heavier is probably over-engineering.

Where it strains: it rots, and keeping it from rotting is real work. Even teams that centralize their AI guidance into shared rules and instructions still need someone keeping those files aligned with a product that changes every week, and that someone keeps getting pulled onto other work. (The honest version of my own setup is a CLAUDE.md I last touched in March.) The Pragmatic Engineer survey surfaced the same pattern: upkeep lands on the shrinking handful of people who still understand the system and are responsible for maintaining it, while everyone else commits against context they never updated. And it's engineering context. What a product term actually means, or why a flow works the way it does, often lives with people who don't spend their days in the repo.

The wiki is where product knowledge lives: PRDs, decisions, glossaries, user journeys. You connect your AI tools to it through an MCP server or by pasting relevant content into a prompt.

This shines because it’s cross-functional. PMs, designers, and engineers already live in the wiki, so the "why" behind a decision is captured in human-readable form, with history attached. For the narrative side of product knowledge, a well-kept wiki is hard to beat, and most teams already have one running.

Where it strains: a wiki records what someone knew the last time they edited the page. Pages go stale, and a stale page is worse than a missing one, because the AI reads it with full confidence. The deeper issue is retrieval. Unlike a repo, the product knowledge is usually there. It's just buried inside documents written for people, not machines. A 2,000-word PRD may well contain the answer, but the agent still has to find the right passage, determine whether it’s the authoritative one, and interpret it correctly. The result often reads perfectly well while quietly missing the definition or rule that actually mattered. Pointing AI at the wiki gives you a snapshot of the prose, not a live answer to "what does this mean right now."

Product meaning lives as structured context: glossary entries, design decisions, business rules, and intent. It’s separate from both the repo and the wiki, and exposed to AI tools through a single MCP server. Instead of parsing prose for a definition, the agent reads the structured entry directly.

This shines when teams need their AI tools to work from the same definitions. When "Everything" is a real screen in your product and not just a common word, or when a rule like "only an admin can archive a workspace" matters, the structured layer gives every tool the same answer each time. Because it's structured and centrally owned, teams have a single place to manage product meaning instead of scattering it across personal files.

Where it strains: it's another system, and consistency doesn't happen automatically. The structure helps AI use product knowledge more reliably, but teams still need someone responsible for keeping that knowledge aligned with reality. If ownership is fuzzy, the layer can drift just like any other source of truth. The danger is that it looks authoritative even when it's wrong. And if your team is one repo and three people, it's more than you need. A CLAUDE.md will carry you until the terminology outgrows it. If you're not sure where that line is, there's a free tier up to 25 users so you can see whether you've outgrown the simpler approaches.

One more path worth naming.

Some larger organizations skip all three and build their own retrieval layer: a vector store and an internal MCP server wired into the systems they already run. It's the most powerful option if you can staff it, and it's the real alternative to something like Atono. A wiki solves a different problem. The tradeoff is that you now own the infrastructure and its upkeep. It’s the same ownership problem as everything above, just at a larger scale and on your headcount.

Be honest about where the team actually is right now:

• One or two repos, a few engineers, mostly engineering context → the CLAUDE.md approach. Don't add a tool for a problem you don't have yet.

• Doc-heavy and cross-functional, with a wiki that's already load-bearing → Notion gets you a long way. Watch the staleness – specifically, watch for the day AI starts confidently citing a page nobody's opened in six months.

• Multiple teams, multiple AI tools, and product terminology the agent keeps getting almost right → that’s where a structured layer starts to earn its keep. It’s the point where "just keep the markdown updated" stops scaling across people.

The through-line is that the tool matters less than whether the context under it stays current and owned by an actual person. So pick the lightest system where the answer to "what does this mean?" is the same everywhere it's asked. Move up a level the day it stops being true.