Skip to main content
In 2026, documentation officially scaled beyond human readers to become pure infrastructure, a shift highlighted in GitBook’s State of Docs report. Recent data from Mintlify shows that AI coding agents (driven largely by Cursor and Claude Code) now account for over 45% of all documentation traffic, effectively tying with traditional browsers, leading them to conclude that we are now serving two separate audiences at once. In response, companies are bridging this gap through four dominant strategies:
  1. Open in ChatGPT/Claude contextual menus: Redirecting users to third-party AI chat interfaces with pre-populated context.
  2. AI-enhanced search: Upgrading the standard search bar with AI-powered retrieval and generative summaries.
  3. MCP (Model Context Protocol) servers: Exposing docs as a structured data source that AI agents can query programmatically.
  4. Embedded AI assistants/chatbots: Adding a dedicated conversational interface within the docs.
Each approach reflects a different philosophy about who (or what) your docs are really for.

​
The Case for Each Approach

Option 1 is the path of least resistance with minimal maintenance and infrastructure overhead. Adding an Open in ChatGPT/Claude button to existing docs is quick, requires minimal infrastructure changes if you already serve Markdown, and gives users a familiar interface. Most modern documentation platforms already offer this. The tradeoff is that you’re essentially renting the intelligence layer from your tool vendor, which means limited control over quality and behavior. You typically can’t swap out the underlying model, force the AI to understand your industry-specific acronyms, or adjust the core retrieval logic if the results are poor. Option 2 is AI-enhanced search. Before jumping to full conversational bots, many organizations are simply upgrading their existing search bars. Tools like Inkeep and kapa.ai are replacing basic keyword matching with AI-powered retrieval, allowing users to search by intent rather than exact terminology. Some even provide an AI-generated summary at the top of the search results. This is effective because it intercepts users exactly where they are already looking for answers, requiring zero change in user behavior. Option 3, the MCP server approach, is architecturally elegant. It treats your docs as a structured knowledge base that any AI agent (like Claude, Copilot, or a custom internal bot) can query on demand. The problem? Discoverability. Your users need to know the MCP endpoint exists and how to configure their agent to use it. That’s a non-trivial ask for anyone who isn’t technical. This could work well if you actively advertise/promote your MCP server within your product as a way to get guidance right where users need them, without the overhead of context switching. Option 4 is where it gets interesting.

​
Why the Embedded AI Assistant Deserves More Credit

The embedded AI assistant is often dismissed as a gimmick, but there’s a real use case hiding in plain sight: the evaluating buyer. Think about who actually reads your documentation before a purchase decision. It’s rarely just developers. It’s product managers, procurement leads, and engineering managers who need to quickly answer one question: Can this product do what we need it to do? They’re not going to read your entire API reference. They want a conversational shortcut to capability discovery. An AI assistant that can answer Can we split a transaction across multiple merchants? or Do you support tokenizing cards for off-session payments? in plain language is enormously valuable at this stage of the buyer journey. It can reduce sales cycle friction, improve conversion from docs to trial, and make your product feel more trustworthy, all before a human ever gets on a demo call.

​
When Not to Add an AI Assistant

While it is tempting to add an Ask AI button to your docs, here is the thing nobody says loudly enough: a bad AI assistant is worse than no AI assistant. If your documentation has gaps, inconsistencies, outdated content, or poor structure, an AI assistant will faithfully hallucinate its way through all of them. What’s worse, your users will trust those answers. That’s a recipe for churn, failed implementations, and support tickets that erode confidence in your product. Before integrating any AI layer into your docs, ask yourself:
  • Are your docs consistently structured and up to date?
  • Do they cover edge cases and failure modes, not just happy paths?
  • Is your content tagged, categorized, or chunked in a way that’s retrieval-friendly?
  • Do you have a process to keep docs in sync with product changes?
If you answered no to most of these, the highest-leverage thing you can do isn’t picking an AI vendor. It’s hiring a technical writer. Get the foundation right first. AI amplifies what’s already there; it doesn’t fix what’s broken.

Your foundation matters. I can help build it.

If you’re building a team that takes documentation seriously, I’d love to be part of it. I’m actively looking for full-time technical writer positions at developer-focused companies.
The right approach depends on your docs maturity, your audience, and how central developer experience is to your growth strategy. However, the worst move is treating AI integration as a checkbox by bolting on a chatbot to docs that aren’t ready for it, just to say you have one. Interested in how I’ve used AI in real documentation projects? Explore my portfolio or get in touch.