The stack your agents run on, operated inside your own envelope.
Agent runtimes, model access, the MCP and tool layer, and the control plane underneath all three. Four parts of one substrate, operated by iTmethods as a single-tenant dedicated instance, each one producing a record a reviewer can follow.
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.
Agents are infrastructure now. Somebody has to operate them.
The agent is the part everyone looks at. The part that decides whether it can be relied on is the four layers underneath it, and those are an operations problem before they are a governance one.
Which means a gap in the control plane is not a control-plane problem. It is a gap in everything standing on it.
What we operate is the envelope they run inside: the runtime, the routing, the tool boundary and the substrate beneath. That distinction is worth being exact about, because most of this market is selling the other thing.
None of it is what anyone demos. All of it is what a reviewer asks about, and it is the layer that is hardest to add afterwards.
The workload is new. The operating model is the one iTmethods has run since before any of this was called AI.
Four parts. One envelope.
Each is operated on its own terms and each has a page. Together they are the thing an agent actually runs on.
Agent runtimes
The operational discipline of running agent runtimes in production under controls: sandboxed at the process and network boundary, with runtime image lifecycle, sandbox policy, agent identity, capacity and incident response operated for you.
Governed model access
The gateway, policy and record layer between your agent runtime and the model providers. Version pinning, fail-over routing and credential rotation run as managed infrastructure rather than as configuration somebody owns personally.
MCP and tool operations
The tool layer run as a governed supply chain: managed MCP servers, tool registries, third-party integrations and in-house tool servers, sandboxed at the tool-call boundary with provenance on every tool definition.
The control plane
The substrate beneath the substrate: identity, network boundary, secret store, compute scheduler, the retrieval layer and the log pipeline, operated on infrastructure the customer owns.
The same architecture in every deployment shape. What changes is where it sits, and only the single-tenant dedicated instance is available today. Deployment options →
The same posture at every layer.
The point of one substrate is that these hold across all four parts rather than being negotiated at each.
Bound to your provider, not a shared service account. An agent that cannot be named cannot be accounted for later.
What a runtime can reach is set before it starts, not discovered from what it managed to reach.
Evaluated at the moment of binding rather than reviewed afterwards, and the binding is recorded either way.
In line rather than in batch, on the same substrate as the thing it describes, so nothing has to be reconciled later.
Reign Ops runs the substrate. Reign governs what the AI does on it.
Four layers produce four kinds of record, and on their own that is four more things to reconcile. Reign Gateway sits on the model path and the tool path, which is where a single policy can cover every layer at once.
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 | Operate the agent runtimes, the model-access gateway, the tool layer and the control plane inside your authorization boundary. Enforce your identity provider at every edge. Sandbox at the process and network boundary. Apply policy before a tool binds. Stream the record to your systems. Patch and scale the substrate. |
| Customer authored | Which agents and which tools are sanctioned. What each agent is allowed to reach and on whose authority. Data classification and the retention you need. What a policy exception means and who may grant one. Your models, your prompts, your data. |
| Operating partner engagement | Scoping and phased onboarding layer by layer. Standing up the initial policy set 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 the agents?
Can we adopt one part without the others?
Which deployment shapes can we have?
What does it cost?
Tell us what your agents run on today.
Which runtimes, which models, and what they are allowed to reach. We will come back with what we would operate, what stays with your team, and which layer we would start with.