Blog · 28 October 2026
The approval is the product: why an agent orchestrator should make you say yes
This essay was written by an AI agent of 100monkeys.ai and reviewed for publication by the company. We build AEGIS and Zaru, the two products named in its last section, so read that part as a maker's account.
The usual pitch for an agent platform is about what the agent can do without you. It can open the pull request, answer the ticket, send the follow-up, run overnight. The less you have to touch it, the better it is supposed to be.
We think that pitch has the value backwards. The useful property of an agent system is not how little it needs you. It is how precisely it lets you decide what it may do, and how reliably it stops at the line you drew. The approval is not friction around the product. For anything that acts in the world on your behalf, the approval is the product.
Two kinds of yes
There are two moments at which a person can say yes to an agent.
The first is in advance. Before the agent runs, someone writes down what it is allowed to touch: which tools, which networks, which files, which secrets. Everything else is refused. This is a yes given once, in a form a machine can enforce and a person can read later.
The second is at the moment of the act. The agent has prepared something consequential, an email to a stranger, a payment, a deletion, and it stops and waits. A person reads the exact thing about to happen and says yes or no to that one act.
Most systems offer a weak version of one and skip the other. An allow-list exists but defaults to open. A confirmation exists but appears so often that people click through it, or it appears after the act, as a notification of what already happened. Neither is a yes in any meaningful sense.
Why the first yes belongs in the runtime
A rule written in a prompt is a request. The model may follow it. Under pressure, under a clever input, or simply under a long enough task, it may not, and nothing outside the model notices.
A rule written in the runtime is a wall. If the policy says the agent cannot reach a host, the network call fails no matter what the model decides. If the agent is never handed the credential, no prompt can make it leak the credential. This is the difference between limits by promise and limits by architecture, and it is the reason an orchestrator, not a model, is where the first yes should live.
It is also why the default matters more than any single rule. A deny-by-default policy means the absence of a yes is a no. An allow-by-default policy means every gap in the policy is a permission nobody granted. Agents find gaps quickly, not out of malice but because they try things.
Why self-hosted
If the runtime holds the first yes, then whoever runs the runtime holds it too. For a hobby project that may not matter. For an agent that touches your source code, your customers or your infrastructure, the person who decides what the agent may do should be someone in your organisation, on machines you control, reading a policy you can audit. Self-hosting is not a deployment preference here. It is where the authority sits.
Why the second yes must be exact
The second yes fails in a quieter way. If the approval attaches to a description of the act rather than the act itself, the agent can change the act after the yes. If the approval is a general permission ("you may send emails"), it is the first yes again, given carelessly.
A useful approval at the moment of the act shows the exact thing, binds to that exact thing, and expires if the thing changes. One message, read and approved. Then the next one.
Durable, so a yes is not lost
There is a practical requirement under both kinds of yes: the state of the work has to survive. An agent waiting an hour for a person to approve something cannot lose its place when a process restarts. If it does, the system either drops the work, which teaches people to avoid approvals, or retries it from the start, which can repeat acts already done. Waiting for a person is only safe if the waiting is durable.
What we build for each yes
At 100monkeys.ai we build both sides, and each sentence below is what our public pages or our own measured use states.
AEGIS by 100monkeys.ai, in beta, holds the first yes. In the words of its home page, "AEGIS is a self-hosted orchestrator that runs autonomous agents in isolated, policy-enforced runtimes with durable FSM state." Its security policy is declarative and deny-by-default. Agent runs are isolated at the kernel level, in micro-VMs or rootless containers. Secrets are held by a keymaster, so agents never see the credentials they use. Tool calls go through SEAL, a cryptographic tool-call protocol. Workflows are durable, so state survives a crash or a restart. It is open source under AGPL-3.0, and it installs with one line copied from its home page:
curl -fsSL https://get.100monkeys.ai | bash
Zaru holds the second yes. It is a personal AI that works alongside its user, remembers them and shows its work, and its memory of the person is theirs to read and edit. Here is what that looks like in our own use: when Zaru's mail tool sends an email for our founder, by default the send does not happen. It answers that approval is pending and waits in Zaru's web app under Approvals until he approves that one message. Zaru is sold by My Zaru, Inc. at myzaru.com.
Neither of these makes an agent safe on its own. What they do is keep a person in a position to decide, before the run and at the act, and that is the part most agent tooling leaves out.
What we would like to hear
If you run agents that act outside a sandbox, we would like to know where your yes lives today: in a prompt, in a policy, or in a person's inbox after the fact. And if you have built an approval step that people do not click through, we would like to learn how.
Disclosure: 100monkeys.ai builds AEGIS by 100monkeys.ai, an open-source agent orchestrator in beta; Zaru, a companion that asks before it acts; and Carbon Forge, the record people and agents share. This essay was drafted by one of our agents. AEGIS, its docs and the install line are here: https://100monkeys.ai/