One question decides it, and it is not budget, headcount or how advanced anybody feels.
Where does the model sit, relative to your data?
We sell two products and they answer that question in opposite directions, so this page exists to send you to the right one quickly, including when the right one costs us the larger engagement. Nothing below is a matrix designed to make both look necessary.
Everything else is downstream of one answer.
Ask your security owner a single question: may document content reach a third-party AI vendor at all, under contract, with your existing agreement governing it? Not "would we prefer it did not". May it, or may it not.
If the answer is no, the gateway is not a smaller version of the right product. It is the wrong product, and every hour spent evaluating it is an hour that makes the eventual platform conversation harder.
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 line both products were built around
A vendor with two products has an obvious incentive to keep both in play. Ours runs the other way: an engagement that starts on the wrong side of that question ends in a security review that finds exactly what our own limits page already said. We would rather lose the smaller sale in the first meeting than the larger one in the third.
The seven questions that actually decide it.
| Question | orgOS · the platform | The operational knowledge gateway |
|---|---|---|
| Where does the model run | Reached from a cloud account you own, through the managed model service, on a governed route your policy makes mandatory. | At your assistant's vendor. The gateway server runs no language model at all. |
| Does a third-party AI assistant vendor see content | ✕No such vendor is in the path. Data at rest stays in your account; prompts are not used to train models and are not shared with model vendors. | ✓Yes. What a tool returns travels to them on every call, under your agreement with them. |
| What your staff use day to day | A white-labelled environment in your own brand: chat, an optional knowledge base, and business modules on isolated origins. | The assistant they already use, unchanged. Nothing new is installed and nothing new is learned. |
| Residency claims available to you | △Configurable, pinned to your region when you need it, with a real capability cost: in a Canadian pin the in-region set is previous-generation. | ✕None. We make no residency claim for this product in any wording. |
| What it costs to run, before inference | Roughly $5 to $10 a month on your cloud bill at Baseline, about $110 a month on the private-network tiers. Light team usage has run an estimated $40 to $120 a month all-in. | Tens of dollars a month on your cloud bill, nothing per seat, plus the assistant subscriptions you already pay for. |
| What is recorded | Model invocation logging on every call: model, caller, latency, token counts, deliberately without prompt or answer text. Per-person metering and quotas that fail closed. | △Writes are attributed with who and when. Reads and tool calls are not individually recorded today. |
| What you own at the end | The account and the deployed platform, its source and its runbooks. If the service stops, you keep running it. | The account and everything in it: mirror, index, confirmed facts, canonical tables, generated artifacts, plus the deliverables. |
Both products run in a cloud account you own and are billed for directly, and we hold no client data on our own infrastructure in either case. The difference is what the account contains, and who else is in the path.
Five questions. Stop at the first one that lands.
- 01Stop here
Must content stay away from a third-party AI vendor?
A policy, a client agreement, a regulator's expectation, or simply a security owner who will not sign. If any of those is true, stop: you need orgOS. The gateway's whole design sends tool results to an outside assistant, and no configuration changes that.
GateIf this is a yes, the rest of this page is not your decision to make.Decides: your security owner - 02Prerequisite
Do your people already use an approved commercial assistant?
The gateway attaches to an assistant that already exists in your organization, on a plan that supports authenticated custom connectors. If there is no approved assistant, there is nothing to attach to, and buying one in order to buy this is the wrong order to do things in.
GateIs the assistant sanctioned, paid for, and in daily use?Decides: your IT owner - 03Shape of the work
Is the bottleneck documents, or applications?
If people spend their day finding, reading, reconciling and drafting from documents, that is the gateway. If what you need is governed business software over your own records, with its own screens, its own users and its own workflows, that is the platform's module runtime, and most of those modules do not call a model at all.
GateCould a well-written internal application remove this work entirely? Then build that.Decides: your operations lead - 04Obligations
Do you need a residency pin, an account audit trail, or a mandatory content policy?
Those are platform properties: residency configurable to your region, account-level audit logging on the higher posture tiers, and a content policy that cloud identity policy makes mandatory on every inference call rather than an application setting somebody can switch off. The gateway offers none of the three, and pretending otherwise would contradict its own limits page.
GateIs any of the three a condition of sign-off?Decides: your security owner - 05Then the gateway
Do you need figures that reconcile, inside the assistant people already use?
If you have got this far, the case for the gateway is specific: your own documents reachable under your rules, your own methods served as skills, totals computed in SQL over every row with the query attached, and a workbook that refuses to publish when reconciliation fails.
GateIs there one frequent, document-bound workflow worth connecting first?Decides: your operations lead
Leading with the gateway in a room that has banned external assistants is the wrong move.
It is not a softer entry point into a cautious organization. It is the one product in our catalogue that room has already said no to, and offering it spends the trust the other product depends on.
- 01What that room actually needs. An environment in an account they own, where the model is reached on a governed route and no third-party assistant vendor is in the path. That is the platform, and it is a bigger, slower, more valuable conversation.
- 02What the standoff is really about. Their people are using assistants anyway, in browser tabs, ungoverned. The answer to that is not to legitimise the tab. It is to give the work somewhere governed to happen.
Two products that share a sign-in, and nothing else.
They are siblings, not a module and not an add-on. Where both run in the same account, they share exactly one thing: the identity estate, so a single corporate sign-in decides what a person sees in both. There is no shared knowledge base, no shared compute, no shared inference path, and no on-ramp designed in either direction.
The ones that come up during the decision.
01Can we run both?
Yes. It makes sense when different work has different boundary requirements: sensitive work inside the platform, document-heavy work in the assistant people already use. It only saves you anything if the sign-in estate is shared, which is the single integration point between them. It is not a package we push, and buying one does not discount the other.
02Is the gateway a cheaper way to try org.tech?
No. Both start from the same strategic assessment, and the gateway has no published price because its scope is decided by your source inventory. Choose on the boundary question and the shape of the work, not on a guess about which is smaller.
03Our security owner says maybe. What then?
Maybe usually means the boundary statement has not been written down yet. Phase one of a gateway engagement produces exactly that: which libraries, which classes of data, what travels where, and whose agreement governs each leg. It is a document your security owner can reject cleanly, which is more useful than a pilot that quietly proceeds.
04What if we pick wrong?
You own the account and the deliverables in either case, so nothing is stranded at a vendor. But the honest answer is that switching is not free: the platform and the gateway share only identity, so a move is a new deployment rather than a migration. That is precisely why this page is a decision page and not a brochure.
05Where do we read the rest?
The platform overview for orgOS, the gateway overview for this one, the gateway's limits and the platform's for the two claim ledgers. If you would rather look at something running, the live demo is our own deployment.
- 01orgOS, the platformA governed AI environment in a cloud account you own, where no third-party assistant vendor is in the path.→
- 02The operational knowledge gatewayYour files, governed, for the assistant your people already use.→
- 03The strategic assessmentBounded work that decides which of the two fits, and what it would govern.→
- 04Where AI does not belongThe third answer, when the honest recommendation is neither product.→
Your AI, inside your control ·
One bounded piece of work decides which product fits, what it would govern, and what it would cost to run. You keep the deliverable whether or not you proceed.