/ How it works

The interview is the input. The feedback loop is the engine.

A recurring cycle: interview, structure, find gaps, interview again, with the right person, about the right thing. Prioritized, not endless.

The operating model

One setup. Then a living feedback loop.

First, identify the critical processes and experts. Then repeat a cycle: interview employees, build and update the knowledge base, identify gaps and plan follow-ups, and return to focused employee interviews. Questions, failures, corrections, handover tests, and process changes from real work also feed into the gap and follow-up stage.

01
Set the direction

Identify critical processes and experts

Define the first scope, priorities, and people to interview.

Recurring cycle Every pass gets more specific
  1. 02
    Capture

    Interview employees

    Gather examples, decisions, exceptions, and sources.

  2. 03
    Structure

    Build the knowledge base

    Turn evidence into linked, sourced, searchable guidance.

  3. 04
    Improve

    Find gaps and plan follow-ups

    Turn missing or unclear knowledge into the next questions.

01

Identify what matters

Start with critical workflows, known dependencies, and a small set of employees. Agree the scope, business priorities, permitted sources, and an interview time budget.

This seeds the loop. It does not require mapping the entire company first.

Output: scope, priorities, time budget, first interview list.

02

Interview employees

AI agents conduct conversational voice or chat interviews about real work. They ask for concrete examples, decisions, exceptions, failure scenarios, and the reasoning behind each step, rather than just a generic description of a role.

Employees can attach documents, screenshots, or demonstrations. Interviews also surface the other people who hold relevant knowledge.

Output: transcripts, sources, named dependencies.

03

Build and update the knowledge base

Material becomes an interlinked, searchable wiki: processes, procedures, decision rules, examples, dependencies, and troubleshooting guidance. Source material is preserved separately from the structured pages.

Every important claim keeps its source, owner, review status, and verification date. Draft explanations are never presented as verified procedures.

Output: wiki pages with provenance, delivered into your existing tools if you prefer.

04

Find gaps and trigger the next interviews

The accumulated knowledge is analysed for missing steps, contradictions, unclear decisions, outdated information, and dependencies on other employees.

For each important gap, the system identifies the right person, generates focused questions, and proposes or schedules a follow-up within approved availability and interview limits. Then the loop returns to step 2.

/ Illustrative example

When only one engineer knows how to recover production.

Interview
“If the service goes down, we call Maya.”
Gap
For database failures, the runbook says “promote the replica”. It does not explain how to check that recent orders are present or how the application reconnects. If Maya leaves, that knowledge leaves with her.
Follow-up
Decant interviews Maya about replication lag, choosing a replica, and reconnecting the application. It requests the relevant configuration and incident notes.
Updated
A reviewed recovery runbook records the checks, decision points, and escalation criteria, with sources and an owner.
Tested
A second engineer rehearses the runbook in a test environment. A missing connection setting triggers a focused follow-up before the procedure is used in production.
/ What “self-improving” means

Better-grounded knowledge and sharper questions, not a model believing itself.

Run the loop on one team first.

Book a pilot