The Company OS
Building it is the easy half.
How an engagement with me actually runs.
Most internal AI tools die at single-digit adoption. Not because the model is bad, but because nobody trusts the output enough to send it and the thing never learned the company’s actual facts. This is the process I use to attack both, written from a real engagement rather than from a framework.
Business first. Then architecture. Then adoption.
Every engagement runs in that order, because the order is the point. The business comes first: how the company actually operates, and where AI genuinely earns its keep. The architecture comes second, shaped by those answers rather than by whatever is fashionable this quarter. Adoption comes last and gets the most attention, because a system nobody uses is a strategy document with a hosting bill.
Don’t hire me to create an AI strategy deck. Hire me to take the company from strategy through implementation and adoption. The deck is the cheapest part of the work, and on its own it changes nothing about how anyone works on a Tuesday.
Five moves, then I leave
None of this is proprietary and none of it is complicated. It is mostly a refusal to skip the unglamorous parts, which is where adoption is actually won or lost.
1. Open with a diagnostic question, not a pitch
The first question I asked a Florida reserve-study firm was not what I could build. It was what the agency he paid a thousand dollars a month was actually doing for him.
Blog posts, page creation, analytics. Two follow-up questions later the real picture came out: he was writing most of the blog content himself, supplying every image, and doing the analytics on his own. He was paying a thousand a month for coordination on work he was already doing.
He diagnosed his own problem while answering me. That is worth more than any diagnosis I could hand him, because he believed it.
2. Build something and show it
I did not fully understand the need yet, so rather than write a proposal about it I went and built. A working artifact beats a scoping document in two ways: it is more convincing, and it surfaces misunderstandings early enough that correcting them is cheap.
A proposal gets agreed to. A working thing gets argued with, and the argument is the useful part.
3. Design the intake so a non-technical person can succeed at it
Two instruments. A questionnaire covering the company, the pain points, and critically what the owner is good at and what he is not, because that pair decides which work the system absorbs and which stays human.
Then a shared folder with the structure already built. Every folder made in advance, and one instruction: drop everything in. Collateral, files, old sites, all of it.
The structure does the sorting, so someone non-technical never has to make classification decisions he is not equipped to make.
4. Build it all in one pass
Extract the files, then build the whole thing together: the constitution, the facts layer, the skills, the guardrails, the brand system, the agents, the repository, the deploy pipeline, and a new website alongside it.
In one pass because the pieces are not independent. A brand system that the site generator cannot read is a PDF. A guardrail that the build does not enforce is a suggestion.
5. Treat the handoff meeting as the deliverable
Not a document drop. One working session where I walk through every part of the system, then set up his account: pick the plan, change the settings, connect him to the model, the repository and the deploy target.
Then we test things live, together, so he watches the pieces work rather than reading that they do.
Anything he does not understand becomes a written guide that same day. The documentation is generated from observed confusion rather than from my guess about what would confuse him.
And then I leave
The goal is that they run it without me. I am not building a dependency, and a system that only works while I am in the room is a system I built wrong.
The test is simple and it is not flattering to me: does it still get used in month three, when the novelty is gone and I am not around to ask.
A one to three person team on a properly built system operates like a team of fifteen
That is the claim, and I will not make it without something behind it.
The saving is the client’s, not my revenue. That engagement is pro bono, and it is worth saying so plainly rather than letting a dollar figure imply otherwise.
The technical build is about half the job
The other half is the list below. It is closer to what this work actually is than any description of a stack, and it is where the time goes:
- Asking the question that lets someone diagnose their own problem, rather than presenting them with mine
- Building before I fully understand, then correcting quickly and in public
- Designing intake so a non-technical person can succeed at it on the first try
- Treating what someone is bad at as an equally important input to what they need
- Configuring their tools as part of the job, rather than calling it out of scope
- Writing documentation from observed confusion instead of assumed confusion
- Turning every prose rule into something a build can enforce, so quality does not depend on anyone remembering
Adoption is not a training problem and it is not a change-management problem. It is a trust problem. People stop using a system the first time it confidently tells them something wrong, and they do not come back. Everything above is in service of the system being boring, correct, and honest about what it does not know.