Over the past few years I watched AI learn to write software, and I watched developers absorb that change almost overnight. The asymmetry struck me more than the speed. The people around me who don't write code were still doing their work the way they did it five years earlier: research, analysis, procurement, reporting, compliance, due diligence, monitoring. Tab by tab, doc by doc, spreadsheet by spreadsheet. By most estimates that kind of operational work is around 80% of what a business actually is. I wanted to understand why code got automated first, and what it would take for everything else to follow.

Why code went first

My working answer is that code has a formal substrate. It's text in and text out, with compilers and tests that tell you immediately whether you're right. Language models could climb that gradient quickly because the gradient was legible.

Operations are different. The knowledge that runs them is mostly tacit. It lives in SOPs that are half-written, in the heads of the people who do the work, in the judgment calls nobody thought to write down because they were "obvious." When the automation industry tried to capture this (RPA, workflow builders, wiring boxes together), it demanded that experts first translate their judgment into flowcharts. The translation was lossy, the result was brittle, and the moment an input changed shape, the pipeline broke. The bottleneck was never the expertise; it was the demand to formalize it.

The design position

So the position I took was that the expertise should be the interface. A person should be able to hand the system the same artifacts they'd hand a new hire: an SOP written in plain language, a screen recording of them doing the task. The SOP carries the intent and the constraints; the recording carries the tacit steps nobody writes down. If those artifacts are enough to onboard a person, the bet is that they're enough to onboard a system that can reason.

That bet implies a second position: judgment over branching. A flowchart tries to enumerate every case in advance, which is exactly what tacit knowledge resists. A reasoning model doesn't need the enumeration. It needs the intent and the context, and it can meet exceptions the way a person would — by thinking about them when they occur, rather than matching them against a diagram drawn months earlier. If the system reasons, the process description can stay human.

I built this into Komo as a system called Playbook. It reads process docs and recordings, builds the operation, researches across hundreds of sources on its own, and runs continuously. There is deliberately no canvas of nodes and arrows anywhere in the product.

What people did with it

The beta results were the most interesting part, because the builders were mostly non-technical: strategists, analysts, procurement leads, investors, consultants. Given a system that could read their process, the experts automated their own work directly, with no engineer in the loop.

• An investment team ran deal sourcing and due diligence across 200+ data sources — one person operating like a research department.
• A procurement group scored vendors and flagged risks with reports that updated themselves.
• A consulting firm turned one-off client research into playbooks they now reuse across engagements.
• A strategy team turned monitoring — competitors, regulations, market signals across 50+ sources — into a brief that arrives every morning.

Some walkthroughs, if you want to see the texture of it: one, two, three.

There was also a continuity I hadn't fully planned. Years of building search left me with machinery for grounding claims in sources, decomposing questions, and checking facts, all built so people could trust answers. An autonomous operation needs the same machinery so people can trust its work, and it needs it more, because nobody is watching the work happen.

Open questions

The ones I keep returning to: How much autonomy should a system like this get, and who decides — per task, per team, per company? How does a non-technical expert audit an agent's work without redoing it? And if expertise really is the interface, what happens to the org chart when every expert can run an operation alone? I don't have settled answers. That's partly why this remains the project I find most interesting.