What is OpsAI?

OpsAI is a control layer. It sits between the AI systems an organization already runs and the systems of record those AI systems want to change, and it answers one question on every attempt: is this allowed? The answer is recorded either way, which is the part that matters afterwards.

What OpsAI does

An AI system proposes an action — issue a refund, post a journal entry, email a customer, add a payee. Before that action reaches the system that would carry it out, OpsAI evaluates it against a policy the organization wrote, decides, and files the decision with everything needed to explain it later.

Three properties of that evaluation are worth stating up front, because they are what separate this from a prompt instruction or a code review.

• It happens before the action lands. A refusal after the money has moved is a report, not a control.
• No model call is in the decision path. A policy compiles to a rule that is evaluated deterministically. Asking a model whether something is allowed reintroduces exactly the uncertainty the policy exists to remove.
• The refusals are recorded too. A log of successful actions cannot answer the question an incident review asks, which is what the system tried to do and what stopped it.

Where it sits

OpsAI is not in your control flow. Your agent framework still orchestrates, your workflow engine still keeps the sequence, your scheduler still fires the job. OpsAI is at the boundary where any of them calls out to something that can change state.

That placement is deliberate and it is the reason the product works with AI nobody wrote for it. An agent built in LangGraph, a copilot embedded in a vendor SaaS product, a scheduled Python script and a workflow step in a low-code tool have nothing in common architecturally — but every one of them eventually makes a call to a system of record, and that call is where a control can live.

What a decision looks like

A single evaluation, end to end. The agent asks; OpsAI answers with an outcome, the rule that produced it, and an evidence reference.

curl -X POST https://api.opsai.dev/v1/actions/evaluate \
  -H "Authorization: Bearer $OPSAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "refund-resolver",
    "action": "issue.refund",
    "subject": "ORD-40122",
    "target": "Razorpay",
    "amount": { "currency": "INR", "value": 18400 }
  }'

{
  "id": "ACT-7512",
  "decision": "authorized",
  "bound": "refund.ceiling",
  "bound_version": "v7",
  "evidence": "EV-7512",
  "latency_ms": 11
}

Everything a review would ask for is in that response. Which agent, acting on what, judged against which version of which rule, with a reference to the sealed record. A denial carries the same shape with the failing check named, which is what makes a refusal something a person can act on rather than argue with.

What OpsAI is not

Four boundaries. Each one is a thing readers reasonably assume, and discovering the assumption was wrong in week three is expensive.

• Not an agent framework. OpsAI does not help you build an AI system and has no opinion about how you do. It governs the ones you have.
• Not an orchestrator. It does not run your workflows or own the sequence of steps. Three of the systems it connects to are orchestrators, and they keep that job.
• Not a model gateway. Routing which model answers is one feature of the control layer, not the product. Nothing here proxies inference to make an agent work.
• Not an observability tool that watches after the fact. It decides. The record is a by-product of having decided, which is why the record is complete.

Where to go next

The quickstart goes from nothing to a governed action, and it is the shortest way to see the loop. If you would rather have the vocabulary first, the concepts page defines every term the rest of the documentation assumes, and it is worth twenty minutes if you expect to write policies yourself.