How I built an agentic AI system to preserve institutional expertise — and why every industry needs one
There is a moment every organization dreads, usually on a Friday afternoon.
A senior employee sends an email. They’re going on medical leave, or they’ve accepted another offer, or they’ve decided it’s finally time to retire. Two weeks. Maybe four. And somewhere in the building, a manager stares at the screen and thinks the same thing every manager thinks in that moment:
They’re the only one who knows how to do that.
Not all of it. The procedures are documented. The SOPs exist, the training materials exist, the process maps exist. But the reasoning behind the non-default configuration choices — that’s not in the SOP. The workaround built in 2019 when the system couldn’t handle a specific edge case — not documented. The name of the person in operations who needs a phone call instead of an email, and why — definitely not in any system.
This is the tacit knowledge problem. It has existed as long as organizations have existed. Most organizations confront it the same way: too late, after the person is already gone, while scrambling to rebuild from scratch what should have been captured years ago.
I spent several months building a system to confront it on purpose. This is what I learned.
What I actually built
CoBuild is an agentic AI system — a pipeline of seven specialized AI agents, each with one job, that takes raw SME materials as input and produces a complete performance support kit as output.
The input is whatever the departing expert can provide: recorded interviews, SOPs, job aids, annotated procedures, system documentation. The output is a layered survival kit — job aids, decision trees, scenarios, microlearning scripts, and a measurement plan — designed to keep an organization operating when that person is no longer available.
Check it out visually here.
The system runs seven agents in sequence:
Agent 1 — Intake: Cleans, chunks, and tags every source document. Flags chunks where tacit knowledge is implied but not stated — places where the expert said “I have a query I run” without specifying the query, or “we changed ours to” without explaining why.
Agent 2 — Task & Criticality: Extracts every task the expert performs and scores each on three dimensions: how often it’s done, how catastrophic errors are, and how easily someone else could substitute. The intersection of high criticality and low substitutability is the priority list — the knowledge the organization genuinely cannot afford to lose.
Agent 3 — Knowledge Gap: The credibility agent. Its only job is to find what isn’t there. It applies Gilbert’s Behavior Engineering Model to every identified gap, routing environmental and access problems away from training artifacts. When the system found that an operations coordination gap was really a system access problem, it refused to generate a job aid for it. That distinction is the whole point.
Agent 3.5 — Learning Theory Selection: This is where CoBuild diverges from most AI content tools. For each true knowledge gap, this agent applies four learning theory lenses — Behaviorism, Cognitivism, Social Cognitive Theory, and Constructivism — and recommends the theory whose predictions best explain how transfer will succeed or fail for that specific piece of knowledge. A high-frequency procedural task gets Behaviorism and a step-by-step job aid. A high-stakes exception-handling decision gets Constructivism and a branching scenario. A configuration rationale that a confident user might accidentally “fix” gets Cognitivism and a microlearning that leads with the problem the setting was designed to solve.
Agent 4 — Instructional Strategy: Takes the theory recommendations as binding inputs and specifies every artifact — type, audience, content outline, Bloom-leveled objective, success criterion, and an explicit “do not include” list that prevents scope creep.
Agent 5 — Artifact Builder: Produces the actual deliverables. Where the source material was thin, it inserts clearly marked placeholders with explicit instructions for what SME session is needed to fill them. It never hallucinates account numbers, navigation paths, or checklist items it doesn’t have.
Agent 6 — Evaluation: Builds a Kirkpatrick-aligned measurement plan overlaid with Thalheimer’s LTEM diagnostic framework. For each artifact, it specifies what to measure and — critically — what a failure at each measurement tier tells you: fix the artifact, or fix the environment.
The pilot ran against a synthetic 47-minute SME interview transcript for “Maria,” a D365 Finance lead going on medical leave. The transcript contained six deliberately planted tacit knowledge gaps. All six were found. The system produced 16 performance support artifacts, 8 build flags for SME sessions required before deployment, and an executive summary written in plain language for a controller — zero jargon, zero pipeline references, actionable on day one.
Why learning science matters in an AI system
I want to dwell on this, because it’s the part most AI-in-L&D tools get wrong.
The dominant narrative around AI and learning is about speed. Generate this course faster. Produce this content in seconds. Ten slides in thirty seconds. The implicit assumption is that the bottleneck in instructional design is writing time, and that removing the writing bottleneck solves the problem.
It doesn’t.
The bottleneck in instructional design has never been writing time. It has been diagnosis — correctly identifying what the problem is, what kind of problem it is, and what kind of intervention will actually address it. An AI system that generates content faster doesn’t solve that. It accelerates the wrong thing.
CoBuild is built around a different premise: the value of AI in L&D is not faster content generation. It is faster, more rigorous diagnosis — and then content generation that reflects that diagnosis.
When Agent 3 identifies 22 gaps and routes 5 of them away from training artifacts entirely, it is doing something most human instructional designers don’t do systematically: applying BEM at the gap level, not just at the needs analysis level. When Agent 3.5 selects a coping model framing for the period status recovery artifact because the performer will be stressed and embarrassed at the moment of use, it is applying Social Cognitive Theory in a way that changes the artifact design in a specific, observable way.
This is not decoration. It changes what gets built. And what gets built changes whether the performer actually transfers the knowledge to the job.
The industries that need this most
Here is what I’ve come to believe after building this system: the tacit knowledge problem is not an L&D problem. It is a business continuity problem. And it is more acute in some industries than others.
Government and public sector. The retirement wave in federal and state government is real and ongoing. Program officers, systems administrators, grants managers, and regulatory specialists carry institutional knowledge that took decades to accumulate and cannot be rebuilt quickly. The added complexity: government knowledge transfer happens in highly secured, Microsoft-only environments. CoBuild’s architecture is model-agnostic by design — the same pipeline runs on Azure OpenAI with Azure AI Foundry orchestration inside the network boundary, with no data leaving the environment. That is not a nice-to-have in government. It is the only acceptable architecture.
Healthcare. Clinical knowledge transfer is one of the most studied problems in healthcare — how do you transfer the expertise of a senior nurse, a specialist physician, a pharmacist who has managed a particular formulary for fifteen years? The existing approaches (shadowing, preceptorship, structured handoffs) are time-intensive and don’t scale. An agentic system that can ingest clinical SOPs, recorded SME interviews, and exception case notes and produce a structured knowledge transfer kit is not replacing clinical judgment — it is preserving it before it walks out the door.
Manufacturing and utilities. This is perhaps the most underappreciated application. The warehouse supervisor who knows which scanner resets on humid mornings. The maintenance technician who can read the vibration pattern that precedes a compressor failure three hours before the alarm goes off. The plant engineer who remembers why a particular valve was re-routed in 1997 and what happens if you change it. This knowledge is not in any manual. It was never going to be in any manual. CoBuild is built to surface it.
ERP and enterprise system implementations. This is where I spend most of my professional time, and the knowledge transfer problem is structural to the work. Consulting engagements end. Implementation teams disband. The client’s legacy system experts retire. The people who knew why the system was configured a particular way — what problem a non-default setting was solving, what workaround was built because the system couldn’t handle a specific business case — they leave, and the knowledge leaves with them. Every D365, SAP, or Oracle rollout I have ever been part of has had this problem. CoBuild is a direct response to it.
Nonprofits and volunteer organizations. These are organizations with high staff and volunteer turnover, deep institutional knowledge concentrated in a small number of long-tenured people, and almost no capacity for formal knowledge management. The grants manager who knows which program officer extended the deadline in 2021. The volunteer coordinator who has the cell phone numbers of every reliable Saturday morning crew. The development director who knows the history of every major donor relationship. When these people leave, the organization loses things it didn’t know it had.
Professional services and consulting. When a senior partner leaves a firm, they take client relationship history, project precedents, and industry pattern recognition that took years to develop. When a consulting engagement ends, the client retains the deliverables but loses the consultant’s understanding of why certain decisions were made. CoBuild addresses both — the internal knowledge transfer problem and the client-facing handoff problem.
What the system gets right that surprised me
I built CoBuild to solve a problem I understood well. Some things it got right in ways I didn’t fully anticipate.
The BEM routing is more powerful than I expected. I knew Gilbert’s Behavior Engineering Model was the right lens for gap analysis. I did not fully anticipate how often what presents as a knowledge gap is actually an access problem, a relationship problem, or a management authority problem. In the pilot, 5 of 22 identified gaps — nearly a quarter — were routed away from training artifacts. In a real deployment, that number is likely higher. Every one of those gaps, if addressed with training, would have produced an artifact that looked correct but would fail at Level 3.
The build flags are a feature, not a bug. When Agent 5 produces a build flag saying “this artifact cannot be completed without the account numbers from SME session q-015,” it is doing something important: it is refusing to fabricate content it doesn’t have. This seems obvious in retrospect, but most AI content tools do the opposite — they fill gaps plausibly, and the result looks complete but isn’t trustworthy. The build flags in CoBuild’s output are the system’s way of saying: “Here is everything I can do with what you gave me. Here is exactly what you still need to get from the expert. Do not deploy until you have it.”
The exec summary test is the right acceptance criterion. One of the validation rules for Agent 6 is that the executive summary must contain zero jargon — no “agents,” no “pipeline,” no “BEM,” no “Kirkpatrick levels.” It must read like a document a controller or VP of Finance would open and act on. When I ran the pilot and read the output, it passed. More importantly, it passed in a way that felt like good consulting work — clear, specific, actionable, honest about what was still needed. That is the bar I want every piece of CoBuild’s output to clear.
What this means for instructional designers
I want to be direct about something, because it matters.
CoBuild is not going to replace instructional designers. It is going to change what instructional designers spend their time on — and that is a different thing entirely.
The tasks CoBuild handles well are the tasks that are currently consuming instructional designers’ time without producing proportional value: ingesting source material, extracting task inventories, gap analysis, artifact type selection, first-draft content generation. These are important tasks, but they are not the tasks that require deep human judgment. They are tasks that require thoroughness, consistency, and framework application — which are exactly what AI agents do well.
The tasks that still require a human instructional designer: validating that the gap analysis reflects organizational reality, reviewing artifacts for accuracy and tone, conducting the SME sessions that fill the build flags, managing the stakeholder relationships that determine whether the artifacts get used, and applying the kind of contextual judgment that no agent can replicate — the recognition that the real problem is not what anyone said it was.
CoBuild is a force multiplier. A single instructional designer running CoBuild can do the analytical and production work of a team in a fraction of the time, then spend their remaining time on the high-judgment work that actually requires them.
That is a better use of an instructional designer’s expertise, not a replacement of it.
The road ahead
CoBuild v1 is a working prototype. It runs on Claude Code with Anthropic’s API, against a single synthetic pilot transcript, and produces a complete survival kit from that input. That is the proof of concept.
The path from here is clear:
v2 adds a second pilot in a different domain — volunteer onboarding for a nonprofit, or sailing curriculum knowledge transfer, or marina operations. The goal is to prove the pipeline generalizes beyond enterprise finance. It also adds a simple intake interface so a non-technical user can upload source materials without opening a terminal.
v3 becomes a Blue Edgewater service offering. The model-agnostic architecture means the same pipeline can run inside a government network on Azure OpenAI, inside a healthcare system on a self-hosted model, or in a small business on any accessible frontier model. The knowledge transfer problem is universal. The architecture should be too.
The longer-term question I keep returning to: what happens when CoBuild has run against dozens of knowledge transfer engagements across multiple industries? The gap maps, the theory recommendations, the artifact patterns — all of that is training data for something more powerful than a pipeline. An organizational knowledge preservation system that has seen a thousand Marias knows things about tacit knowledge that no individual instructional designer could know.
That is the version worth building toward.
Try it yourself
The full source code for CoBuild v1, including all seven agent prompts, the orchestration pipeline, and the Maria pilot transcript with planted gaps, will soon be available on GitHub. The showcase site at blueedgewater.com/cobuild includes two sample artifacts — a decision tree and a scenario — produced by the pipeline from the pilot transcript. I have also included a Case Study.
If your organization is facing a knowledge continuity risk — and most organizations are — I am available for consulting engagements. The knowledge transfer problem is urgent, it is addressable, and it is much cheaper to solve before the person walks out the door than after.
jason@blueedgewater.com blueedgewater.com
Jason Edgewater is an instructional designer and Training Developer with an MS in Learning Design and Technology from Purdue University. He is the founder of Blue Edgewater Consulting, where he offers Human Performance Technology consulting, instructional design, and AI enablement services. CoBuild is a Blue Edgewater project.
Leave a Reply
You must be logged in to post a comment.