Human over the loop: the open-source rule that holds without you

The four words, and what each one moves

Human in the loop and human on the loop are the two models most explanations cover. Torch.AI states the pair in a sentence: in the loop "requires a person to approve each action before the system acts, while on the loop lets the system act on its own under active human supervision with the authority to intervene or stop it" (Torch.AI). Decagon writes the same pair for a support queue. A person approves each decision before it takes effect, or the system acts while a person watches and can step in, correct it or stop it (Decagon).

Torch.AI adds a model past those two. "A third model, human out of the loop, removes the person from the operating cycle entirely once the system is running." Decagon draws that end of the line as a place "where nobody plays a real-time role. People set the rules ahead of time and audit afterward."

Human over the loop is the term teams use for the model that sits between them, and neither of the two pages that draw the pair defines it. The term is used in practice to mean a person writes the constraints the agent runs under. Those constraints are evaluated on each matching call, and the person reviews outcomes and rules instead of individual steps. The authority is real, and it is spent before the run.

The four words move four different things.

• —Human in the loop moves the decision. A person answers yes or no to a call that is waiting for one.
• —Human on the loop moves the attention. A person watches a stream of actions and keeps the power to stop or correct one.
• —Human over the loop moves the constraint. A person decides what shape of call may run, and the rule applies that decision every time the shape appears.
• —Human out of the loop moves nothing after setup. Nobody holds a real-time role, and oversight lives in how the system was built, tested and bounded, plus the audit that follows.

Torch.AI describes that last shift plainly: oversight "moves earlier, into how the system was designed, tested, and bounded." Over the loop keeps one thing that out of the loop gives up. The constraint is evaluated on the call itself, before the call runs, so a person's judgment still applies to each action without a person being present for it.

The distinction is decided per action, not per system. One project can hold a refund for approval, run status replies under a written rule, and let an internal summary run unread, all from the same policy.

Why writing the constraint is a different job from watching

On-the-loop supervision asks a person to be right in the moment. The supervisor watches a stream and decides whether this action, the one in flight, should continue. Decagon names two failure modes that live inside that moment. "Human-in-the-loop fails through fatigue", with reviewers who approve a long run of correct proposals stopping their close reading. The same glossary describes the on-the-loop failure as automation bias, the habit of trusting a system that usually works. A supervisor who has seen a thousand clean runs is poorly placed to spot the dirty one.

Both failures sit in the person's attention, and attention is the resource an on-the-loop design spends. A constraint spends the author's attention once. A rule that reads a recipient and decides whether the address is inside the company is a judgment about a whole class of calls. It is taken while the list is visible, by someone who is not halfway through a shift.

Kortix applies that judgment before the action runs. A policy decides whether an action is allowed, needs approval, or is blocked, and the first matching rule wins. Conditions let the rule test the call's arguments, so the decision is about the recipient, the channel or the amount rather than about a tool in general.

An approval covers one exact request, so the person who releases a call has decided that call. The next one arrives with no memory of the decision. A class of calls needs a rule, because a queue only ever decides the call in front of it.

One consequence catches teams that treat over-the-loop as a softer queue. A held call waits for a person, and the wait expires. If nobody decides within 24 hours, the call is dropped and the session does not resume. An action that has to run at three in the morning therefore needs an Allow rule written in advance, with an argument condition narrow enough to be worth allowing. The yes is given at review time or it is not given at all.

Where each of the four belongs

Each model fits a different kind of action, and the fit is decided one action at a time. Torch.AI matches the control model to "the consequence of being wrong and the time available to act", and notes that most real workflows mix all three.

• —In the loop suits the irreversible and the judged: money leaving an account, a message to a customer, a release, a decision someone will be asked to defend. Torch.AI places this model on "lethal, legal, or irreversible actions".
• —On the loop suits reversible work at volume, with a supervisor who is genuinely watching: triage, tagging, order status, drafting.
• —Over the loop suits known-pattern work that has a written rule and an audit: routing by domain, refunds under an amount, deletes outside a directory, mail to an internal list.
• —Out of the loop suits narrow, low-stakes work only. Decagon is direct about the boundary, calling it reasonable for narrow, low-stakes tasks and wrong for anything that touches a customer's money, account access or rights.

A team usually runs all four in one project, and the Kortix policy file is where the assignment becomes visible. One action holds for approval, the next runs under a condition, a third is blocked outright. The setting belongs to the action, so a single connector can carry three of them.

The line between the two models most pages explain is drawn on the human-on-the-loop page, and the guide to choosing maps all four onto common agent jobs.

The limit of a written rule, and the review that covers it

A rule holds only what someone thought to write. The syntax will not invent a case. A condition on to says nothing about a field the provider adds next quarter. A connector installed after the review arrives with no rules of its own. An action nobody classified falls through to the default.

The default is the honest measure of that gap. In a new project policy.default_mode is allow_all, which runs every action no rule matched. Approval gates you set. Off until you set them. A team that writes three careful rules and leaves the default alone has constrained three actions and left the rest open.

The syntax defends against one failure. A malformed condition fails closed, so a typo narrows a gate instead of opening one. It cannot defend against a rule nobody wrote.

What covers the gap is a second job for a person, done on a schedule instead of in a queue. The policy is a file, so a change to it is a diff that can be read on a calendar and argued with line by line. Every action is recorded. Reading, exporting and streaming the audit log depend on the plan. The record is what turns the review from a reading of intentions into a reading of what ran and with which arguments.

Two questions are worth asking at that review. The first is which rules fired, and whether they fired on the calls their author imagined. The second is what ran unmatched, because that set is the part of the agent's behavior no person has decided about yet.

Encoding the constraint in kortix.yaml

Kortix evaluates a call in a fixed order, and the first match wins. Project-wide policies: in kortix.yaml come first, with fully qualified patterns such as gmail.send_email or *.delete*. The connector's own policies: come second, with patterns relative to the connector. sensitive: true comes third and holds every remaining action, reads included. policy.default_mode comes last. A connector rule cannot override a project rule, so the constraint with the widest reach is also the hardest to loosen at the connector.

Conditions put the test on the call's arguments, which is where behavior is decided. arg is a dot path into the call's arguments (message.channel), match takes a glob, a case-insensitive pattern or a /regex/, and negate: true inverts a test. A rule holds up to 10 conditions and all of them must match. A missing argument never matches the pattern, so a negated condition on an argument that is absent holds. A rule that fails to parse fails closed.

A complete project policy can be this short. risk runs reads and holds writes and destructive actions for approval. One rule allows a send to an internal address. The next rule holds every other send to the same action, so the exception stays narrow and that action still ends in a person's decision. sensitive: true on a connector, or allow_all as the default, changes the shape of everything the rules leave alone.

The same file is editable from a terminal. kortix connectors policy set --default risk --apply sets the default, and kortix connectors policy add "gmail.send_*" ask --condition to='*@example.com' adds a rule with a condition. The evaluation order and the condition rules are in (Read the docs).

The policy change is itself work that lands through review. Session work reaches main through a change request. Merge is default-deny for agents. A rule that widens what an agent may do unattended is a diff a person reads before it governs anything. That is also why policy edits stay out of the agent's own reach.

Review the policy on the same clock as the work it governs. An exception written for one customer keeps its narrow shape long after the contract ends, and the log is where that shows up first. The approval workflow page takes a held call apart, from the paused turn to the decision that resumes it.