Skip to content

Platform

Bring your agents under control

Every connected agent shows who owns it, which model it calls, what it can reach and what it has actually been doing — however and wherever it was built.

However it was built

Agents

11

Frameworks

8

None of them were built with OpsAI, and nothing here asks them to change. An agent is governed where it calls out, not inside its own loop.

What connects

8 frameworks, one control point.

This is the spread across 11 agents in a single sample estate. It is the normal state of an organization that let its teams move, and it is the reason a control point has to sit at the boundary rather than inside the framework.

  • 2Cron job + direct API2 agents
  • 2LangGraph2 agents
  • 2LlamaIndex2 agents
  • 1CrewAIone agent
  • 1Hand-written (Python)one agent
  • 1n8n automationone agent
  • 1Temporal workflowone agent
  • 1Vendor copilot (Zendesk)one agent

IllustrativeThe OpsAI sample estate. A real organization usually finds more frameworks than it expected, not fewer.

OpsAI does not build agents, and does not ask you to rebuild yours.

A connected agent keeps its own control flow. What changes is that the call it makes to a system of record now passes through a point that can refuse it — and that the refusal, or the authorization, is written down either way.

What OpsAI attaches, whatever it is.

The same four for a LangGraph orchestrator and for a cron job that gained a model call. If the requirements varied by framework, the framework column above would be a governance problem instead of an implementation detail.

An identity of its own
An attested workload identity, so a decision is about this agent rather than about whoever holds a key it also uses.
A named owner
A person, not a team alias. Authority starts with them and the agent holds a subset of it.
A declared reach
The systems, tools and actions it may call. Anything outside the declaration is refused rather than recorded for review.
A rule at the action
Evaluated when the action is attempted, against that action's own amount, target and subject.

Every agent, in one table

What it runs on, who answers for it, how far it reaches.

One row per agent. The two columns worth reading together are Built with and Reach: how an agent was written tells you nothing about how far it gets, and only one of those two facts is a risk.

Agent registry

11 agents · 8 frameworks
Every agent in the sample estate: the framework it was built with, the model it calls, its accountable owner, its autonomy level, the enterprise systems it can reach, and its current state.
AgentBuilt withModelAnswers for itAutonomyReachState
refund-resolverLangGraphClaude Sonnet2026-04-11Priya NairL3Act with approvalRazorpayZendeskActing
order-lookupLangGraphClaude Haiku2026-04-11Priya NairL1ObserveZendeskActing
ap-invoice-agentCrewAIGPT2026-03-28Rahul MenonL2AdviseZoho BooksRazorpayXActing
payout-runnerHand-written (Python)GPT2026-03-28Rahul MenonL4Act autonomouslyRazorpayXWatched
vendor-onboardTemporal workflowMistral2026-03-05Anita RaoL3Act with approvalNetSuiteActing
inventory-syncCron job + direct APIGemini Pro2026-02-19Anita RaoL2AdvisePostgresActing
tier1-supportVendor copilot (Zendesk)Claude Haiku2026-04-11Priya NairL2AdviseGmailZendeskActing
crm-hygieneCron job + direct APIGemini Pro2026-02-19Sneha IyerL1ObserveSalesforceActing
claims-triageLlamaIndexClaude Sonnet2026-04-11Devang ShahL2AdviseSalesforceGmailActing
contract-readerLlamaIndexLlama2026-01-30Kabir SenL1ObserveBoxActing
dunning-agentn8n automationClaude Haiku2026-04-11Sneha IyerL2AdviseGmailRead only

One row, in full

An agent is either governed at this resolution, or it is not governed.

A registry row tells you an agent exists and is owned. This is the resolution at which you can answer what it is allowed to do — and it is the same view for every agent in the table above.

refund-resolver

orchestrator · Support Ops
Acting
Answers for it
Priya Nair
Built with
LangGraph
Model
Claude Sonnet
Autonomy
L3 · Act with approval
Delegated from
root
Under governance since
4 May 2026

Tools it may call

  • issue.refund
  • close.ticket

Acts inside a bound. Above the bound, a person co-signs.

Read it in this order.

Owner before anything
Everything below is only meaningful because a named person accepted it. An unowned agent with a perfect policy is still unowned.
Then reach, then rule
What it can touch, and only then what constrains the touching. Reading those the other way round is how a tightly-worded policy ends up governing an action nobody realised the agent could attempt.
Activity last
What it has actually been doing, which is the only column that can contradict the three above it.

Follow one of its actions end to end

When an agent delegates

Authority narrows on the way down. It never widens.

An agent that calls another agent is delegating authority, and that is the moment most estates lose track of what is permitted. The rule is mechanical rather than advisory: a child may only ever hold a subset of its parent.

Authority for one refund

depth 1 of 3
  1. Priya NairSupport Ops
  2. refund-resolversubset of parent · L3
  3. depth 1 of 3

Deepest chain

2

ceiling is 3

Delegated agents

2

hold a subset of a parent

The ceiling exists because depth is where reasoning about permissions stops being possible. Three hops can be held in a person's head; six cannot, and an estate that allows six will eventually contain a chain nobody has ever read from end to end.

Where to start

Connect the one you are least comfortable with.

Not the simplest agent. The one that already writes to a system you care about, because that is the connection that tells you something you did not already know.