
Every AI tool this firm had tried worked in the demo and died in the building. The tools were fine. Nothing connected them. The fix was not a better tool. It was an operating system.
The founder of a boutique wealth management firm sat across from me with a spreadsheet of every AI tool the firm had paid for in the last eighteen months. There were eleven of them. A scheduling assistant. A message-triage bot in the client portal. An ambient scribe for review-meeting notes. A billing tool that promised to chase down planning-fee renewals. A phone agent for the front desk. Each one had been bought to solve a real, specific pain. Each one worked in the demo. Not one of them had changed how the firm actually ran.
I want to be precise about what this kind of firm is, because the shape of the business matters to the rest of this story. It is flat-fee concierge financial planning. Clients pay an annual fee for a small advisor panel, same-day access, and an advisor who answers the phone at nine at night. The whole promise is attention. A client is paying for the feeling that someone is paying attention to their money specifically. That promise is also the operating problem, because attention does not scale by buying more software. It scales by coordinating the people and the information around each client, and that is exactly the thing none of the eleven tools were doing.
What this founder had was not an AI problem. It was a coordination problem wearing an AI costume.
What this founder had was not an AI problem. It was a coordination problem wearing an AI costume. The scheduling bot did not know what the triage bot knew. The scribe wrote a beautiful note that sat in the file while the front desk re-asked the client the same three questions the next morning. Every tool had its own little memory and none of them shared. The firm had automated eleven steps and connected zero of them. So I brought Chuck in to look at the wiring, because by this point I was sure the problem was underneath the tools, not in them.
This is a Field Notes piece, the first of two where we drill into one kind of business. The details are composited across more than one engagement, the way we always do it, so no client recognizes themselves. The pattern is real. The eleven tools are real, give or take one.
When Skip brought me in, the first thing I asked for was not a list of the tools. It was a single client. Walk me through one member, from the message they sent at nine at night to the moment their problem was actually resolved, and show me every system that touched them on the way.
It took the firm most of an afternoon to reconstruct that path, which told me everything. The client's history and message thread lived in the CRM. Their custodian paperwork came in through the custodian portal that still faxed, in 2026, into a queue an ops associate checked twice a day. Their financial plan sat in planning software, their signed agreements in a separate document vault, and their planning-fee billing lived somewhere else entirely. The "context" for that one client was scattered across five systems that did not talk, and the only thing holding it together was a client service associate named in nobody's architecture diagram who happened to remember things.
The agent was being asked to make decisions blind, so of course the firm could not trust it with anything that mattered.
This is the part that matters, and it is the same lesson from Series 1 when we wrote about orchestration being the bottleneck inside a codebase. The bottleneck was never the typing. It was the coordination. Here the bottleneck was not any single tool's intelligence. Every one of those eleven tools was individually fine. The bottleneck was that there was no shared context for the AI to act on. You cannot ask an agent to safely triage a nine-p.m. message if the agent cannot see the account that rebalanced that afternoon, the withdrawal the client requested last week, and the note from the review meeting two days ago. The agent was being asked to make decisions blind, so of course the firm could not trust it with anything that mattered.
So we did not start by adding a twelfth tool. We started by building the layer that the eleven were missing.
We ran the same loop here that we run on a software build. CRAFT is not a code methodology that happens to work on operations. It is a coordination methodology, and software was just the first place we needed it. Applied to this firm, it looked like this.
Intent first. Before any agent touched a client message, we wrote an Intent Contract for the work, the same way we write one before any feature. Not "automate triage." That is a wish, not an intent. The contract said exactly which messages an agent could resolve on its own (routine scheduling, an administrative confirmation), which it could draft a response to for a human to approve (a general planning question), and which it had to hand straight to a human untouched (anything that involved moving or withdrawing money, anything that referenced a death or a divorce, anything from a client flagged vulnerable, plus a short list of words the chief compliance officer chose herself). The acceptance criteria were compliance-driven, and the CCO owned them. No work without intent, exactly as we wrote in Series 2, except the intent here protects a client instead of a release.
A context graph the agents could actually read. We built the shared layer that the eleven tools never had. One place where a client's history, recent messages, open paperwork, portfolio, planning-fee status, and advisory-team notes resolved into a single current picture an agent could query before it did anything. This is the unglamorous center of the whole project. It is also the thing that turned the existing tools from eleven islands into something that behaved like one system. The scribe's note was now visible to the triage logic. The triage decision was now visible to the front desk. The client stopped getting asked the same three questions.
A gate before anything reached a client. Nothing client-facing went out without passing what we call the Fortify Gate. In a code release the gate asks whether a change is safe to ship. Here it runs on every interaction, in real time, checking which intent tier this message falls into and what the agent is allowed to do inside it. A drafted reply to a planning question does not reach the client until a human advisor approves it. In a regulated advisory firm, human review of client communications is not merely good practice but a compliance obligation, which is part of why the gate is built the way it is. The gate is owned by the firm, lives in the firm's system, and is auditable. It is not a prompt we hope the model respects. It is a boundary the model cannot route around.
Telemetry on outcomes, not activity. And we instrumented the thing to measure what actually happened to the client, not how busy the agent was. More on that from Skip, because the number that mattered surprised both of us.
I expected the founder to be most excited about the message volume. The system was now resolving or pre-drafting a large share of inbound client messages, and the associates had hours back in their day. That is the number that sells the project. It is not the number she talked about.
Her advisors had stopped apologizing to clients. The context now arrived before the advisor did.
What she noticed first was that her advisors had stopped apologizing to clients. For two years, every other review meeting had started with some version of "sorry, let me pull up your file." The advisor walking into the meeting did not have the context, because the context was scattered across five systems and an associate's memory. Now the context arrived before the advisor did. The client who sent an anxious message at nine at night after a market drop got a same-night answer that referenced their recent rebalance and their cash reserve, because the system could see both. The attention the client was paying for, the entire premise of the business, finally showed up consistently instead of depending on whether the right associate was working that day.
That is the thing operators miss when they shop for AI tools. They are buying capability when the problem is coordination. The eleven tools added capability the firm could not connect. The operating system added coordination, and the capability the firm already owned started to compound. Client retention moved, and in a membership business retention is the whole game. The AI did not make the firm feel more human by being clever. It made it feel more human by making sure the humans always had what they needed in front of them.
Here is the part I would want to know if I were the operator reading this.
The hard work was not the AI. The agents were the easy part. The hard work was the context graph and the intent contracts, which is to say the hard work was deciding, precisely and in writing, how the firm actually wanted to coordinate client work. Most of the pain in that project had nothing to do with models. It was getting a room of smart advisors and their compliance lead to agree on which messages an agent could touch and which it could not, and then encoding that agreement somewhere a machine could enforce it at two in the morning.
There is no twelfth tool. Coordination is the part that is specific to your business, which means it is the part nobody can sell you off a shelf.
That is uncomfortable because it means you cannot buy your way out of it. There is no twelfth tool. The vendors selling the eleven tools are selling capability, because capability demos well and coordination does not. But coordination is the part that was missing, and coordination is the part that is specific to your business, which means it is the part nobody can sell you off a shelf. The firm owns that layer now. They own the context graph, the intent contracts, the decision records of what they chose to automate and why. We keep the method and the reference architecture we brought to build it. Both of those are true at once, and the line between them is the thing worth getting right in any engagement like this.
If you run a mid-market business and you have a spreadsheet of AI tools that each worked in the demo and none of which changed how you run, you do not have a tool problem. You have the same coordination problem this firm had, in your own costume. The fix is not the next tool. It is the layer underneath them, the one that holds your context in one place and enforces, in writing, how you want work to flow. That layer is boring to buy and decisive to own.
And if you are a founder building a product rather than running a firm, look again, because this is your problem too. Every AI feature you have shipped has its own little memory. The autocomplete does not know what the summarizer knows. The moment you have more than two AI features, you have a coordination problem, and the teams that win are the ones that build the shared context layer on purpose instead of discovering they needed it after the third feature shipped blind. Same disease, same cure, smaller building.
If the system only worked in boutique wealth management, it would not be an operating system. It would be a feature.
Next week, Chuck and I take the same operating system into a business that could not look more different from an advisor's office: a field service company with trucks, technicians, and a dispatch board that never stops moving. Same CRAFT loop, same coordination layer, completely different floor. The point of running these two back to back is that what carries over is the operating system, not the industry. If the system only worked in boutique wealth management, it would not be an operating system. It would be a feature.
AI that runs your business. Not the other way around.
Written by Skip Marshall & Chuck Griess
Learn more about our team