Skip to main content
    Meet us at Open Source in Finance Forum (OSFF) New York, Convene Brookfield Place, November 4 to 5.Book a meeting
    Book a briefing
    Reign OpsAI substrate

    Operate the infrastructure your AI agents depend on.

    Reign Ops operates agent runtimes, model access, tool connections and the supporting control plane as a dedicated environment. Customer policies define who and what may use them; the operating record shows what happened.

    Available today Discuss your agent platform See the four parts →

    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 deployment are supported.

    The substrate four parts
    Four layers, one operating scope run Agent runtimes reach Governed model access bind MCP and tool operations underneath The control plane identity · network · secrets · logs Gateway models Each layer carries the one above it A record at every layer, in a form a reviewer can follow
    Four layers, one operating scope
    runAgent runtimes
    reachGoverned model access
    bindMCP and tool operations
    underneathThe control planeidentity · network · secrets · logs
    Gatewaymodels

    Each layer carries the one above it

    A record at every layer, in a form a reviewer can follow

    Four parts, one envelope. The agent is the part everyone looks at; the four beneath it are what Reign Ops operates as one scope.
    What Reign Ops operates

    One operating scope from agent runtime to control plane.

    Reign Ops puts the runtime, model access, tool layer and control plane into one agreed operating scope. The engagement defines which layers Reign Ops operates, how access and changes are handled, and where the operating record goes.

    01We do not build the agents
    iTmethods does not host or serve foundation models at scale, and does not sell you an agent.

    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.

    02Two decades of the same problem
    Operating foundational infrastructure inside somebody else's boundary, under their controls, is not a new discipline here.

    The workload is new. The operating model is the one iTmethods has run since before any of this was called AI.

    The substrate

    The layers in scope, operated together.

    Each layer can be scoped on its own; the control plane underneath is shared.

    Run

    Agent runtimes

    The place your agents execute. Runtimes, dependencies and releases are operated through an agreed change and incident process, inside your identity and network boundary.

    What you get. Agents run somewhere supported, with a named owner for releases, incidents and rollback instead of a prototype on someone’s laptop.
    Discuss agent runtimes →
    Reach

    Governed model access

    The gateway, policy and record layer between your agent runtime and the model providers. Version pinning, routing policy and credential rotation run as managed infrastructure.

    What you get. Teams manage permitted model access in one place instead of inside each agent. Calls sent through Gateway leave an operating record for review.
    How the boundary works →
    Bind

    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.

    What you get. Teams can add MCP tools without making them available to every agent. Each identity sees only the tools it has been granted.
    MCP and tool operations →
    Underneath

    The control plane

    The substrate beneath the substrate: identity, network boundary, secret store, compute scheduler, the retrieval layer and the log pipeline, operated on your single-tenant instance.

    What you get. Operations and review teams know where agent identities, secrets, runtime health and logs are managed for the agreed environment. Your identity provider is enforced at every edge, and the agreed telemetry states its destinations and retention for the deployment.
    Discuss the control plane →

    Every layer runs on the same single-tenant instance, in infrastructure iTmethods operates or in your own AWS or Azure account. Both are available today. Deployment options →

    Where Reign fits

    Reign Ops runs the substrate. Reign Gateway records the calls sent through it.

    Reign Gateway sits on the model path and the tool path and applies one policy to the model and tool interactions sent through those two points. Model and tool interactions produce separate records.

    For each model call sent through Gateway:
    The identity that made it, the policy that applied, the decision taken, the model that answered and the time it happened.
    For each tool binding made through Gateway:
    What the agent asked to bind, what was allowed and what it did once bound.
    For the control plane, a Reign Ops record:
    Identity events, key rotations, retrievals and scheduling decisions. The record is written in line rather than assembled in batch.
    A record of what happened, not a verdict. It is prepared so that a reviewer can follow it. It is not an audit opinion, and it is not independent assurance of anyone's controls. Beyond SOC 2 Type II for Reign Ops, no other certification or accreditation is claimed. How the boundary works → · Regulatory alignment →

    Which agents and which tools are sanctioned, what each agent is allowed to reach and on whose authority, and what a policy exception means and who may grant one, are customer decisions. Your models, your prompts, your data.

    FAQ

    Do you build the agents?
    No, and we do not host or serve foundation models at scale either. What Reign Ops operates is the envelope the agents run inside: the runtime, the routing to the model providers, the tool boundary and the control plane underneath. You choose the agents.
    Can we adopt one part without the others?
    Yes, and most estates do. The layers stack, so adopting a lower one makes the ones above it easier, but each is scoped and operated on its own terms. The first conversation is usually about which layer is causing the most trouble right now.
    Which deployment shapes can we have?
    A single-tenant dedicated instance, in infrastructure iTmethods operates or in your own cloud account on AWS or Azure. Both are available today and both are single-tenant. Google Cloud is planned for 2027. Air-gapped and sovereign deployment are supported. There is no multi-tenant or shared option. Deployment options states which is which without softening any of them.
    What does it cost?
    Pricing is set in the scoping conversation. This site publishes no price list and no tiers, because what we would operate for you is the thing being priced and it is different every time. The scoping call is where that gets answered, and it commits you to nothing.
    Next step

    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.

    Discuss your agent platform Coding assistants, governed →