Most companies can now show you an AI dashboard. Licenses bought, weekly active users, a few pilots with good demos. Ask the CFO which line of the P&L moved, and the room goes quiet.
That gap is the real problem. The models are good enough. The tools are mature. What is missing is a method that connects AI to a number the business already cares about, then builds the system that moves it, then keeps it from breaking.
I build software where failure is expensive. I architected an enterprise sales platform at Level 3 Communications and Lumen Technologies that went from $0 to $500 million in four years, with renewal systems spanning more than 1,000 product lines. Before that I built message-switching software serving the FBI, the DOJ and state law enforcement agencies, and did engineering work for the Department of the Interior under federal security clearance. More recently, my team built a governed AI knowledge system from 7,519 records that now answers more than half of a client's customer questions, with zero errors on a 370-question QA suite.
This blueprint is what that work taught me, written for the CEO, COO, CMO and CTO who have to make AI pay. It has a destination, one prerequisite and six moves.
The destination: a company where every cycle gets cheaper
The goal is a company that compounds. Each quarter, the systems learn from the last one. A question answered once never costs a person an hour again. A renewal pattern found in one product line runs across all of them. A correction made by an expert is captured, approved and reused.
In the Leverage Diagnostic we call this stage Compounding. Many companies sit two stages back, at Assisted: AI helps individuals, while the company still runs the old way. The distance between those stages has little to do with which model you license. It comes down to where you point AI, what it can see, how it fails, how it spreads and how buyers see you.
The prerequisite: one owner, one number
Before any of the moves, someone has to own a business result. An "AI champion" who runs tools and training does not count. I mean a named executive accountable for a number the CFO already reports: revenue per employee, gross retention, cost to serve, cycle time.
When AI programs stall, the cause is rarely technical. It is a program measured on adoption, so it produces adoption. People log in, try the assistant and go back to the old way, because everything they are paid on still rewards the old way.
The test is simple. Write down the number. Write down who owns it. If either line is blank, that is the first project.
Move 1: Start from the money
A business can grow in only three ways: more customers, larger transactions or more frequent transactions. Most AI programs aim at the first, because new-customer acquisition is the most visible. It is also usually the most expensive.
The platform I architected grew to $500 million on the other two. Renewals, rerates and upsells, routed to the right person at the right moment, across more than 1,000 product lines. The money was already inside the customer base. The system made it visible and made sure someone acted on it.
Most companies have the same pattern hiding in plain sight:
- Contracts that renew on autopilot at old prices
- Customers who bought one product and were never offered the second
- Dormant accounts nobody has contacted in a year
- Quotes that sit for days because pricing needs three approvals
Start there. Before anything is built, agree with finance on the number the system must move and how it will be measured. If the number cannot be checked, the result cannot be defended, and the program will be cut in the first bad quarter.
Move 2: Find the constraint
Every operation has one step that limits everything downstream. Speed up any other step and the work just piles up in front of the bottleneck. This is the oldest lesson in operations, and AI programs ignore it constantly.
Teams automate what is easy to automate: meeting notes, email drafts, first-pass research. Those are real savings for individuals. They rarely move the company, because the constraint was somewhere else, in an approval queue, a pricing decision, a handoff between sales and delivery, or one senior person every hard question routes to.
To find the constraint, look for where work waits. Ask your teams three questions:
- What are you waiting on most often?
- Which questions only one or two people can answer?
- Where does work get redone because information was missing?
The answers point to the step worth engineering first. One well-placed system there is worth more than fifty assistants anywhere else.
Move 3: Build the company brain
AI is only as good as what it can see. Most company knowledge is scattered across email, chat, documents, the CRM, call recordings and the heads of a few long-tenured people. An agent working from part of that picture delivers confident wrong answers, and after the third one your team stops trusting the system.
The fix is what the industry has started calling a company brain: one governed, current source of what is true about your customers, products, people, policies and decisions. Agents read from it, and approved learnings flow back into it.
Three properties separate a company brain from a document dump with search on top:
- Every fact has a source, an owner and a date. When two documents disagree, the system knows which is newer and which is authoritative, and it flags the conflicts it cannot settle.
- It separates history from current truth. Last year's price list is history. The current one is truth. An agent must never confuse them.
- Access follows your rules. People and agents see only what their role allows, and new information becomes approved guidance only after a person with the authority approves it.
This is the system my team built for the client above. It was built from 7,519 historical customer questions. Before it went live, it had to answer 370 real questions with known answers, and it did so with zero errors. It now handles more than half of the questions that used to reach staff.
Move 4: Engineer for failure
The law enforcement message switch taught me the rule I still build by: assume every component will fail, and decide in advance what happens when it does.
AI systems fail in new ways. They can be fluent and wrong. So the controls have to be designed in from the first day:
- Humans first. On day one, every AI answer goes to a person for review. Autonomy is earned with evidence, workflow by workflow.
- A test suite on known answers. Build a set of real questions with verified answers, including the hard cases: changed policies, ambiguous names, conflicting sources. The system must pass it before launch and after every change.
- Escalation by design. When the system is unsure, it routes to the right person with the context attached. Our knowledge system uses three layers of escalation, and the person always sees why the question came to them.
- Guardrails in code. Rules that must hold every time, like what may be said to a customer, are enforced by deterministic checks on the output.
- An audit trail. Every input, answer and correction is logged. Your security team and your auditors will ask for it, and the logs are also how the system improves.
This is what lets a regulated or cautious company say yes. It also keeps the program alive after the first mistake, because the mistake is caught, routed and fixed in the open instead of becoming a story about why AI cannot be trusted.
Move 5: Scale it
A pilot that works in one team is a proof. Leverage comes from rolling it across the business.
The renewal systems on the $500 million platform were built once, as a pattern, then applied across more than 1,000 product lines, with the rules for each line held in data instead of code. That is the difference between a project and a platform.
Design every system you build to be copied:
- Separate the pattern from the specifics, so the second product line, region or team is configuration instead of a rebuild.
- Measure every rollout against the same number from Move 1, weekly.
- Turn what your best people do into written playbooks, then into systems. Your playbook is software waiting to be compiled.
Scaling also means changing how teams are built. The fastest ones pair a small group of builders with the people who own each process, so the knowledge of how the work really happens goes into the system.
Move 6: Be the answer
The first five moves work inside the company. The sixth faces outward.
Buyers increasingly ask an AI assistant who the credible vendors are before they talk to sales. Whatever the model says about your company, accurate or not, shapes the shortlist. Most companies have never checked what each type of buyer is told: what the CFO hears about your pricing, what the CTO hears about your security, what the operations lead hears about implementation.
Being the answer is engineering work. It means publishing clear, specific, verifiable evidence about what you do, for whom and with what results, in the places models read. It means consistent facts across your site, profiles and third-party sources. It means measuring what AI says about your category every month and fixing the gaps the way you would fix a broken funnel step.
The company brain from Move 3 helps here too. A company that knows what is true about itself can say it clearly to the outside world.
Which move is yours?
Most companies are strong in one or two moves and stuck in another. The symptom usually tells you which.
| If this sounds familiar | Start with |
|---|---|
| "We have AI everywhere and no P&L impact." | Move 1: start from the money |
| "AI saves people time, but nothing ships faster." | Move 2: find the constraint |
| "The assistant gives answers nobody trusts." | Move 3: build the company brain |
| "Legal and security keep blocking launches." | Move 4: engineer for failure |
| "The pilot worked, then never spread." | Move 5: scale it |
| "Buyers come in with wrong ideas about us." | Move 6: be the answer |
Where to start: the first 30 days
You can begin without a transformation office. You need one number, one constraint and one system.
- Week 1: Find the lever. Score where revenue, time and knowledge are leaking. Pick the one number that matters most, and agree with finance how it will be measured.
- Week 2: Map the constraint and the knowledge. Interview the people doing the work. Find where work waits and which questions only a few people can answer. Gather the sources the first system needs.
- Week 3: Build and test. Stand up the first system on that constraint, inside your security rules. Build the test suite of known answers and run it until it passes.
- Week 4: Go live with humans first. Every output reviewed. Measure against the baseline. On day 30, decide to continue or stop, with evidence in hand.
That is the shape of our 30-Day Leverage Pilot, and you can run the first week yourself today. The Leverage Diagnostic takes about six minutes, scores the six places leverage hides, and prices the gap with the math shown.
Questions leaders ask
Is this a technology project or a management project?
Both, and the management part is harder. The build is the easier half. The harder half is choosing the right number, giving one person ownership of it and changing what people are measured on. Without that, a good system goes unused.
Do we need a company brain before we can start?
No. Start with the knowledge one workflow needs. The first system defines the structure, and every system after it adds to the same brain. Trying to capture everything before shipping anything is how knowledge projects die.
How do we keep sensitive data safe?
Build inside your accounts and your guardrails from day one: your approved vendors, your access controls, your logging. The company brain is your company's memory, so it should live where your security team can see it.
How do we know it is working?
By the number you agreed on in Move 1, measured against a baseline taken before launch. Adoption and activity are useful diagnostics. Results are what the CFO can audit.