Most knowledge transfer starts from memory: interviews, documentation sprints, a handover written in the last two weeks. This method starts from the work itself. It rebuilds the role from the trace the work already leaves, then produces the handover, the training material and the job description from that one record.
What is a role record?
A role record is a living map of how one role actually runs: its workstreams and their status, the people it works with on each, the commitments it has made and is waiting on, its recurring rhythms, and the systems it owns. It is rebuilt from the work and kept current, so it describes the role as it runs today, not as it was designed.
The role at a glance, drawn directly from a role record with no AI in between. Fictional data from the live demo.
Which sources does it read?
Only what the role-holder connects, and only to read.
| Source | What it contributes | What it does not |
|---|---|---|
| Workstreams, the people on each, commitments made and owed, the history behind decisions | Anything that was only said aloud | |
| Calendar | Recurring rhythms, upcoming deadlines and meetings, who meets with whom | What was decided in the meeting, unless it was written down afterwards |
| Systems of record | What the role actually built and owns, for example SAP integration packages and transports with their source | Systems that are not connected |
| The role-holder's own notes | Corrections and context, treated as authoritative | Nothing, unless they add it |
How is the record built?
- Read. Mail threads and calendar events are read from the role-holder's own mailbox, either from the desktop mail client or from Microsoft 365 with read-only permission. Systems are read through their own APIs.
- Reconstruct. Threads are grouped into workstreams. For each one the record keeps its status and phase, the latest development, the people involved and their part, open commitments in both directions, and a timeline.
- Separate inside from outside. People are split by whether they are inside the organization or outside it. The outside list is the part manual handovers lose most often.
- Correct. The role-holder can merge workstreams, rename them, mark noise to ignore, and add notes. Their notes override what was inferred.
- Ground in systems. Where a workstream owns systems, the record links them and pulls what they actually contain, so the systems part of a handover is evidence rather than recollection.
What does it produce?
Three deliverables, all from the same record, each written for a different reader:
- A temporary handover for a colleague covering a leave: what will happen while you are away and how far their authority goes.
- A permanent knowledge transfer for a successor: the whole role, its history, the people outside the organization, and a first-30-days plan. Both are shown in the annotated handover examples.
- A job description for hiring the next person, with every requirement tied to the work that needs it and no names in it. See job description from the actual work.
For the questions each of these answers, see the 100 handover questions. For why this matters most when a long-tenured expert retires, see how to capture a retiring expert's knowledge.
What can't it see?
Anything that never left a written trace. Phone calls, conversations in the hallway, decisions made in a meeting that nobody wrote down, judgment the person applies without noticing, and work done in systems that are not connected. It is also only as current as its last refresh. That is why the role-holder's notes count as authoritative, and why the record is the starting point for a handover conversation, not a replacement for it.
Which roles does it fit?
Roles whose work runs through email, calendars and systems: coordinators, delivery and project leads, managers, founders, owners of integrations and vendor relationships. It fits poorly where the work is mostly hands-on and leaves little written trace, such as a machine operator on the shop floor. For those roles, shadowing and interviews remain the better tools.
Who owns the record?
The person whose role it is. The record is built for them, they decide what is shared, and only finished outputs leave, never the raw mail. It maps the work, not the worker. More on this on the security page.
Where does it lead?
The same record that briefs a human successor is what an AI agent needs to take on part of the role. That step is gated: the agent takes over a task only when its drafts are proven right on real cases and it can actually reach the systems involved, and a person stays in charge. How the gates work.