How CRAFT Runs the Business, Not Just the Software

We built CRAFT to ship software. Then we ran it on a client's operations and almost nothing had to change. Same five phases, same artifacts. Here's what carried over, and where it stopped.

Two weeks ago I spent a morning with the operations director of a mid-market company, watching how a new customer actually gets onboarded. Not the version in the SOP document. The real one. A sales rep closes the deal and emails the contract to ops. Someone re-keys the account into the billing system. Someone else sets the customer up in the support tool. And a fourth person, who happens to know things the other three don't, quietly fixes the parts that got missed. The whole thing took nine days and four people, and at no point did anyone do it wrong. The work was fine. The coordination was the problem.

I've spent twenty years building and leading engineering teams, and the last year writing about an operating system Chuck and I built called CRAFT. If you've read this series, you know the shape of it: five phases, Context, Rationale, Automate, Fortify, Telemetry, with a small set of artifacts underneath. What I did not expect, when we started installing it on the client side, is how little of it is actually about code.

Operations and software delivery are the same problem wearing different clothes.

I want to walk through that, because it's the part of the thesis I was least sure about and am now most convinced of. CRAFT was built to coordinate engineering work. It turns out engineering was just the first place we noticed the problem. The operating system runs the business too, and it runs it with the same artifacts, because operations and software delivery are the same problem wearing different clothes: getting parallel work to cohere when no single person can hold all of it in their head.

Context: the operating picture nobody had written down

In the codebase, Context is the shared truth a team needs before it writes a line: what we're building, for whom, under what constraints, and what we already know about the risks. We wrote in Series 2 about feeding that context to the tools deliberately, instead of letting every developer reconstruct it from memory.

The operations version is the same artifact with the org chart removed. When I sat with that onboarding team, the single most expensive fact in the room was that the nine-day process existed nowhere as one picture. Each person held their own segment. The fourth person, the one who fixed the misses, was the closest thing the company had to documentation, and she was planning to retire in eighteen months.

An agent cannot coordinate a process it has never been told the shape of. Neither can a new hire.

So the first thing we built was not an automation. It was a Context Graph for the workflow: every step, who owns it, what it depends on, what the constraints are, and where the known failure points sit. Boring work. It put into one shared artifact what had been living in four heads and a retiring employee's instincts. And the moment it existed, two things happened that I've now watched happen in every engagement. The team found three steps that existed only out of habit and deleted them. And the AI work that came later had something to read. An agent cannot coordinate a process it has never been told the shape of. Neither can a new hire. The Context Graph is what makes both of them useful on day one instead of week six.

Rationale: the decisions that govern the agents

In engineering, a Decision Record captures what was chosen, why, and what would make us revisit it. JWT versus session cookies, that kind of thing. The point was never the database choice. The point was that a decision made out loud and never written down is not a decision. It's an assumption, and assumptions reappear later as rework.

The operational decisions are higher-stakes and, before CRAFT, almost never written. Which refunds can be issued without a manager. When a discount needs sign-off. What gets escalated to a human and what doesn't. These rules lived in people's judgment, which is fine right up until you want to hand part of the work to an AI agent. An agent that cannot read the rule "refunds over five hundred dollars go to a person, because of what happened last March" will resolve that gap on its own. Plausibly. And wrong.

You cannot delegate to an agent what you were never willing to write down for a human.

This is the part operators underestimate. They think the blocker to automating a workflow is the technology. Most of the time the blocker is that the governing decisions were never made explicit, so there's nothing safe to automate against. The Decision Record is not bureaucracy. It's the thing that makes autonomy grantable. You cannot delegate to an agent what you were never willing to write down for a human.

Automate: autonomy calibrated to what a mistake costs

Here's where most of the AI initiatives I get called in to rescue went wrong. Someone decided to "add AI to operations" and pointed the most capable tool they had at the most visible process, usually something customer-facing, because that's where the demo looks good.

Automation scales with risk, not ambition. The question is never "can the model do this." It's "what happens if it does this wrong, and how fast can we catch it."

