Skip to content

Platform

One operational layer across your AI environment

OpsAI connects the AI your organization already runs and adds the operational layer around it: identity, policy, risk, approval, execution and evidence.

What this covers

Control surfaces

24

Stages

6

Every surface below answers one question about an action that has not happened yet. The concepts, in order.

How the layer is organised

Six stages, in the order control actually happens.

Not a feature list. Each stage depends on the one before it: you cannot govern what you have not found, and you cannot prove what you did not observe.

  1. 01Connect

    Bring existing AI systems, agents, models, data and tools under one layer.

    What is already running, and how does it come under one layer without being rebuilt?

  2. 02Understand

    Know what AI exists, who owns it, and how it behaves.

    What exists, who owns it, and what has nobody claimed?

  3. 03Govern

    Identity, accountability, policy and data controls.

    Who is acting, on whose authority, and under which rule?

  4. 04Control

    Risk, approval and the boundaries an action runs inside.

    How consequential is this action, and who has to agree to it?

  5. 05Observe

    Activity, traces, incidents and the evidence record.

    What actually happened, and can it be proven afterwards?

  6. 06Improve

    Routing, evaluation, posture and continuous governance.

    Where is the estate drifting, and what changed since last week?

The model underneath

One chain, from the person who is accountable to the record that proves it.

Every stage above is a segment of this chain, and every decision OpsAI makes walks the whole of it. Read it once here and the rest of the platform is a set of close-ups.

Human to audit, in order

the product graph
  1. Human

    Someone is accountable. Every chain of authority starts at a named person, not at a service account.

  2. AI System

    The application, copilot or workflow the person is responsible for. It already exists; OpsAI did not build it.

  3. Agentdelegation narrows

    What actually runs. It holds a subset of the authority above it, and never more.

  4. Model

    The model the agent calls, with a provider, a version, an owner and an approved use.

  5. Context / Data

    What the model was allowed to see. A data request is authorized before it is answered.

  6. Tool

    The capability the agent wants to use. Registered, owned, and scoped to specific actions.

  7. Policyno inference in the path

    The rule that applies, written by the team that carries the risk and evaluated as code.

  8. Risk

    How consequential this particular action is, given what it touches and whether it can be undone.

  9. Approval

    Where the stakes require it, a named person co-signs. Otherwise the action proceeds inside its bound.

  10. Action

    The call goes out with the policy attached, so it cannot widen in flight.

  11. Result

    What the system of record actually did, returned to the agent that asked.

  12. Auditchained, not editable

    The decision, its inputs and the policy version are sealed before the response returns.

Three things the order is doing.

It starts at a person
Not at a service account and not at an API key. Accountability is the root of the chain, which is what lets an agent be responsible for a task without becoming answerable for the outcome.
Authority narrows on the way down
A child agent holds a subset of its parent, never more. A sub-agent cannot be talked into authority it was never issued.
Policy sits at the action, not at the start
The rule is evaluated when the action is attempted, against that action's own amount, target and subject — not once when the workflow began.

Every stop, defined

What it looks like in use

An estate, with a name against every part of it.

The figures below come from the sample estate this site uses throughout. It is a fictional company, and the point of it is the shape rather than the size: every system connected, every rule owned, every team named.

AI systems governed

11

each with a named owner

Teams accountable

6

not one central body

Enterprise systems

11 of 12

one deliberately not connected

Policies in force

8

owned by the teams at risk

IllustrativeA sample estate used to show how the platform behaves, not a customer deployment.

Scope

What OpsAI is not.

Four things this gets mistaken for. Ruling them out is quicker than describing the alternative, and it is the fastest way to work out whether this is the layer you are missing.

Not an agent framework
OpsAI does not build agents and has no opinion about how yours are written. LangGraph, CrewAI, a bare model call in a cron job — all of it connects as it is.
Not a model
There is no OpsAI model, and no inference anywhere in the decision path. Bounds are evaluated as code, which is why a decision costs milliseconds rather than tokens.
Not a database
Your data stays in the warehouse, the document store and the systems of record that already hold it. OpsAI governs the request; it does not become the source of truth.
Not a committee
Nothing here is a review board or a quarterly attestation. It is a control point in the path of an action, and it either authorizes that action or it does not.

Where to start

Connect one system and watch what it asks for.

The first connection is usually the informative one. Most teams find the agent is reaching for more than anyone realised, and that is the point at which a bound is easy to write.