We do not build agents. We run them the way you run everything else.
Agent runtimes operated in production under controls: sandboxed at the process and network boundary, with runtime image lifecycle, sandbox policy, agent identity, capacity and incident response run by the engineers who answer the pager.
Delivered as a single-tenant dedicated instance, in infrastructure iTmethods operates or in your own cloud account on AWS or Azure. Both are available today. Air-gapped and sovereign are in development.
An agent your team started on a laptop is not in production.
The gap between a working agent and an operated one is the same gap that has always existed between a working service and an operated one. It is just newer.
Agents that run wherever a developer happened to start them are the reason nobody can answer what ran last quarter.
Shared credentials make the record useless at exactly the moment somebody needs it, because everything resolves to one account.
This is the layer that stops an agent's mistake from being an incident, and it is set once rather than per prompt.
Agent workloads fail in ways ordinary services do not, and at hours that suit nobody. There is a named engineer and a current runbook.
The runtimes your engineers have already chosen.
Orchestrated and sandboxed under one operating model, whichever ones you run. Adding another is a scoping conversation rather than a migration.
| Runtime | How Reign Ops runs it |
|---|---|
| Cursor Self-Hosted | Isolated environments per agent session, inside your boundary, with model routing through the governed gateway. |
| Claude Code | Operated with governed routing and prompt and tool guardrails, with the record written where the work happened. |
| LangGraph | Orchestrated and sandboxed at the process and network boundary under the same policy as every other runtime. |
| Sandboxed runtimes | Kernel-level sandbox isolation and deny-by-default network policy for the runtimes that support it. |
| Your own | An in-house runtime is operated under the same contract. There is no separate path for something you built. |
The same tools appear in AI-native governed SDLC when a human is at the keyboard rather than an autonomous agent. The boundary between the two pages is human-in-the-loop versus autonomous action, and the governance posture is set accordingly.
Set before the runtime starts, not after.
Applied at deployment as configuration under version control rather than as settings somebody remembered.
Runtime images built, patched and rotated on a cadence, rather than pinned to whatever version was current when the agent first worked.
Deny by default at the network edge, isolation at the process boundary, and no shared execution surface between agents that should not see each other.
Single sign-on and role-based access bound to your provider, with short-lived credentials rather than long-lived ones held in a runtime.
Scheduling and capacity operated for you, with a named engineer and a current runbook when something needs a person at an inconvenient hour.
Attestation status and the standard pack for procurement are released on request under non-disclosure rather than asserted here. Security and trust →
Reign Ops runs the runtime. Reign governs what the agent does inside it.
Operating a runtime well bounds what an agent can reach. It does not, on its own, tell anyone what the agent actually did. Reign Gateway sits on the model path and the tool path, and that is where the answer to that question gets written.
What we run, what you run.
Written down before anything is deployed, so the boundary is a document rather than a discovery.
| Who | What they hold |
|---|---|
| Reign Ops, automated | Provision and operate the runtimes inside your authorization boundary. Build, patch and rotate runtime images. Enforce sandbox policy at the process and network boundary. Bind agent identity to your provider. Operate capacity, scheduling and incident response. Isolate a runtime when something goes wrong. |
| Customer authored | Which agents run and what they are for. What each one is allowed to reach. The data classification that applies. Who may approve a new runtime or a policy exception. Your models, your prompts, your code. |
| Operating partner engagement | Onboarding runtimes in scoped waves. Standing up the initial sandbox and identity policy with your team. Authoring the first evaluators against your agent surface. The periodic posture review, and the decisions that change the design rather than the configuration. |
The questions that arrive every time.
Do you build or sell agents?
Can we bring an agent we wrote ourselves?
What happens when an agent misbehaves?
Which deployment shapes can we have?
What does it cost?
Tell us what your agents run in today.
Which runtimes, how they are started, and whether anyone can currently name the identity each one uses. We will come back with what we would take on first and what we would leave alone.