CRAFT's rule is the opposite, and it's the same rule we run on code: automation scales with risk, not ambition. The question is never "can the model do this." By 2026 the model can do far more than you should let it. The question is "what happens if it does this wrong, and how fast can we catch it." A reversible, low-stakes, high-volume step (drafting the onboarding email, categorizing an inbound ticket) earns aggressive automation. A step where a mistake is expensive, irreversible, or invisible until a customer is already angry keeps a human in the loop, with the agent assisting rather than acting.

When we ran that calibration across the onboarding workflow, about half the steps were safe to automate outright, a third moved to agent-assisted with a person approving, and a handful we deliberately left fully manual. That mix is not a failure to automate. It's the design. The companies that get burned are the ones that treated "how much can we automate" as the goal, instead of "how much can we automate safely," which is a different and far more useful number.

Fortify: nothing goes live without a way to catch it failing

In the codebase, the Fortify Gate is the set of conditions that have to be true before anything ships: rollback plan, known failure modes, basic telemetry, and a definition of done that isn't "it compiles." It's the rule teams break most often under pressure, and the one that produces the most expensive incidents when broken.

Operational rollouts break it constantly, because operations rarely thinks of itself as shipping. But flipping a workflow from manual to agent-assisted is a deployment, and it deserves the same gate. Before that onboarding automation went live, we asked the Fortify questions. How do we roll back to the manual process in an afternoon if this misbehaves? What are the three ways it's most likely to fail, and are we watching for them? Who gets paged when a customer falls through, and how would we even know? An operational change that can't answer those is exactly as dangerous as a code deploy with no rollback. More so, because the failure shows up as a lost customer, not a stack trace.

Telemetry: measuring the outcome, not the activity

This is the phase that separates CRAFT from a vendor dashboard, and it's the one I care about most. Telemetry measures outcomes, not activity. In engineering that means we don't count pull requests merged. We measure whether the thing we shipped did what it was supposed to.

One of the automations we were proudest of was making things worse. We caught it because we were measuring the outcome. A handle-time dashboard would have called it a win.

Every operational AI tool I've watched get pitched reports activity, and activity is almost always the wrong number. Tickets resolved per hour. Average handle time. Percentage of conversations the bot closed without a human. Those numbers go up the moment you deploy the tool, which is why vendors lead with them. None tell you whether the customer's problem actually got solved. The Telemetry question for that onboarding workflow was not "how fast is onboarding now." It was "are customers active and getting value by day thirty, and did that rate go up or down." When we instrumented for the outcome instead of the activity, one of the automations we were proudest of turned out to be making things slightly worse: faster onboarding, lower thirty-day activation, because the step we'd automated was where customers used to ask their first real question. We caught it because we were measuring the right thing. A handle-time dashboard would have called it a win.

What I'm still working out

I'm not going to tell you CRAFT-on-operations is a finished, proven system. We've run the full loop on a handful of client workflows, not a hundred, and the sample is young. What I can say is that the thing I expected to be hard, translating an engineering operating system to the business, barely required translation. The artifacts carried over almost unchanged, because they were never really about code. They were about coordinating work that has gotten too fast and too parallel for instinct to hold it together. That fit the codebase first. It fits the business just as well.

The honest open question is where the loop needs artifacts we haven't built yet. Operations has a human-change dimension that engineering has less of. You're not just deploying a workflow, you're asking people to trust it, and the adoption side of that is the part I'm least finished thinking about. We'll write about it when we've run it enough times to say something true.

For the operator reading this, the practical move is smaller than a transformation initiative. Pick one workflow. Write down its real shape, not the SOP version. Write down the decisions that govern it. Then, and only then, ask what's safe to automate. You'll find, as we keep finding, that most of the value was in the writing-down, and the automation was the easy part everyone wanted to start with.

For the founder reading this, it's the same loop you should already be running on the product. The company that pulls ahead is not the one with the most agents. It's the one where every agent, every workflow, and every person is reading from the same context, governed by the same written decisions, and measured against the same outcomes.

Next week, Chuck and I take CRAFT out of the abstract and into a real industry, with the first of two Field Notes pieces on where the operating system took hold first and what actually happened when it did.

AI that runs your business. Not the other way around.