Written for the person who has already been pitched twice this quarter and is still not convinced.
This page is the argument the rest of the site is built on. It starts with a standoff that a great many organizations are living inside right now, moves to a diagnosis that is less flattering than the usual one, and ends with a way of working that treats a sceptical buyer as correct rather than as an obstacle.
Every organization wants AI, and many have banned it. Not because it does not work, but because using it means sending their data to somebody else's computer. So the work goes on anyway, in browser tabs, with no governance at all.
That sentence is the whole market in three lines, and the important part is the third one. A ban does not remove the demand. It removes the visibility. The organization ends up with the exposure it was trying to avoid, plus the disadvantage of not being able to see it, plus the quiet knowledge among its staff that the policy is not survivable.
Nobody wrote the restriction out of hostility to the technology. They wrote it because a consumer assistant's data path cannot be scoped by the person who has to answer for it, and because a security review that cannot describe where content goes has to say no.
The work still has a deadline. A person with a document and an hour will use whatever gets the document finished, and consumer assistants are excellent. Shadow use is not indiscipline. It is competence meeting an absent alternative.
Staff working around the policy are the strongest demand signal in the building. They have already run the pilot, at their own expense, and concluded it is worth the risk. The remaining question is only whether that happens inside something you govern.
The choice on the table is almost never AI or no AI. It is unmanaged adoption or a governed operating capability. Framing it as the former makes waiting look free, and waiting is the one option whose cost nobody is measuring. We wrote that comparison out in full.
Inside one organization the problem is rarely abstract. It has two people in it, both doing their job properly, and their jobs point in opposite directions. Nothing moves until they can both say yes to the same controlled capability, which is why feature lists do not close this and an architecture they can check does.
Owns the downside of a yes. Has been asked to approve something whose data flow they cannot describe, by people who will not be blamed if it goes wrong. They are not opposed to AI; they are opposed to uncontrolled AI. The winning move is to offer them more control, not more reassurance.
Owns the downside of a no. Watches throughput, rework and handoffs, and watches peers whose staff are allowed to use these tools. The cost of saying no is real and lands on them, but it arrives slowly and never as a single incident, so it is easy to discount.
The security owner carries the risk if they say yes. The operating owner carries the cost of saying no. That standoff is the opportunity.The problem stated by role, not by feature
They have an operating-capability problem. The usual response to falling behind on AI is to add: another assistant, another pilot, another model, another proof of concept in another corner of the business. Each addition is defensible and the sum is a collection of disconnected tools with different security models, different data paths and no shared way to turn any of it into work that gets done.
Adding tools, pilots and models is solving the wrong scaling problem. The thing that actually compounds is the governed ability to turn the organization's own knowledge and its own way of doing things into new capabilities, repeatedly, without launching a fresh platform project each time. That is an operating layer, and it has an owner, an address and a bill.
| After eighteen months | More tools, more pilots | A client-owned operating layer |
|---|---|---|
| What accumulated | ✕Subscriptions and vendor reviews | ✓An environment, an index, and capabilities on it |
| Where your content sits | ✕Across several vendors' accounts | ✓At rest in one account you own |
| Who can answer the security review | △Each vendor, about itself | ✓You, from your own configuration |
| When the model market moves | △You wait for each vendor | ✓The model is a setting behind your own layer |
| What a second capability costs | ✕Another procurement | △A deliverable on a foundation that already exists |
| What you hold if the supplier stops | ✕An export, at best | ✓The account, the platform and its source |
Judgments, not measurements. The right-hand column describes how a deployment is built and owned; it does not assert an outcome we have measured for you. Composable AI and ownership and exit set out the mechanisms behind rows four and six.
The order matters more than any single component. Each stage makes the next one cheap, and each stage is useful on its own if you stop there. We do not start with the ambitious capability, because the ambitious capability is the one that needs the trust the first two stages produce.
One organization, one cloud account in your name, billed to you directly by your cloud provider. A content policy that cloud identity policy makes mandatory on every inference call, as a deny rather than an app setting. An administration area for users, roles, grants and quotas. Branded as yours.
Chat over frontier models with per-person metering, and an optional knowledge base that answers with citations to your own documents and declines when retrieval finds nothing. It is the least autonomous thing we ship, which is exactly why it goes first. Its limits are on the page, not in a footnote.
Then the slower work: sitting inside the business, learning its handoffs, approvals, exceptions and bottlenecks, and turning the highest-value parts into governed capabilities that run on the platform you already own. Most of them do not call a model at all, and that is a feature.
It is not a pilot you have to buy twice. The environment stood up in stage one is the production environment; stage two runs on it; stage three extends it. The engagement path gives you gates instead of dates.
A small supplier asking a large organization to put its content somewhere new has a trust problem it cannot talk its way out of. The only durable answer is to make trust unnecessary at the points where it would be load-bearing.
You would not, structurally, and that is the point of the ownership model. The account is yours, the billing relationship with your cloud provider is yours, and the deployed platform and its source sit inside it. If we stop, you lose us, not the platform. Running it afterwards needs a competent cloud engineer, which is why infrastructure as code and runbooks are deliverables rather than courtesies.
On size: we are a founder-led practice with a small bench of contractors. What gives the work reach is the platform and the deployment factory, not headcount. Continuity is written up here.
A product, operated as a service, with engineering available on top. Every deployment comes from a tagged release and a clean checkout of the same codebase, and the deployment factory refuses a tag that is not on the mainline. The bespoke work sits above that line and is scoped per deliverable, so it strengthens the product rather than replacing it. The factory and the fleet.
Data at rest stays in the account you own. Inference is the exception, stated exactly: a managed model service processes the content of a request, under terms where prompts are not used to train models and are not shared with the model vendors. Where a request may run is a configured choice, refused in words when a model has no route inside your pinned region. The boundary, as a defined term.
A $2,500 strategic assessment, bounded, and you keep the deliverable whether or not you proceed. Deployment starts at $2,500 and typically lands around $5,000 once the solutions pipeline is scoped, invoiced by milestone with nothing at signing. Managed operations are $500 a month, cancellable. Compute is billed to you by your cloud provider at their list price. The full pricing page.
It is: own the environment, inspect the evidence, and keep the exit open. Everything on this site is an attempt to make those three things checkable rather than believable.
A bounded assessment of where governed AI creates value in your organization and what currently blocks it. You keep the deliverable whether or not you go further.