# Human in the loop vs on the loop: open source policy decides

> In the loop, a person decides before the action runs. On the loop, the system acts while a person watches and can stop it. Kortix is the open-source AI Operating System, and the choice between them is a rule in a policy you write.

URL: https://humanintheloopvshumanontheloop.com/

Open source oversight, one rule per action

**The open-source AI Operating System**

`Kortix's Agents screen lists four agents in kortix.yaml, among them Support-Desk, which triages helpdesk tickets and drafts replies for a human to approve`

```

```

Source: https://kortix.com/media/film/agents.webp

`kortix.yaml`

```yaml
policy:
  default_mode: risk
policies:
  - match: gmail.send_email
    action: require_approval
```

Source: https://kortix.com/docs/connect/connectors

Actions are always_run, require_approval, block, shown as Allow, Ask, Block.

[Try Kortix](https://kortix.com) · [Read the docs](https://kortix.com/docs/connect/connectors)

Allow, Ask, Block · a rule per action and per argument · the policy is a file in your repo

## Four actions, four different answers

The same agent gets a held refund, a reviewed deploy, a screened CRM write and a report that runs on its own.

### Human in the loop: A refund waits for a person

One Ask rule holds the refund call, so the agent drafts it and the turn pauses until someone decides.

What the rule hands back: `Approval card`

- Rule: Ask on the refund call
- Amount: 480.00 USD
- Requested by: a session
- Status: pending_approval

Nothing ran while the call was held.

### Human in the loop: A production deploy waits as a change request

The deploy is prepared on the session branch, and a person reads the diff before any of it reaches `main`.

What the rule hands back: `change-request.diff`

```diff
- replicas: 2
+ replicas: 4
+ image: api:2026-10-24
```

+2 -1

The branch carries the work; the merge is the person's call.

### Human on the loop: A CRM write runs for your own domain and waits for anyone else

The same action carries two rules, and the condition reads the contact's email domain, so writes to your own domain run and every other one is held.

What the rule hands back: `kortix.yaml`

```diff
+ policies:
+   - match: crm.update_contact
+     action: always_run
+     conditions:
+       - arg: email
+         match: "*@northwind.example"
+   - match: crm.update_contact
+     action: require_approval
```

+8 -0

The second rule catches every write the first one let through.

### Human over the loop: A nightly report runs and someone reads the result

Reads run under `default_mode: risk`, the report is written at 06:00, and the person who set the goal checks the outcome in the morning.

What the rule hands back: `nightly-run`

- Reads: run
- Writes: none in this run
- Report: 06:00
- Held: 0

No call was held because nothing in the run writes.

## What each model decides, and what enforces it

The model columns restate each published definition; the Kortix column is what a policy file enforces on a call.

| | Kortix (recommended) | Human in the loop | Human on the loop | Human over the loop |
| --- | --- | --- | --- | --- |
| Who decides | Your rule, per action. | A person, before it runs. | The system, under supervision. | A person, at the outcome. |
| When the person acts | When a rule says Ask. | Before the action runs. | While it runs, and on exceptions. | At the start and at review. |
| What the person sees | The call, its arguments, the approval summary. | The proposed output. | The running behavior and flagged exceptions. | The finished result against the goal. |
| What it costs at volume | Only the calls a rule holds. | A decision per action. | Attention on exceptions. | A review per cycle. |
| How it fails | A missing rule, since the default is allow_all. | Reviewers approve a long run without reading. | Coverage depends on what is watched. | Constraints nobody wrote down. |
| What enforces it | `kortix.yaml` rules, then the connector's. | A decision gate in the workflow. | Monitoring, alerts, an override. | Stated goals and limits. |

Model cells restate each publisher's own definition, linked in the column heading; the human-over-the-loop column is this site's synthesis, since Torch.AI defines human out of the loop and the column follows the contrast that page draws with the third model.

A held call is a rule you can read, diff and change like the rest of the project.

- Approval gates you set. Off until you set them.
- Session work reaches `main` through a change request. Merge is default-deny for agents.

**1 file** the policy sits in `kortix.yaml`, next to the agents it governs

## The oversight rules are a file in your repo

[Kortix on GitHub](https://github.com/kortix-ai/suna) · [Read the docs](https://kortix.com/docs/connect/connectors)

## Answers to the questions the pair raises

### What is the difference between human in the loop and human on the loop

In the loop, a person decides before the action runs. On the loop, the system acts while a person supervises and can stop, override or change its policy. The difference is who holds the decision at the moment of action.

### Is human in the loop better than human on the loop

Neither is better on its own. In-the-loop suits actions that are hard to undo. On-the-loop suits high volume where someone can watch and step in. The choice belongs to each action, not to the agent.

### What is human over the loop

A person sets the goal and the limits, then reviews the outcome rather than the steps. The system runs inside them. It sits further out than on-the-loop oversight, where someone still watches the running work.

### What is human out of the loop

No person reviews or supervises the work, and the system's output stands. Torch.AI names it alongside the other two, as the case with no one watching. It fits actions you would let run unattended.

### When should an AI agent ask for approval before it acts

When the action is hard to undo, reaches outside your organization, or spends above a threshold you set. Write the rule for that call, and let the rest of the agent keep running.

## Decide it per action, in a file you own.

Start with the one action that should wait; leave the rest running.

[Try Kortix](https://kortix.com) · [How to choose](https://humanintheloopvshumanontheloop.com/how-to-choose)