Documentation Agents: 1. Define the Strategy
In my page Docs-as-data, I introduced the approach that documentation should increasingly be considered as a source of knowledge for both humans and AI systems.
This changes the way we think about documentation.
Documentation is no longer only something users navigate, search, and read. It can also become a knowledge source that AI systems query, analyze, compare, summarize, and turn into new services.
Documentation agents fit naturally into this approach.
They can provide a new way to interact with documentation or a knowledge base: users can ask questions in natural language, retrieve information from several sources, obtain a consolidated answer, get step-by-step guidance, or receive support directly from documented knowledge.
Agents can also work in the opposite direction: they can help documentation teams analyze and improve the corpus itself by detecting duplicate content, terminology inconsistencies, outdated information, or other quality issues.
The objective is not to put AI everywhere, nor to delegate documentation entirely to AI.
It is to use AI where it can provide an additional and identifiable documentation service.
The starting question is therefore not: "Which AI tool or model should I use?"
It is:
As a documentation expert, what service do I want to provide to users from the knowledge already available?
This is the starting point for designing a documentation agent in a docs-as-data approach.
Documentation Agents Start with Documentation Problems
For several years, I have worked on large, heterogeneous, and distributed documentation ecosystems.
The tools and technical environments change, but many of the same issues repeatedly appear:
- difficult onboarding;
- large or inconsistent vocabularies;
- duplicated or overlapping content;
- information that is difficult to retrieve;
- content that is difficult to consolidate across several sources;
- recurring support questions;
- incomplete or ineffective FAQs;
- old or archived pages that still contain useful knowledge;
- documentation produced by different teams with different practices.
A recent mission gave me the opportunity to work on a Confluence knowledge base with exactly these characteristics: large, heterogeneous, collaborative, and covering several technical documentation sets.
This was not an isolated situation. I had previously worked with multi-format, multi-author, and multi-tool documentation ecosystems presenting similar problems.
The experience reinforced an idea I had already encountered repeatedly:
Recurring documentation problems can often be grouped into identifiable needs, and some of those needs can be supported or augmented by specialized agents.
The important point is that the agent comes after the problem has been identified.
An agent should not be created simply because the technology exists.
Strategy: Tailor the Agent to Needs and Usages
A useful documentation agent does not start with the choice of a model or a platform.
It starts with:
- a documented need;
- an audience;
- a knowledge domain;
- a service to provide;
- an expected benefit.
The agent also does not make the original documentation invisible or unnecessary.
Users should still be able to browse documentation, follow links, use navigation, search by keywords, and read complete procedures or conceptual explanations.
The agent provides an additional mode of interaction.
For example, instead of knowing which page to open or which exact keyword to search for, a user can ask a question in natural language and receive a response assembled from several relevant sources.
One of the agents I designed, the Documentation Intelligence Assistant, followed this type of RAG-like approach: it retrieved relevant information from a defined Confluence corpus before consolidating it into a structured, source-backed answer.
The distinction matters.
The value does not come only from generating an answer. It comes from grounding that answer in an identified knowledge base.
Designing a documentation agent is first a documentation strategy exercise.
In my case, this strategy eventually led to an ecosystem of four specialized agents working on a defined part of the Confluence knowledge base. They were designed to work independently and, potentially, to be coordinated through an orchestrator.
The work combined documentation architecture, documentation strategy, domain knowledge, understanding of the existing corpus, and knowledge of user needs.
One Knowledge Base, Several Documentation Services
A single knowledge base can support very different user needs.
Some of these services already exist through documentation itself: navigation, search, tutorials, conceptual pages, FAQs, troubleshooting guides, glossaries.
An agent can augment these services.
It can also create new ways of using the same documented knowledge.
| Documentation need 🠊 | 🠊 Agent service |
|---|---|
| Find information | Ask questions in natural language, retrieve from several sources, synthesize |
| Onboard and train users | Explain concepts, guide users, suggest relevant content or learning paths |
| Maintain content quality | Detect duplication, overlap, inconsistencies, or obsolete content |
| Normalize knowledge | Identify terminology variants, acronyms, synonyms, and naming inconsistencies |
| Improve support | Generate contextual answers, Q&A, procedures, troubleshooting steps, or escalation guidance |
| Improve product adoption | Make documentation easier to query, understand, and apply |
These services are not universal.
Every knowledge base has its own structure, history, audiences, ownership model, terminology, and documentation maturity.
There is therefore no standard documentation agent that can simply be copied from one organization to another.
The agent has to be tailored to the knowledge environment it will operate in.
From Services to Benefits
Defining what the agent does is only part of the exercise.
The next question is:
What does the user — and the organization — gain from this service?
A useful agent should create a measurable or at least observable benefit.
| Agent service 🠊 | 🠊 Expected benefit |
|---|---|
| Natural-language search | Less time spent looking for information |
| Multi-source synthesis | Faster understanding of complex or distributed knowledge |
| Guided onboarding | Faster learning and greater user autonomy |
| Duplicate and inconsistency detection | Easier maintenance and fewer conflicting sources |
| Terminology normalization | Better understanding across teams and audiences |
| Contextual support | Faster issue resolution and potentially fewer repetitive support requests |
| Source-backed answers | Greater confidence in the information returned |
| Interactive Q&A and procedures | Better access to knowledge at the moment of need |
These benefits take different forms depending on the audience.
-
For users, they mainly translate into faster access to knowledge, greater autonomy, easier navigation through complex terminology, and more confidence in the answers they receive.
-
For documentation teams, agents can expose weak areas in the corpus, reveal duplication or inconsistencies, identify recurring information gaps, and provide new inputs for continuous improvement.
-
For the organization, the broader benefit is better reuse of existing knowledge: faster onboarding, more efficient support, improved knowledge sharing and product adoption, and stronger use of documentation as a shared knowledge asset and potential source of truth.
This is where the value of agentic AI becomes particularly interesting for documentation.
The documentation is no longer only a passive collection of pages.
It becomes part of an active knowledge system that can answer, guide, analyze, and support.
Specialize Rather than Build one General-Purpose Agent
Instead of creating one general-purpose agent expected to handle every documentation need, I chose to split the requirements across several specialized agents.
Specialization helps to:
- give each agent a clear role;
- associate the agent with a specific usage;
- reduce unnecessary overlap;
- define more precise boundaries;
- control the amount and type of knowledge processed;
- make future orchestration easier.
Each agent was designed in response to a problem observed during the documentation audit.
This leads to an important principle:
The agent should not precede the need. It should be designed for an identified usage.
I would add two criteria.
The need should be:
- real and observable;
- persistent enough to justify creating and maintaining an agent.
In my case, this led to four complementary functions:
- Retrieve & synthesize — find and understand information.
- Analyze & clean — detect duplication and overlap, and suggest consolidation opportunities.
- Normalize & govern meaning — contribute to controlled terminology and shared vocabulary.
- FAQs & user support — turn static documentation into a more interactive support service.
Because the knowledge base was hosted in Confluence, I implemented these functions using Rovo agents in this project.
The technology followed the documentation strategy — not the other way around.
Continue with Step 2: Design the Architecture.
© Author: Florence Venisse, Technical Documentation & AI Expert – First version dated September 12, 2026