Skip to main content

    Why Reign

    Everyone bought the jets. Almost nobody built the airport.

    Enterprises now run fleets of AI agents. Different airframes, different missions, all of them able to leave the ground. Getting an agent airborne is the easy part. The airport is how the work lands: eligibility before work starts, isolation while it runs, policy at the model boundary, an approval gate on the decisions that matter, and evidence afterwards. Reign is the airport.

    Reign runs as a single-tenant dedicated instance. Work is contributed into your software delivery lifecycle and stops at your gate.

    The fleet and the airport

    Taking off was never the problem.

    Landing is. Ground infrastructure decides what flies, what it may carry, and where it is allowed to come down.

    Procurement has been good at buying aircraft. Most large organizations now hold licenses for several agent platforms, and pilots are running in more than one function. Very few of those organizations have built the ground infrastructure underneath. The result is a flight line with no tower, no clearance, and no arrivals process.

    Without that infrastructure, every flight becomes a judgment made in the air. Output appears. Somebody accepts it. Six months later nobody downstream can reconstruct what was asked for, what the model was given, or who agreed to the result. The engineer at the controls remembers some of it. The organization remembers none of it.

    The airport is unglamorous and it is the whole job. Five things happen on the ground.

    • Eligibility. What work an agent is permitted to pick up, decided before it starts rather than argued about afterwards.
    • Isolation. Where the work runs, and what it can reach while it is running.
    • Policy at the model boundary. What may cross to a model, and what may not.
    • The approval gate. A human decision on the changes that matter, taken before anything moves.
    • Evidence. A record written as the work happens, not reconstructed later from memory.

    Four motions cover that ground. Reign Ops operates. Reign Factory builds. Reign Gateway governs. Reign Assurance is being designed to assure.

    For engineering leaders

    Capacity is only half of it.

    The backlog is one problem. Code arriving without a reader who understands it is the other.

    The backlog that never shrinks

    Every quarter the list grows faster than the team. Upgrades, migrations, deprecations and small remediations sit at the bottom because nobody has the hours. They are not hard. They are simply never next.

    Which work has been waiting longest because no one had the time, not the skill?

    Code without a reader

    The fear is reasonable. Machine written code can arrive faster than any human can absorb it, and a reviewer who cannot explain a change should not be approving it. Reign contributes work in units a reviewer can hold in their head, with the request, the scope and the reasoning attached to the change itself.

    Could your reviewer explain this change to a colleague tomorrow morning?

    Someone accountable

    Reign Factory runs with a named engineer embedded for this population. That person owns the shape of the work, answers for what was contributed, and is the one your team calls when a change is wrong.

    When something breaks at midnight, whose name is on it?

    On our own engineering, 11 July to 11 August 2026, Reign Factory produced 326 merged merge requests. Median time from merge request open to merge was 19 hours. 326 of 326 carried a recorded approval from a named iTmethods engineer.

    About those figures. Measured on our own engineering, 11 July to 11 August 2026, internal environment only, by a two-person team. They describe what happened in one population of work over one month. They are not a forecast, a benchmark, or a service level for your environment. Read the full method.

    For technology leaders →

    For risk and audit

    You are asked to sign off on work you cannot see.

    A record is only useful if it answers the question you did not think to ask at the time.

    The usual position is uncomfortable. A team reports that AI assisted delivery is working. You are asked to accept that, and the material offered is a summary written after the fact by the people who did the work. Nothing in it can be tested. Nothing in it survives a follow up question.

    A record that is worth anything to a reviewer contains particular things, captured while the work runs.

    • The request. What was asked for, by whom, and against which piece of authorized scope.
    • The eligibility decision. Why this work was in scope for an agent at all, and what was excluded.
    • The model boundary crossing. Which model and version, and what was supplied to it.
    • The output. What was produced, and where it was contributed.
    • The human decision. Who reviewed, who approved, what they changed, and when.
    • The disposition. What merged, what was rejected, and what was withdrawn.

    Reign Assurance · Co-design development. Its purpose is to prepare that record in a form your own reviewers can interrogate, so that the determination they reach is theirs and is supportable.

    Reign prepares; people decide. Reign Assurance does not issue certification, attestation, an audit opinion or independent assurance, in any tense. It does not act as your second line of defense. It assembles evidence. Your risk function reaches the conclusion.

    For the Chief Audit Executive → For the Chief Risk Officer →

    For security

    The model boundary is the control point.

    Everything worth governing happens where a request crosses to a model, and where the result comes back.

    What passes

    Reign Gateway sits at the boundary and applies policy to every crossing. Which models are permitted, for which classes of work, carrying which categories of context. Policy is configuration you set, not a default you inherit.

    Today, can you name every model your engineers are able to reach?

    What does not

    Work runs inside isolation you define. Reach is bounded to the repositories, systems and data the population of work requires. A request that falls outside policy is refused at the boundary rather than logged as an exception afterwards.

    What would a refusal look like in your current setup?

    What is recorded

    Each crossing produces a record: the policy applied, the decision taken, the model and version involved, and the disposition of the result. The record is written as it happens and is retained for your reviewers.

    If a supervisor asked for one week of crossings, how long would that take?

    Deployment is a single-tenant dedicated instance, in infrastructure iTmethods operates or in your own cloud account. There is no shared tenancy and no multi-tenant service. Air-gapped and sovereign are in development.

    For the CISO →

    The difference

    This is not a coding assistant.

    The work does not live in an engineer's editor, and it does not depend on an engineer remembering to describe it.

    An assistant sits beside one person and improves that person's day. Its output is bounded by their attention and disappears into a commit with no history of how it came to exist. That is a useful tool. It is not delivery, and it is not governable.

    Reign contributes into your own software delivery lifecycle. Changes arrive as merge requests in your repositories, under your branch protections, in front of your reviewers, subject to your pipelines. We operate GitLab. The approval path is the one your organization already trusts, because it is already yours.

    Nothing merges without your gate. Nothing releases without your gate. If your reviewers decline a change, the change does not happen, and the decline is part of the record.

    Bring us the work

    Start with one population of work.

    Pick a backlog your team already understands and a reviewer who already owns it. We will walk the path from request to merge, and show you the record it leaves behind.