94 Years of Experience. Zero Documentation.

9:15am, Monday. A mid-level engineer walks to Graham's office. The door is open. She asks: "Graham, how do we handle the soil bearing capacity assessment for the retail park project? The site investigation suggests variable ground conditions and I'm not sure which BS code applies for the foundation design."

Graham answers from 34 years of experience. The right code. The right approach. The specific local authority interpretation that differs from the standard guidance. The thing to watch for in the ground investigation report that indicates potential sulphate attack. Takes 15 minutes.

The answer is correct, thorough, and now exists in exactly one place: the mid-level engineer's notebook.

At 9:45, a junior engineer messages Graham on Teams. "Can you check my retaining wall calculation? I'm not sure about the surcharge loading for the adjacent highway."

At 10:20, another junior walks in. Pricing query for a client proposal. "What do we normally charge for a Category 3 contaminated land assessment with risk assessment and remediation strategy?"

By lunchtime, Graham has answered six queries. Each one was precise, valuable, and unrecorded. Tomorrow, a different engineer will ask the same soil bearing capacity question. Graham will answer it again. The week after, another will ask the same pricing question. Graham will answer it again.

This is, when stated precisely, a knowledge management system whose storage medium is a 57-year-old man, whose retrieval mechanism is a queue outside his office, and whose backup strategy is hoping he doesn't retire before someone writes it down.

Civil engineering consultancy in Birmingham. Forty-six employees. £5.2M annual revenue. Three founding partners (Graham, David, Margaret, ages 57, 59, 62), eight senior engineers, twelve mid-level engineers, fifteen juniors, eight support staff.

The firm's most valuable processes exist only in the experience of five people: the three founders and two senior engineers aged 56 and 61. Client proposal methodology. Technical review standards. Regulatory interpretation for complex projects. Pricing models for unusual scopes. Local authority relationships and the specific ways different councils interpret the same national standards. Regional ground condition knowledge accumulated over decades of working in the West Midlands.

None of this is in a document. When a junior engineer encounters a non-standard situation (which, in civil engineering, is most situations), the answer is "ask Graham" or "ask David" or "check with Margaret."

The five knowledge holders spend an estimated 12-18 hours per week combined answering "how do we handle X?" queries. At an average loaded cost of £65 per hour, that's £40,560 to £60,840 per year in senior staff time spent being a human knowledge base. The junior and mid-level engineers lose an additional 8-12 hours per week combined to queuing, working around gaps, and making assumptions that later need correction: £12,480 to £18,720 per year. Total annual cost of undocumented knowledge: £53,040 to £79,560.

The previous documentation attempt: an SOP project four years ago. It produced 14 documents covering 6 processes. Eight other critical processes remain undocumented. The project stalled because Graham, David, and Margaret couldn't spare the 60-plus hours required to sit with a technical writer while also running client projects and managing a firm.

One incident captures the risk: a junior engineer misinterpreted a regulatory requirement on a structural assessment while Graham was on annual leave. The error was caught at peer review but cost three days of rework (£2,340 in billable time lost). The peer reviewer noted that the correct interpretation was "something everyone who's been here more than ten years knows, but it's not written down anywhere."

Three of the five critical knowledge holders are likely to retire within five years. Combined experience leaving: 94 years. Estimated cost per departure (from industry benchmarks for engineering consultancies): £120,000 to £200,000 in lost productivity, client relationship disruption, and re-learning time. For three departures: £360,000 to £600,000 in knowledge that currently exists in three people's heads.

Four stages. The core insight: you don't need Graham to sit with a technical writer for 60 hours. You need Graham to have 30-minute conversations about how he makes decisions, captured and structured so the next person who asks the same question gets Graham's answer without Graham being in the room.

Stage 1: Knowledge capture via structured interview

The agent conducts 30-minute conversational interviews with the knowledge holders. Structured by topic: "Walk me through how you approach soil bearing capacity on a variable ground site." "What's the most common mistake you see juniors make on retaining wall calculations?" "When does the standard BS code guidance not apply?"

The responses are transcribed, structured into knowledge articles (problem statement, approach, decision criteria, exceptions, references, source attribution), and stored in a vector database for semantic search. Each article is tagged by topic, project type, regulatory area, and confidence level.

Graham doesn't write documentation. He talks about how he does his job. The agent turns the conversation into searchable, structured knowledge.

Stage 2: Knowledge retrieval via Teams bot

