The question in front of the board is not which assistant to buy. It is where the control point for this capability is going to sit.
Tools are bought, used for a while, and replaced. A capability is the governed ability to turn your own knowledge and processes into new capacity, repeatedly, and it is the only version of this worth a board's attention. This page is written for the person who has to authorise it and the group that has to oversee it.
Most organizations do not have an AI tool problem. They have an operating-capability problem, and the two have different answers. The durable advantage is not access to one model, which everyone has. It is the governed ability to turn organizational knowledge and process into new capability, again and again, without a new vendor each time.
A subscription here, a pilot there, each with its own security model, its own data flow and its own login. The estate grows, the governance does not, and no single purchase is large enough to trigger a proper review. This is how most firms arrive where they are.
One governed environment, one identity, one policy, and a way to add a capability to it whenever a process is worth rebuilding. The second thing you build is cheaper than the first. That is the whole economic argument, and it only holds if the foundation is owned.
Whoever holds the account, the identity and the policy holds the capability. If that sits inside a vendor, the firm is renting its own operating knowledge back. If it sits in infrastructure the firm owns, the vendor becomes replaceable, which is the correct arrangement.
You're not buying seats. You're buying a private AI platform on your own cloud, yours to keep.The commercial shape, in one line
Organizational velocity is the objective: more transactions with the same team, fewer errors, faster handoffs, and less work trapped in one person's head. It is measurable, it belongs to you, and it is not the same thing as AI adoption.
org.tech is a founder-led practice: one principal with a small bench of contractors. The risk is real, and it belongs at the top of the page rather than in a clause. What follows is the structure that bounds it, and every element is something you can verify before signing.
The cloud account is in your name, the root credentials are yours, the provider bills you directly and the data sits at rest in your account. There is no lever we could pull that stops your platform running, because the platform is not on our infrastructure.
Infrastructure as code, runbooks and architecture records are contracted deliverables rather than goodwill. Running the platform afterwards needs a competent cloud engineer, and we say that plainly rather than implying a business could operate it with nobody technical.
$500 a month, cancel anytime. The fee buys managed operations and continuous improvement, not access to your own system. You lose us, not the platform, and that sentence is the whole of the commercial commitment.
Nothing reaches production on your deployment without a named administrator on your side approving an exact artifact hash. Our own automation cannot promote: continuous integration publishes to staging only. That gate sits with you, and it does not depend on how large we are. Read the full statement.
If a board authorises this, it should authorise it conditionally. These are the conditions we would want attached if we sat on the other side of the table, and we will put them in writing.
| Condition | Why it matters | Who holds it |
|---|---|---|
| Name the accountable owners | One for the business outcome, one for source data, one for finance, one for risk. Engagements drift when these are implied | The firm |
| Approve baseline measures early | A measure agreed after a build is a measure chosen to flatter it | The firm, before we build |
| Prioritize by outcome, not novelty | The interesting capability and the valuable one are rarely the same. Novelty is how pilots die | The executive sponsor |
| Keep deterministic processes deterministic | Inference does not belong in a zero-error critical path. Sometimes AI is the runtime; sometimes it is the tool used to build the runtime | Jointly, at design time |
| Preserve ownership of account, credentials and billing | This is the condition that makes every other one enforceable. Do not let it be traded away in procurement | The firm, permanently |
| Require transferable documentation as a deliverable | Infrastructure as code, runbooks and architecture records, delivered as work product rather than promised | Contracted from us |
| Pause expansion if quality falls | Both parties should be able to stop. A capability that is expanding while its output is degrading is the failure mode worth guarding against | Either side, at any time |
These are governance conditions, not contract terms we are quoting at you. Take them to whoever drafts your agreements, including for a supplier that is not us. Anyone who resists the fifth one is telling you something important.
Sponsor the relationship rather than a project, because the second capability is where the economics are. Name one owner for business outcomes and one for source data, and say both names out loud in the same meeting. Tell the firm what the objective actually is: organizational velocity, not AI activity. That last one costs nothing and changes how every subsequent decision gets made.
$2,500 for the strategic assessment, which is bounded and whose deliverable you keep whether or not you proceed. Deployment starts at $2,500 and typically lands around $5,000 once scoped, invoiced at milestones with nothing at signing. Managed operations are $500 a month, cancellable. Compute is billed to you directly by your cloud provider at list price. The whole ladder.
No. No baseline exists until you set one, and a number we invented would be the least defensible thing in the pack. What we will do is help build the baseline in the first phase and report against it monthly, as a working target rather than a promised result. Written for your CFO here.
Yes, and you should. There is a live demo of the running product rather than a deck of screenshots. For a board conversation the more useful artifact is usually the assessment deliverable: a network topology and data-flow map of your own organization.
Each capability page states its limits beside its claims, and anything built but not yet proven at client scale carries a hedge on the page. What we do not claim is the fastest place to test that, and the live demo is the fastest way to test the rest.
A bounded first step with a deliverable your board can read: where your data goes today, and what a governed capability would change.