Why the KT meeting shouldn't exist

Every IT services firm has the same ritual. Someone resigns, and the two weeks that follow fill up with meetings called KT. A senior engineer sits with their successor and tries to say out loud what they learned over two years on one client account.

It never works. What transfers is the part that was easy to write down — the runbook, the access list, the deployment steps. What doesn't transfer is why that integration is fragile, which client contact escalates, what was tried in 2023 and quietly failed. That half leaves with the person, and the client pays for it in the third month after the handover, when the new engineer rediscovers a problem the old one had already solved.

We didn't set out to build a knowledge tool. We set out to ask why the context never survives, and the answer turned out to be structural. The work happens in private. Every AI tool a delivery team uses today gives each person their own window, and when the tab closes, the reasoning inside it stops existing.

So we started from a different unit. Not the person, and not the company — the client engagement. An engagement is the thing that has an MSA, a confidentiality clause, a delivery team that rotates through it, and a lifespan longer than any individual on it. Sessions live inside an engagement. Memory accrues inside an engagement. Nothing crosses between engagements, because the contract says it can't.

Once the work is shared and scoped that way, KT stops being an event. The night shift hands to the morning shift with the reasoning intact. A successor asks a question and the answer comes from hundreds of real sessions instead of two weeks of someone's recollection.

We're not selling a tool. We're selling the end of the KT meeting.