The honest version of who you would be buying from, written before you have to ask.
org.tech is one person, maybe two. That is a fact about the company, not an apology for it. The work that would normally need a team is done by a versioned product and a deployment factory, which means the person who answers your question is the person who wrote the thing you are asking about. What we will never do is describe a team we do not have.
Most firms in this market are either large enough that you will never meet the people who build your system, or small enough that what they sell is hours. org.tech is neither, and the difference is not scale. It is that the repeatable part of the work has been turned into a product and a factory, so the scarce part, which is judgment, is what you actually buy.
Everything below is a statement about the company. Everything the product does, and does not do, has its own page with the limits printed next to the claims.
A founder-led practice: one principal, with contractors brought in against a specific deliverable. You are talking to the person who designed the platform, deployed it, and will be the one on the call when something is wrong. There is no account manager between you and that person, and no bench of juniors to keep busy.
What we deploy is a single-tenant platform with a mandatory content policy enforced by cloud identity policy, per-person metering settled against the provider's own record, an isolated runtime for business applications, and a controls matrix mapping 17 technical rows to SOC 2 and ISO/IEC 27001 criteria. That is engineering depth, and it is the reason a two-person firm can answer a security review.
No programme, no discovery phase measured in quarters, no procurement theatre. The prices are published, the first step is bounded, and each stage releases on evidence from the one before it. If the honest answer is that governed AI does not earn its place with you yet, you get that answer in writing and you keep the deliverable.
org.tech is a managed service provider for private AI. We provision it, run it, maintain it and build capability on top, and you own it. The distinction matters commercially: a consultancy sells the hours, a product company sells the thing that removes them, and only one of those gets cheaper for you over time.
The reason a practice this size can operate production systems in separate cloud accounts is that no deployment is assembled by hand. Each one is a tagged release of one product, layered with your parameters, built by a factory that refuses to proceed when its own preconditions are not met.
They are evidence of engineering discipline, not of headcount and not of adoption. A tag is a release, not a feature, and a test count says how carefully the thing is defended, not how many organizations use it. Each of the four is read from a record: the release ledger, the test suite, the controls matrix and the generated catalogue.
org.tech came out of roughly twenty years in software development leadership and three concentrated years building AI automation. Over those three years the same two lessons kept repeating, and between them they explain every structural decision on this site: why the foundation is sold before the application, and why the work is a product rather than a programme of bespoke labour.
Organizations wanted AI and could not move past three things: security, ownership and governance. The interesting demo was never what stopped them. What stopped them was that nobody could answer where the data went, who owned the environment, and how anyone would evidence it afterwards.
So the trusted foundation has to come before anything consequential is built on it. That is why the first thing we deploy is a governed environment in an account you own, and why the assessment maps your data flows before anyone discusses a capability.
Teams spent heavily on bespoke retrieval pipelines and model-specific systems, and managed services simplified or replaced that work within months. The engineering was real and it was obsolete almost immediately, because the layer it occupied kept being absorbed by the platforms underneath it.
What did not get absorbed was judgment: what to build, which components fit, where inference does not belong, and how the result becomes a business capability. That is what a small senior practice can sell honestly, and it is the opposite of billing for the pipeline everyone will stop needing.
As implementation becomes easier, judgment becomes more valuable.The lesson the company is built on
Exact claims beat broad claims. Region, model, retention, networking and provider behaviour get specified, and a control is described at the tier it belongs to rather than in general. This is why the site says "available on Standard and Strict" where a competitor would say "enterprise-grade security", and why it says we hold no third-party attestation on the same page as the compliance work.
The discipline is not modesty. A claim that cannot be pointed at is a claim your security reviewer will eventually test, and the cost of failing that test is the whole relationship.
A working target stated as a result is the most common lie in this industry, and it is usually accidental. We say "working target" when something is one, we say "an estimate" when it is one, and where nothing has been measured we publish nothing at all rather than a plausible figure.
The instinct of a technical founder is to solve an implementation problem by becoming the implementer. The rule corrects it: improve the scaffold, the documentation, the validator or the support path first, and step in as the builder only when the issue belongs to the platform or crosses a security or governance boundary.
It is also what makes the practice survivable. Every time judgment is encoded into tooling instead of being applied by hand, the company depends a little less on one person being available.
orgOS is the platform. The operational knowledge gateway is a second, sibling product for organizations whose people already use an AI assistant and whose real problem is governed access to their own documents. They solve different problems and their claims never get mixed. If you are unsure which one fits, the decision page is written to talk you out of the wrong one.
The product's limits are maintained as a page of their own rather than left for a reviewer to discover: what we do not claim sets out what orgOS does and does not do, and compliance alignment carries the attestation position and the controls matrix with its verdict per row. The one limit that belongs on a page about the company is its size, and continuity states what bounds it and what a successor would need.
One principal, with contractors engaged against a specific deliverable. Not a department, not an agency roster, not "our engineers". The principal designed the platform and deploys it, so the person answering a question about it is the person who wrote the part you are asking about.
Only with the exit open, which is why the whole commercial model is built around it. The platform runs in a cloud account you own and are billed for, the deliverables include infrastructure as code and runbooks, and the monthly fee buys our service rather than access to your own environment. Continuity is the page that answers this properly, including the part where the answer is uncomfortable.
Capacity is added when committed work requires it, rather than to look larger during a sales process, and the repeatable part of a deployment is carried by the factory rather than by available hours. The scarce input is senior attention, and pricing it as if it were unlimited is how small firms fail their clients.
No. The platform is deeply built on one cloud provider, and moving it to another would be a rebuild rather than a migration. We say that plainly because "cloud agnostic" is a claim buyers test. What is genuinely composable is the model: switching which model serves a workload is configuration inside the same governed route. Composable AI states both halves.
Including the parts about us. A company this size can only be bought safely if the buyer can see all of it, so this page is written to be checked rather than believed.
A bounded $2,500 engagement with the person who built the platform, ending in a written plan you keep either way.