Engineers query the agent through Microsoft Teams (where they already work). The agent searches the knowledge base semantically, retrieves the most relevant articles, and presents them with source attribution: "Based on Graham's documented approach from [date]."

Confidence scoring on every answer: high confidence (directly documented from a capture session), medium (inferred from related topics), low (gap identified, suggesting the engineer ask the knowledge holder directly). The engineer knows whether they're getting Graham's documented expertise or a best guess.

Stage 3: Gap detection and capture scheduling

Every query that returns a low-confidence or no result gets logged as a knowledge gap. Gaps are aggregated weekly. The most frequently hit gaps become the agenda for the next capture session.

This is the mechanism that makes the knowledge base grow from demand rather than from a top-down documentation project. The engineers' questions identify what needs documenting. The capture sessions address the gaps in priority order. After six months, the 20 most frequently asked question categories are documented. After twelve months, the critical mass of knowledge is captured, searchable, and independent of any individual.

Stage 4: Knowledge maintenance and currency

Knowledge articles have review dates tied to regulatory update cycles. When BS codes are updated, when local authority guidance changes, when new standards are published, the agent prompts the relevant knowledge holder: "BS 8004 was updated last quarter. Does your documented approach to foundation design on variable ground still apply?" The answer updates or confirms the article. The knowledge base stays current without requiring a full re-documentation cycle.

The 30-minute format was chosen deliberately. The SOP project failed because it required 60-plus hours of structured documentation time from people who run a consultancy. Thirty minutes is the length of a meeting Graham would attend. The constraint forces the capture sessions to focus on one topic per session rather than attempting comprehensive documentation. One topic, documented well, per session. Four sessions per month. Twenty topics in the knowledge base after five months. The pace is slower than a documentation sprint. It's also sustainable, which is why it works when the sprint didn't.

Source attribution is the trust mechanism. Junior engineers trust Graham. They don't inherently trust a chatbot. Every answer from the agent carries "Based on Graham's documented approach from [date]" or "Based on Margaret's guidance from [date]." The knowledge IS Graham's knowledge, delivered through a different channel. The attribution makes the bot an extension of Graham rather than a replacement for him. Early adoption in the pilot depended almost entirely on this: engineers used the bot when they could see whose expertise it was delivering.

The gap log is the most valuable output of the first month. Before the first capture session, nobody knows which topics get asked about most frequently. After two weeks of queries hitting the empty knowledge base, the gap log produces a ranked list of the firm's most critical undocumented knowledge. That list is worth more than the 14 SOPs the previous project produced, because it reflects what engineers actually need to know rather than what a documentation project assumed they should know.

Recommended stack:

Orchestration: n8n (self-hosted or cloud). Intelligence: Claude Sonnet for capture interviews and retrieval, Haiku for gap classification. Vector database: Pinecone (managed, simple API) or Supabase pgvector (self-hosted, lower cost). Interface: Microsoft Teams bot (where the engineers already work). Document storage: SharePoint (knowledge articles alongside existing documents).

Step 1: Set up infrastructure (Days 1-2)

Deploy n8n instance. Set up vector database (Pinecone free tier covers up to 100K vectors, more than sufficient for initial knowledge base). Configure Microsoft Teams bot registration (Azure AD app registration, bot framework). Configure Anthropic API credentials. Set up Postgres for gap logging and usage tracking.

Step 2: Build the knowledge capture workflow (Days 3-5)

Create a structured interview workflow. System prompt for Claude Sonnet: "You are interviewing a senior engineer to capture their expertise on [topic]. Ask focused questions: How do you approach this? What are the decision criteria? What are the common exceptions? What mistakes do juniors commonly make? What regulatory references apply? Push for specificity: ask for recent examples, site-specific details, and the things they know that nobody writes down."

Post-interview: Claude Sonnet structures the response into a knowledge article (problem statement, approach, decision tree, exceptions, references, source attribution, confidence level, review date). Chunk the article, generate embeddings via the Embeddings node, store in the vector database. Store the structured article in SharePoint.

Step 3: Build the retrieval workflow (Days 5-7)

Teams bot receives engineer query via webhook. Query embedded and searched against vector database (top 3 results). Claude Sonnet synthesises retrieved articles into a response with source attribution and confidence scoring. High confidence: return answer via Teams. Medium: return answer with "verify with [source]" flag. Low: return "not documented yet," log the gap.

Step 4: Build the gap detection workflow (Days 7-8)

