A role we keep performing without naming. What it is, what it does in the first three months, and where it sits in our platform and process.
"Without your help, we couldn't have worked out how to define the knowledge we needed to capture."
We hear a version of this on every engagement. The customer knows their work cold. They cannot say, on their own, which parts of that knowledge a system needs and in what shape. We do that part for them, and we've been treating it as setup rather than as the thing we're actually good at.
Reading the document is the easy part. The harder job is getting the knowledge out of people's heads and into a form a system can use. There's a name for that work, and it predates us: knowledge engineering. The old AI field called the bottleneck "knowledge acquisition," and the people who did it were knowledge engineers.
The tooling has caught up. The models are cheap and getting cheaper. That makes the elicitation the scarce skill, not the build. It's the one part of our delivery a customer cannot do without us.
Define the knowledge.
Data structures, validation rules, and extraction logic for the customer's documents and decisions.
Maintain it over time.
Corrections, exceptions, and the customer-specific rules captured as the work runs.
Apply it at scale.
The accumulated expertise runs autonomously, around the clock, inside the customer's tenant.
The platform maintains and applies the knowledge well. The first definition, getting the right knowledge into Studio in the right shape, is where customers stall. That's the slot.
A Knowledge Engineer embeds with a new customer to turn how their experts actually work into a knowledge model the platform can run, then hands it off and steps out.
They are not a project manager and not an integration engineer. Their craft is elicitation: sitting with the people who do the work, surfacing the rules that live in their heads, and encoding the judgment that makes the process correct, not just automated.
The instinct with long customer work is to keep the expert embedded. That's how vertical AI companies become consulting firms with a software line item.
So we cap it. The Knowledge Engineer is a front-loaded role: heavy at the start, gone by the end of month three. They define the knowledge, prove it runs, train the customer to maintain it, and leave. What stays behind is the platform doing the applying and the customer doing the maintaining, neither of which needs us in the room.
If the role can't withdraw on schedule, the knowledge wasn't captured well enough. The end date is the quality test.
The knowledge model a Knowledge Engineer builds for the first customer in a vertical is the starting point for the next one. The domain content carries over even when the customer doesn't.
Engagements like this build IP instead of draining margin. The role pays for itself twice: once in the deal, once in the asset it leaves behind.
As the agents absorb more of the mechanical setup, the human role narrows to exactly the irreducible part: the elicitation and the judgment. That's the part worth a person's time.
We start with people because the knowledge starts with people. Someone has to get it out of their heads and into the platform. That someone is the role.