What You Own and What We Keep

The reference architecture underneath CRAFT OS, and the line we draw on every engagement between what a client owns and what we hold onto. Most firms in this market never tell you where that line sits.

Skip: The sentence I gave one line to

A month ago Chuck and I wrote a piece about who owns the coordination layer a business runs on, and somewhere in the middle of it I put down this:

Clients own the layer: the context, the rules, the agents, the infrastructure. We keep the method, the reference architecture, the reusable components, and the telemetry model.

One sentence. Then I moved on to the next thought like it was a housekeeping detail.

It isn't.

That sentence is the most commercially loaded thing in this newsletter, and I've spent the four weeks since writing around it instead of into it.

I showed you our own operating system. I showed you the money and the pipeline underneath it. Last week I told you what owning any of it actually costs and when the math flips. Every one of those pieces closed by promising the architecture, and every one of them delivered something adjacent to it.

So here it is, and I want to hand most of it to Chuck, because the interesting part is structural and he built it.

One thing before I do. Every firm in this market draws this line somewhere. The ones running workshops draw it so that you keep a slide deck. The platform vendors draw it so that you keep a login. Almost none of them will tell you where the line is before you sign, and most operators don't think to ask until renewal, which is the worst possible moment to find out. We're going to draw ours in public, in enough detail that you can hold us to it.

Chuck: What's actually underneath

The reference architecture is four things that hold state, plus one surface that makes the state actionable. That's it. Every engagement we run puts the same five pieces in place, and what differs between a wealth management firm and a field service company is what goes inside them, not which ones exist.

The context layer. This is the compressed, current answer to how a specific business actually operates: who the people are, what the accounts are, what a normal week looks like, which exceptions are routine and which are alarming. It exists because the alternative is an agent that guesses.

An agent that guesses is worse than no agent at all, because it guesses confidently.

We wrote about this pattern back in April. It has changed less than anything else in the stack, which is usually a sign that something is load-bearing.

Written intent. Before anything gets built, somebody writes down what the system is for, what it is allowed to decide by itself, and what has to route to a person. This is the piece most businesses have never produced, in any form, for any process. It's also the piece that determines almost everything downstream, including how long the build takes.

The decision record. What got decided, when, and why. Not what the code does, which you can read, but why it does that instead of the other thing. Six months into an engagement this is the difference between a system somebody can modify and a system everybody is afraid to touch.

The gate. A checklist that turns "done" into a question with an actual answer instead of a judgment call at the end of a long week. We wrote about the Fortify Gate in May. The thing worth adding now is that the gate is where the telemetry hooks in, because "did this improve the outcome" is a question you can only answer if you decided in advance what you were measuring.

The MCP surface. This is the newest piece and the one that changes the character of the other four. The context, the intent, and the decisions are all things you can look at. An MCP surface is what turns them into things you can act inside. InTech Time already works this way for time off: someone asks in plain language, inside the session they were already working in, and the system checks it against policy and either handles it or routes it. We're extending the same surface to the categories I walked through two weeks ago, so the money and the pipeline stop being things you go check.

Five pieces. None of them are novel individually. The architecture is the claim that these five, in this relationship, are what a coordination layer minimally requires, and that everything else is a detail of a particular business.

Skip: Three businesses, one shape

Chuck says the shape holds across engagements. That claim is worth being specific about, because it's the entire basis for us charging anyone for a reference architecture instead of billing them to invent one.

Three businesses. A boutique wealth management firm, where the coordination problem was that client context lived in advisors' heads and a decade of email. A field service company, where the same problem wore a completely different costume: dispatch, technicians, parts, and a scheduling system that couldn't see any of the other three. And our own back office, where it turned out we'd been living inside our own case study for years without noticing.

Nothing about those three overlaps on the surface. Different industries, different customers, different regulatory weight, different everything. What they had in common was the failure mode. In all three, the systems that were supposed to know something couldn't tell each other, so a person became the integration layer by default, and that person was usually the most expensive person available.