Every low-confidence query logged in Postgres: query text, topic area, requesting engineer, timestamp. Weekly Schedule Trigger aggregates gaps by frequency. Generates "Top 10 Knowledge Gaps This Week" report. Sends to Graham, David, and Margaret with suggested capture session topics.

Step 5: Build the maintenance workflow (Days 8-9)

Knowledge articles tagged with review dates based on regulatory update cycles. Schedule Trigger checks for articles approaching review date. Notifies the attributed knowledge holder. If updated: re-embed and update vector store. If confirmed current: extend review date by the standard cycle.

Step 6: Conduct initial capture sessions and test (Days 10-14)

Five capture sessions with Graham on the firm's most frequently asked topics (identified from the gap log or from Graham's own assessment of "what I get asked every week"). Test retrieval against 20 real questions engineers have asked in the past month. Compare agent responses against Graham's actual answers. Refine prompts based on accuracy (target: 85-plus percent match on documented topics). Deploy to 3-4 engineers for a two-week pilot before full rollout.

Estimated build time: 10-14 days for a competent n8n developer. 3-4 weeks if learning RAG patterns alongside the build.

Build costs (one-time):

If hiring an n8n developer: 10-14 days at £300-£500 per day = £3,000 to £7,000. If building yourself: £0 plus your time.

Monthly running costs:

Claude API detail: Capture sessions: roughly 4 per month at approximately $0.30. Retrieval queries: roughly 200 per month at approximately $3.60 (growing as adoption increases; at 500 queries, roughly $9). Gap classification via Haiku: roughly $0.05. Maintenance prompts: roughly $0.10. Total: approximately £4-£10 per month, scaling with usage.

Year-one total cost: £3,288-£7,960 (with a hired builder) or £288-£960 (self-built). Compared against £53,040-£79,560 per year in senior staff time spent answering questions. And compared against £360,000-£600,000 in knowledge loss risk across three retirements within five years.

The build cost is recovered in the first month of reduced interruptions. The knowledge loss prevention is incalculable because you only discover the cost when the person has already left and the knowledge has already gone.

Knowledge holders won't engage with capture sessions. Graham is busy. Start with the topic he gets asked about most (reduces his interruption burden immediately). Show him the gap log after week one: "You got asked about soil bearing capacity four times this week. One capture session means you never answer it again." Self-interest is the motivator, not documentation enthusiasm.

Captured knowledge is too generic. The interview produces "consider ground conditions" rather than "in the West Midlands, variable ground typically means BS EN 1997-1 Clause 6.5 with the local authority amendment requiring..." Push the prompts for specificity: "Give me a specific recent example." "What would you tell a junior engineer standing on that site right now?" "What's the thing you know about this that nobody writes down?" Refine after the first five sessions.

Engineers don't trust the bot. Source attribution is the fix. Every answer says "Based on Graham's documented approach from [date]." The answer IS Graham's knowledge. Trust builds from accurate answers, not from mandates. Pilot with engineers already comfortable with AI tools.

Knowledge becomes stale. Regulatory updates change the correct approach. Review dates on every article. Regulatory update feeds trigger review prompts. The maintenance workflow is not optional.

Vector search returns wrong context. A query about retaining wall design retrieves an article about retaining walls in a different context (landscaping versus highway infrastructure). Tag articles with context metadata (project type, regulatory area, ground conditions). Use hybrid search (semantic plus metadata filtering) rather than pure semantic search.

If your most critical process knowledge exists only in the heads of people approaching retirement, and your documentation strategy is "we'll get to it when we have time" (which you won't, because the people who hold the knowledge are also the people who run the firm), the knowledge will leave when they leave.

The queue outside Graham's office is the Monday morning bottleneck in its purest form. Your team is the software. Graham is the knowledge base, the search engine, and the help desk. The 27 engineers who need his expertise are the users. The retrieval mechanism is a queue and a question. The backup strategy is hope.

The agent doesn't replace Graham's expertise. It captures it in a form that survives his retirement, answers questions at 2am when Graham is asleep, and stops the same question being answered for the fourth time in a week by a man whose billable rate makes the repetition rather expensive.

Ninety-four years of combined experience. Five retirements approaching. The question is whether the knowledge is documented before or after it walks out the door.

This is Blueprint #46 in the AdAI series. Every week we publish the full architecture of a real AI agent design: the bottleneck, the systems, the logic, the build guide, and the costs. Free to read. Free to build from.

Want the next one? Subscribe to AdAI News. New blueprint every Thursday.

by CD
for the AdAI Ed. Team