The answer was in the documentation. In two of them, in different places.

Neither source alone is enough, and the usual fixes cost too much

Technical documentation is one of the most underused assets an organisation has. It exists in volume, spread across internal knowledge bases, version-controlled repositories and configuration references. Finding the right answer inside it means knowing where to look, how it is structured and how to read it. For most people that friction is enough to abandon the search.

A user asking how to configure a specific integration needs the organisation's own credential procedure and the platform's official configuration reference at the same time. Answering from either alone produces something technically correct and practically useless.

The two standard remedies each carry a cost that is easy to underestimate at the point of choosing:

• A managed service means sharing your docs. A third-party documentation chatbot requires handing proprietary internal content to a vendor. In a regulated environment that rules the option out before cost is discussed.
• Vector search brings an infrastructure tail. An embedding pipeline, a hosted vector store, and continuous re-indexing as content changes. The maintenance burden outlives the enthusiasm of whoever built it, and stale embeddings fail quietly rather than loudly.
• Similarity is not precision. That trade is fine for prose and poor for a configuration reference. Someone asking about one node does not want passages about a node that resembles it.
• Follow-ups are ambiguous on their own. "What about the credential for that one?" means nothing without the preceding exchange, and keyword-based detection misroutes exactly the conversational questions users ask most.

Well-organised documentation is already an index. Use it

The architectural decision underneath this build is the one worth stating plainly: for the external path, there is no vector database.

Traditional retrieval embeds an entire corpus, which buys tolerance for unstructured, inconsistently organised content. Well-maintained platform documentation is not that. Its folder hierarchy, file naming conventions and component metadata are already a working index, built and kept current by the people who write the docs. Paying to rebuild an index that already exists is the more expensive mistake.

So the system navigates that structure instead of approximating it with embeddings. It works from a pre-generated structural map: a lightweight JSON file capturing the folder hierarchy, file paths and component metadata. Interpreted intent narrows to the relevant top-level folders, a component index points at likely files, and a final step selects three to five files before any content is fetched.

The trade is real and worth naming: this depends on the external documentation being well structured. Against a sprawling, inconsistently organised corpus, vector search would be the better tool.

One orchestrator, two specialists, the right method for each source

Internal documentation is curated and relatively stable, so it gets semantic search, and the index stays inside the organisation's own infrastructure; no documentation leaves it. External platform documentation is structured and versioned, so it gets structural navigation. Using one method for both would either waste the structure of the external repository or over-engineer the indexing of the internal content.

An orchestrating agent analyses each question and routes it, weighing the domain, the conversation history so follow-ups resolve correctly, and a confidence score. Where confidence is low, a secondary scoring pass evaluates every candidate before deciding. Follow-up detection is a classification step rather than a keyword heuristic.

Before any retrieval, the selected agent works out what the user is actually trying to accomplish. That interpreted intent, not the raw question, drives every retrieval decision. A question spanning both domains runs both agents concurrently and merges the answers, each part attributed to its source, so response time stays flat regardless of how many sources were consulted.

Adding a knowledge domain, whether another internal base or a new external platform, needs only a new specialist agent with its own retrieval logic. The orchestrator routes to it without modification.