The first digital employee is a project. The second one is a pricing decision.
We shipped our first one months ago: an HR assistant that lives in the company chat, screens candidates, and answers policy questions. It worked. Then something predictable happened that I still failed to anticipate. Everyone wanted one. An assistant to walk founders through company registration. A bookkeeping clerk. A customer-success agent. Inside a company, demand for digital employees does not arrive one at a time. It arrives as a queue, the moment the first one proves itself.
The naive answer is to run the same playbook again: new repository, new service, new deployment pipeline, new everything. That is what we did the first time, and the first time it was the right call, because you cannot extract a platform from zero examples. But you should price the approach honestly before running it twice.
When I audited where the HR assistant’s months had actually gone, the vertical logic — the part that is genuinely about HR — was the minority of the work. The rest was harness engineering: LLM retry classification, prompt-injection defense, output scrubbing, streaming translation, context compaction, durable memory, multi-tenant isolation, proactive notifications, tool error contracts, tracing. None of that work mentions HR anywhere. All of it was learned the hard way, one production incident at a time.
The vertical logic was never the expensive part. The harness was, and the harness does not care which vertical it serves.
So for the second employee we did not clone the playbook. We extracted it. One runtime process now hosts a roster of residents. A mechanism layer at the bottom owns everything generic. A resident layer sits on top, where a new digital employee is a directory rather than a service: prompts, a conversation graph, a domain schema, and nothing else.
The extraction itself was unglamorous. We went through the first agent function by function with an audit sheet, because the headline features hide the real inventory. Around every large mechanism sit a dozen small guards that you only rediscover in production. When we finished, the mechanism layer was twice the size of the first resident’s business code. That ratio is the entire argument, and it is measured rather than asserted.
The payoff appeared immediately. The first resident of the new runtime went from an empty directory to real-machine testing in days. The second business moved in within the week. The marginal cost of a digital employee dropped from months to weeks. More importantly, that week is now spent where it should be: on the domain, on what a registration flow actually needs, instead of re-learning lessons the platform already carries.
One boundary rule keeps the arrangement alive. Mechanism moves down, domain stays up, and residents never import each other. Whenever a resident grows something generic — a retry policy, a form-validation trick — that thing is promoted into the mechanism layer, where the next employee inherits it at no cost. This is the compounding that makes the queue survivable: each employee you ship makes the next one cheaper.
Build the first one from scratch. You have to, because that is where the platform’s raw material comes from. Then extract it, and let every employee after that start from the middle.