Company Knowledge Base Agent
An enterprise-wide agent that answers questions against Confluence through MCP — no vector store, no separate index, no sync job to go stale.
Engagement
Anonymized — Fortune 500 pharmaceutical enterprise
30 → 5 min
to find internal knowledge
The problem
What this replaced
The manual process, before
- 01Knowledge is scattered across the organization.
- 02Confluence is the central store — but finding the right page inside it is still slow.
- 03Search across many spaces and pages, then give up and ask a colleague who already knows.
Who has this problem
All internal personnel — not just engineering. Anyone who needs to look something up.
Why it costs money
Significant time lost per lookup, plus a second cost that rarely gets counted: the repeated interruption of the people who already know the answer.
The build
What I built
The agent connects to Confluence through an MCP server and answers natural-language questions by calling Confluence tools directly — page retrieval, page and space search, and CQL queries — chaining calls until it has enough to answer.
Cut lookup time from about thirty minutes to a few, without building an index that has to be kept in sync.
Capabilities
- Page content retrieval
- Page and space search
- CQL (Confluence Query Language) querying
- Multi-call chaining when one query is not enough
- Answers returned with source page links
How it runs
The workflow
Trigger
A natural-language question from any employee.
- 01Agent parses the question and selects the right Confluence MCP tool(s)
- 02Calls get page, search page, search space or CQL query
- 03Iterates with further calls when the first result is insufficient
- 04Aggregates retrieved content and synthesizes an answer
Output
A direct, concise answer with links to the Confluence pages it came from.
Architecture
How it fits together
Components
- Query interface
- Knowledge agent — Claude Sonnet 4.5
- Confluence MCP server
- Confluence spaces and pages (existing, untouched)
Data flow
01
Question → tool selection
02
Confluence MCP calls, chained as needed
03
Aggregate + synthesize
04
Answer with source links
The guardrail
What it is not allowed to do
No index means nothing to go stale.
The deliberate choice here was to build no vector store at all. The agent queries Confluence live through its own API surface, so answers reflect the current state of the documentation rather than whenever an embedding job last ran. Every answer carries source links, so a reader can verify the claim rather than trust it.
Stack
What it is built on
- Model
- Claude Sonnet 4.5
- Tooling
- Confluence MCP server
- Retrieval
- Live tool calls — no vector store, no separate index
- Cloud
- AWS (internal enterprise)
Hard parts
What made it difficult
- 01
Deciding when a single tool call is enough and when the agent needs to keep digging — over-querying is slow, under-querying is wrong.
- 02
Serving every persona in the business, not just engineers, from one interface.
- 03
Answering from documentation written by many teams, to no shared standard.
Outcome
What changed
30 → 5 min
average lookup time
Information lookup time fell from about thirty minutes to about five.
Deployed enterprise-wide across all personas, not limited to technical teams.
Written as a de-identified case study. The client's identity, space and page names, and documentation contents are not disclosed. What is described here is the architecture pattern and the measured outcome — nothing proprietary to the environment it runs in.
Limited availability
Tell me the problem.
I’ll tell you if an agent is the answer.
A 30-minute call, no pitch. Describe the manual loop that hurts and I’ll give you a straight read on whether this is worth building — including when the honest answer is a script, not an agent.
30 minutes · video call · no pitch