The five pieces Chuck described are the response to that failure mode, not to any particular industry. What changes between engagements is the content: the wealth firm's context is nothing like the field service company's context, and the rules a dispatcher operates under are nothing like the rules an advisor operates under. What doesn't change is that both need a place to put that context, a written statement of what the system may decide alone, a record of why, a gate, and a way to act on any of it without leaving the tool they're already in.

That's what makes it reusable. Not the content. The container.

Chuck: Why the line sits where it does

Now the ownership split, which is the part Skip has been circling.

The client owns the context, the rules, the agents, the data, the infrastructure, and the written record of every decision made along the way. We keep the method, the reference architecture, the reusable components, and the telemetry model.

The reason isn't generosity and it isn't a negotiating position. It falls out of what each thing actually is.

The context layer is the compressed operating history of one specific business. It has no value anywhere else, and that business cannot function without it. If we held it, then leaving us would mean re-deriving how your own company works from scratch.

That is not a partnership with an unfavorable clause in it. That is a hostage arrangement with a support portal.

The rules are your policy, written down precisely enough for a machine to execute. Whoever writes those rules is running the business. We can help you draft them, and we frequently do, because most businesses have never had to make their own policy explicit and the first draft is genuinely hard. But the moment we own them, we're making operating decisions for a company we don't run.

The agents execute against the context and the rules, so their ownership follows automatically. Same for the infrastructure and the decision record.

What that leaves us is everything that is worth nothing without a business inside it. A method is a way of working. A reference architecture is a shape. Reusable components are parts that do nothing at all until they're pointed at somebody's context. A telemetry model is a way of asking whether outcomes improved, not the outcomes themselves. None of it holds anyone hostage, because none of it contains a business.

That is the test I'd apply to any firm you're evaluating, including us. Ask what they keep. Then ask whether the thing they keep would still be worth something if you were not their client. If the answer is yes, you're the leverage.

Skip: The exit test

Here's the version of this you can actually run on a vendor, and it takes about thirty seconds.

Ask them what you walk away with. Not whether you can leave. Everyone says you can leave. Ask what you're holding the day after.

With us, the answer is specific. You keep the context in your own store, on your own infrastructure. You keep the written intent and every decision record, which together are the reason a new team could pick the system up without a discovery phase. You keep the agents and the running system. Nothing turns off, because there is nothing of ours in the middle of it to turn off.

What you don't keep is us, and you don't keep future versions of the components as they get better. That's the real trade and I'd rather state it plainly than pretend the relationship has no value in it.

We're worth paying for because of what we know how to build and how quickly we can build the next thing, not because we're standing on the power cord.

I've asked the walk-away question of vendors on behalf of clients more than once, and the tell is never a bad answer. It's a slow one. A firm that has thought about this line answers immediately, because they had to decide where it went in order to build anything. A firm that hasn't will tell you about their partnership philosophy.

Chuck: What we still don't know

I'm not going to end an architecture piece pretending the architecture is finished.

Three open items, honestly. First, every business we've built this in is under a certain size, and I don't know where the shape breaks. I suspect the written-intent piece is the first thing that fails at scale, because at some headcount you can no longer have one coherent statement of what the system may decide, and you get competing ones by department. We haven't hit that wall yet. We will.

Second, we still don't know how two of these layers behave when they have to coordinate with each other, built by two different firms for two different parts of one company. I raised that a month ago and we're no closer.

Third, and this is the one that sits least comfortably: the reusable components get better because of client work, and the line we've drawn means clients get the improvements without owning them. That's defensible, it's how every practice in every field has ever worked, and it's still an asymmetry that favors us. I'd rather name it than let someone discover it and assume we were hiding it.

Next up: we're going to take the exit test Skip described and run it on the systems we've been telling you to own, including where our own answers are less clean than we'd like. Less blueprint, more stress test.