Autonomous vs human in the loop: three open-source points of control

Where should a person stand in the run?

It depends on what the run can reach. For calls that move money, reach a customer or delete something, set rules per tool call so the irreversible ones wait for a person. For changes that land in the repository, use a merge gate and read the diff. Reads, drafts and lookups can run with nobody there. One person at every step costs the speed you gained, and it buys oversight you would never refuse. Start strict on one run, then loosen one rule at a time.

Autonomy is the part of the run with nobody in it

Microsoft calls autonomous AI agents "systems that can independently analyze situations, make decisions, and act". It adds that "they don't just follow preset instructions". Salesforce says "autonomous agents can execute on tasks and workflows independently". Both sentences describe behavior from outside the run, which is why they leave the placement question open. An agent that reads a support queue and one that issues refunds look equally autonomous in a definition, and the sentence covering both says nothing about which of them can move money out of your account.

The difference shows up at one question: what can this run touch before a person looks? There are three ways to answer it. Each one is a level you can configure.

Level one: a person at every step

At the first level a person sits inside the session. Each action waits for a nod. The agent continues, and the next action waits again. A wrong reading gets caught early. An agent that misread a ticket never sends the reply that follows. The same level also caps what the run can do. A run that needs a person at each step will not clear a backlog overnight, and "A trigger starts a session with no person present" describes the opposite arrangement.

Try this level for the first week of a new agent, or for work with legal exposure. Drop to the next level once you can name each call you would always approve. If the prompt starts to feel like a formality, it has already become one, and the agent is a slower way to do what you were doing yourself.

Level two: a rule per tool call, a person for the held one

The second level puts a person at one call instead of every step. Each tool call can be set to allow, ask or block, down to the arguments it was given. Only the held call waits. A rule can allow a draft to your own domain and hold the single send addressed to a customer. A second rule can block that tool outright. The rest of the run keeps moving. The gate covers the refund, the send and the delete, and it leaves the read calls alone.

The manifest is the whole mechanism, quoted from the manifest reference. Read it top to bottom and you can predict which calls a person will see before the run starts, because the first rule holds a send addressed inside one domain, the second blocks every other send of that tool, and any call that no rule matches falls to the project default. A held call expires if nobody decides.

policy:  default_mode: riskpolicies:  - match: gmail.send_email    action: require_approval    conditions:      - arg: to        match: "*@example.com"  - match: gmail.send_email    action: block

Level three: a person at the merge

The third level reviews the work after the run. The agent commits to the session branch and opens a change request. A person with the project.gitops.merge permission reviews the diff and merges it. Everything the run did arrives as one readable change, and a rejection costs nothing because nothing reached the default branch.

What this level catches is the aggregate. Twenty individually reasonable edits can add up to a worse process. A prompt can be rewritten so that a check no longer runs, and the diff says so in one line. Its weak point is the reviewer. A change request nobody reads is an approval with extra steps. Merge on green checks alone and you have moved the decision to a linter.

Kortix is open source, so the three levels are not hidden from the people who have to defend them. "Approval gates you set. Off until you set them." The policy block, the agent files and every merge sit in the project repo, and a reviewer opens them there without asking anyone for a screenshot.

What the vendor definitions leave out

Snowflake says autonomous agents "track progress and adapt over time rather than completing a single action and awaiting further instruction". That is about duration. NVIDIA describes systems that "autonomously reason, plan, and execute complex tasks based on high-level goals in a secure environment with controls". Its platform material then puts the policy engine at the infrastructure layer. An operator configures that layer. A business reviewer cannot read it. Microsoft builds autonomous agents in Copilot Studio and bills the work in Copilot Credits, a number that varies per action or response, which prices a gate without placing one.

Each definition names a boundary: a duration, an infrastructure layer, a credit. None of them says where the person should stand. That placement is the decision that matters, and the definitions leave it open. Read only the definitions and you will pick the strongest gate you can find and apply it everywhere, so the agent ends up waiting on a person for work the person would always approve.

Choosing a level

Start from the run's tool list and sort the calls by what happens if one goes wrong and nobody can undo it. A call that leaves your systems, moves money or reaches a customer belongs at level two, with a rule that names its arguments, and a change that lands in the repo belongs at level three, because the diff is cheap to read and the edit is permanent. Everything else can run without a person, which is what makes the other two levels affordable.

Watch for three symptoms in the first week. An approval queue that grows faster than it clears means level two covers too much, and the approvers are rubber-stamping calls they would always allow. A merged change nobody can explain means level three exists on paper only. A run that finishes only while its owner is awake means level one is still on.

Whichever level you choose, write it down where the run can read it, because a policy that lives in a chat message or a wiki page is a preference and an agent cannot obey a preference at three in the morning. What autonomous AI agents are covers the definitions. Running an agent with nobody watching covers the schedule and the signature that start the run. Open-source autonomous AI agents compares the tools you can read.