# 100monkeys.ai > 100monkeys.ai builds AEGIS, a self-hosted orchestrator that runs autonomous agents in isolated, policy-enforced runtimes with durable FSM state, and four products alongside it: Carbon Forge, Your Zaru, Zaru CLI and Grill My Idea. AEGIS is open source under AGPL-3.0 and installs with one command: `curl -fsSL https://get.100monkeys.ai | bash` AEGIS bounds what an agent can do at the infrastructure layer rather than in the prompt. Generate, execute, evaluate, refine: the loop runs until deterministic validators pass. The membrane around it enforces isolation and policy on every tool call, and each run is a durable state machine. This file is the full text of the English FAQ, paper, datasheets page and blog guides on 100monkeys.ai, one page per section, each headed by its URL. The index of the site is https://100monkeys.ai/llms.txt; the AEGIS documentation has its own at https://docs.100monkeys.ai/llms.txt. The datasheets themselves are PDFs and are linked, not reproduced. --- Source: https://100monkeys.ai/faq FAQ ## Questions about AEGIS, agent limits and accountability Short answers from 100monkeys.ai. AEGIS by 100monkeys.ai, in beta, is a self-hosted orchestrator for autonomous agents; it is open source under AGPL-3.0 and installs with one command. ``` curl -fsSL https://get.100monkeys.ai | bash ``` We build every product named on this page at 100monkeys.ai, so read the answers as a maker's account. They were drafted by one of our AI agents and reviewed by the company. ### How do you self-host an AI agent orchestrator with approvals and limits? Put the limits in the runtime, not the prompt: a declarative policy that denies by default, isolation for each run, and secrets the agent never holds. We build AEGIS by 100monkeys.ai, in beta: it is a self-hosted orchestrator that runs autonomous agents in isolated, policy-enforced runtimes with durable FSM state. Runs are isolated in micro-VMs or rootless containers, a keymaster holds the secrets, and workflows survive a crash or restart, which matters when a run is waiting on a person. It is open source under AGPL-3.0 and installs with one command: `curl -fsSL https://get.100monkeys.ai | bash` Install line and overview on [100monkeys.ai](https://100monkeys.ai/); documentation at [docs.100monkeys.ai](https://docs.100monkeys.ai/). ### How do I stop an AI agent from leaking API keys or credentials? Do not give the agent the credential. Anything in the agent's context can end up in its output, logs or a tool call, however the prompt is worded. The pattern that works is a broker: the agent asks for an action, and a component the agent cannot read attaches the secret on the way out. Combine that with a deny-by-default network and tool policy so a confused agent has nowhere to send things. AEGIS by 100monkeys.ai, in beta, which we build, does this with a keymaster that holds secrets so agents never see them, inside isolated, policy-enforced runtimes. Install line and overview on [100monkeys.ai](https://100monkeys.ai/); documentation at [docs.100monkeys.ai](https://docs.100monkeys.ai/). ### How do you keep a long-running AI agent workflow from losing its place when something crashes? Treat the workflow as a durable state machine rather than a process in memory: every step's result is recorded, and a restart resumes from the last recorded state instead of starting over. This matters most where a run pauses for a person, because a human approval can take an hour and a restart in that hour should not repeat acts already done. Engines such as Temporal exist for exactly this. AEGIS by 100monkeys.ai, in beta, which we build, runs agents with durable FSM state on Temporal workflows, so state survives a crash or restart. Install line and overview on [100monkeys.ai](https://100monkeys.ai/); documentation at [docs.100monkeys.ai](https://docs.100monkeys.ai/). ### What is an accountability sink, and does AI make it worse? The term is Dan Davies', from The Unaccountability Machine: a structure built to remove human discretion and absorb blame, so a decision happens and nobody made it. His test is that the extent to which you can change a decision is the extent to which you can be accountable for it. AI can make it worse because it is an easier scapegoat; in his words, decisions travel further than responsibility. The fix is not refusing AI but keeping a person able to see each decision, see why it was made, and stop it. That is the test we build to at 100monkeys.ai. More: [Red levers](https://100monkeys.ai/papers/red-levers), our paper on traceable, deterministic agents, and the essay [Nobody at the helm](https://medium.com/@jeshua_46811/nobody-at-the-helm-why-ai-needs-red-levers-48f5c6bde7c9). ### Carbon Forge questions Carbon Forge, the record people and agents share, answers these on its own site. Public workspaces are free, and every account includes one free private workspace. - [How do several coding agents share one repository without clobbering each other?](https://carbonforge.dev/faq#agents-share-one-repository) - [How do AI agents get shared memory across sessions?](https://carbonforge.dev/faq#shared-memory-across-sessions) - [How do you audit what an AI agent changed, and why?](https://carbonforge.dev/faq#audit-what-an-agent-changed) - [What is an MCP server for a knowledge base, and why would I want one?](https://carbonforge.dev/faq#mcp-server-for-a-knowledge-base) - [Does git work for teams of AI coding agents?](https://carbonforge.dev/faq#git-for-teams-of-agents) ### Zaru questions - [What is an AI companion that asks before it acts?](https://myzaru.com/faq?utm_source=100monkeys.ai&utm_medium=referral&utm_campaign=push-2026-10-28#companion-that-asks-before-it-acts) --- Source: https://100monkeys.ai/papers/red-levers Paper · CC BY 4.0 ## Red levers: traceable, deterministic agents in production Jeshua ben Joseph, 100monkeys AI, Inc. · 28 October 2026 [Download the PDF](https://100monkeys.ai/papers/red-levers.pdf) · [Product datasheets](https://100monkeys.ai/datasheets/) *Disclosure: this paper was drafted by an AI agent of 100monkeys.ai from the company's evidence pages and public documentation, and is issued by the company under its founder's name. 100monkeys.ai builds the three products described in sections 4, 6 and 8, so those sections are a maker's account. Every product statement traces to the company's evidence pages; the public sources are listed in the references.* ### Abstract Most of the systems that decide things about our lives were never designed by one mind and are owned by no one. Social scientists have described how such systems drift from their purpose and absorb blame, and how the people who once ran them by hand were also the people who could refuse. AI agents now take over that running, at machine speed and without the accidental safety of a person who can say no. This paper argues that an agent system is safe in production only when a person can see every decision it made, can read why it was made in words written at the moment it was made, and can stop it, before the act as well as after. We call the mechanisms that provide those three properties red levers, after Dan Davies' "red handles". We argue that each property belongs outside the model, in a deterministic layer around it: the runtime, the record and the approval. We then describe how three products from 100monkeys.ai embody one property each, state plainly what is not done yet, and list the public sources. ### 1. The problem: nobody at the helm Institutions accumulate. Money began as a ledger, bureaucracy as a memory aid, government as a coordination device. Each was a reasonable answer to a real problem, and the compounding of many reasonable answers across generations produced structures that nobody steers. Such a structure has no intent, only persistence. That is why it is hard to correct: an un-owned structure cannot be argued with, because there is no one to argue with. Robert K. Merton described one mechanism of this drift in 1940. In his account of bureaucratic structure, rules adopted as means come to be followed as ends: "an instrumental value becomes a terminal value" [1]. The people who wrote a rule knew what it was for. Their successors inherit the rule without the reason, and follow it because it is the rule. Harry Braverman described a second mechanism in 1974. Scientific management separated the conception of work from its execution, so that the people doing the work ran routines whose logic was held somewhere else [2]. For a long time, forms, queues, approvals and compliance checks were executed by people running a process they did not own and often could not see. Dan Davies, in *The Unaccountability Machine*, names the modern result: the accountability sink, a structure built to remove human discretion and absorb blame [3]. His test is simple: "The extent to which you are able to change a decision is precisely the extent to which you can be accountable for it, and vice versa." A scoring process refuses a loan; the person at the counter has no authority to change it, and the author of the policy sits behind layers of process. The decision happened. Nobody made it. The arrangement in which people were the runtime had one accidental safety property. People are slow, and people can refuse. A clerk can notice that a rule has produced something absurd and stop. Davies calls the mechanisms that allow this "red handles": the levers that let the people on the ground halt the machine when an automated rule produces an absurd or destructive outcome [3]. Over decades, many institutions removed them in the name of consistency and cost. AI agents remove the last of them by default. An agent that reads a ticket, edits a repository, sends an email or moves a record does the work of the clerk, faster and without the clerk's ability to object. Davies observes that AI "has intensified the problem by providing an even easier scapegoat, resulting in a world where decisions travel further than responsibility" [3]. The danger this paper addresses is not malice in the software. It is the same absence of anyone steering, now running at machine speed. Lisanne Bainbridge identified the engineering side of the same trap in 1983: automating a process leaves the human operator with the tasks the designer could not automate, while removing the practice the operator needs to perform them [4]. A person nominally "in the loop" who sees nothing until something has gone wrong is not in control of anything. The answer is not to put a person back into every step, which defeats the purpose of agents. It is to decide precisely where a person must be able to see, explain and stop, and to build those points so that they hold. Regulators have arrived at a similar list. Article 14 of the EU AI Act requires that high-risk AI systems "can be effectively overseen by natural persons during the period in which they are in use", and that the people overseeing them are enabled "to properly understand the relevant capacities and limitations" of the system and "duly monitor its operation", "to disregard, override or reverse the output", and "to intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state" [5]. We cite the Article for its list of what oversight requires. Nothing in this paper claims that any product makes a deployment compliant with it. ### 2. Three properties, and why they belong outside the model We define a safe agent system operationally. An AI system is safe when a person can see every decision it made, why it made it, and stop it. Each clause is a property that can be checked. **See.** Every action an agent takes leaves a record that a person can read later, complete and unaltered. A record that can be rewritten, or that holds only some actions, does not meet the property. **Explain.** Each recorded action carries the reason for it, written by its author at the moment of the action, not reconstructed afterwards from a diff or a log. A reason generated later is a guess about intent. Only the author, at the time, knows what the change was for, and for an agent the time is short: the session that made the change is discarded soon after. **Stop.** A person can prevent an act before it happens, both in advance (by limits the agent cannot exceed) and at the moment of a consequential act (by an approval that binds to that exact act). Stopping only after the fact is an incident report, not control. All three properties have to hold outside the model. A rule written in a prompt is a request: the model follows it most of the time, and under a long task, a clever input or simple drift it may not, with nothing outside the model noticing. A rule written in the runtime is a wall: if the policy says the agent cannot reach a host, the network call fails whatever the model decides. The same holds for the record and the approval. A model asked to keep an honest log keeps the log it keeps. A record that the agent writes through a narrow, append-only interface, and cannot edit afterwards, is honest by construction. This is what we mean by deterministic agents. The model at the centre stays probabilistic. Its surroundings do not: the policy decides the same way for the same request every time; a change lands completely or not at all; a recorded state renders to the same bytes every time it is read; an approval holds for exactly one state of the work and for nothing else. The AEGIS home page describes its execution loop in the same terms: "Generate, execute, evaluate, refine: the loop runs until deterministic validators pass." [6] In production, that means the parts a person relies on to see, explain and stop must not depend on the model's cooperation. The three properties also need durability. 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 from the start, which can repeat acts already done. Waiting for a person is only safe if the waiting survives a crash. We now describe one product for each property. The order is the order in which a person meets them: the runtime that holds the agent inside its limits, the record that keeps what it did and why, and the companion that asks before it acts. ### 3. Stop, in advance: limits enforced by the runtime The first lever is a yes given in advance, in a form a machine enforces and a person can read later. Before an agent runs, someone states what it may touch: which tools, which networks, which files, which secrets. Everything else is refused. Three design choices decide whether that lever holds. The default. 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, and agents find gaps quickly, not out of malice but because they try things. The boundary. The policy is only as strong as the isolation that enforces it. A policy checked inside the same process as the agent can be bypassed by the agent. Isolation at the kernel level, in a micro-VM or a rootless container, puts the check where the agent cannot reach it. The credentials. An agent that holds a credential can leak it, whatever its prompt says. An agent that is never handed the credential cannot. The credential stays with a broker that performs the authorised call on the agent's behalf. Self-hosting completes the lever. If the runtime holds the first yes, whoever runs the runtime holds it too. For agents that touch source code, customers or infrastructure, the person who decides what an agent may do belongs to the organisation that bears the consequences, on machines it controls, reading a policy it can audit. ### 4. AEGIS: the runtime that enforces the limits AEGIS by 100monkeys.ai, in beta, is our runtime for this first lever. 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." [6] Its security policy is declarative and deny-by-default. Agent runs are isolated at the kernel level, in micro-VMs (Firecracker [7]) 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; the SEAL gateway is a standalone component that AEGIS uses, not a part of AEGIS. Workflows are durable, built on Temporal [8], so the state of a run, including a run waiting for a person, survives a crash or a restart. AEGIS is built to enforce limits by architecture rather than by promises. AEGIS is open source under the AGPL-3.0 [9], with its orchestrator on GitHub [10] and documentation at docs.100monkeys.ai [11]. It installs with one line, copied from its home page: `curl -fsSL https://get.100monkeys.ai | bash` ### 5. Explain: a record where every change says why The second lever is the record. Source control was designed for people, and it assumes the author is still around. Every engineer has run blame on a puzzling line and found a name, a date and the message "fix", then walked over to ask the colleague. Blame was a pointer to a person who held the reason in their head. When the author is an agent, that assumption fails. The session that wrote the line is gone, its context discarded soon after it landed the change. If the reason was not written down at the moment of the change, it exists nowhere. A record built for agents has to hold five things. The reason, in the author's words, written when the change lands. The whole change or none of it, so the code and the page that documents it never disagree halfway. No silent merges, because a merged line that neither author wrote is a line nobody intended. A history that cannot be rewritten, so a later reader can trust what they read. And approval bound to exactly what was approved, so a patch made after review voids the review. Scale makes this urgent. Anthropic's write-up on its own source-control system, Scion, describes merges to its monorepo going from about 2,500 a day in May 2026 to over 30,000 a day in September, as agent work grew [12]. Its stated principles are that clients are always online, that commits are cheap, incremental and lock-free, and that the working copy is optional and sparse. Those are Anthropic's figures about Anthropic; we cite them for the direction of travel, not as a claim about any product of ours. ### 6. Carbon Forge: the record where every change says why Carbon Forge is our record. Each sentence below is what its public documentation states [13][14][15][16][17]. Carbon Forge keeps code, files and prose in one record on the server, and people and agents read and write it through the same tools. An agent opens a lane instead of cloning: a lane is a set of patches over the trunk, and every read on it composes the trunk as it stands now with those patches. A landing is one changeset: every page, atom, code tree and file it names is written in one transaction, or nothing is. A code change and the page that documents it land in the same changeset, together or not at all. Carbon Forge never merges text by itself. A patch that no longer applies is reported as a named conflict, and the caller answers it against the trunk it saw. Every revision and every changeset is hash-chained, and a revert is a new landing, so history only moves forward. A cut names one sealed snapshot of the workspace and never moves, so a release has one answer for as long as the workspace exists. Blame, grep, diff and history run on the server, and blame shows next to each line the intent the agent wrote when it landed it. The question "why is this line here" is answered with the author's own sentence, written at the moment it mattered. On a protected trunk, a landing-rules page names the approvers each path needs, and an approval binds to the lane's exact state, so a later patch voids it. Git is a projection: every code tree renders to a git history and pushes to GitHub fast-forward only, so git tooling keeps working. Agents reach Carbon Forge over the Model Context Protocol [18] with the same tools the editor uses, and a token can be held to a preset such as SCM reader, which writes nothing. Public workspaces are free and every account includes one free private workspace. Plans for further private workspaces are at [https://carbonforge.dev/pricing](https://carbonforge.dev/pricing). ### 7. Stop, at the act: the approval bound to one message The third lever is a yes given at the moment of the act. The agent has prepared something consequential, an email to a stranger, a payment, a deletion, and it stops. A person reads the exact thing about to happen and approves or refuses that one act. This lever fails in a quieter way than the first. If the approval attaches to a description of the act rather than the act, the agent can change the act after the yes. If it is a general permission ("you may send emails"), it is the first lever again, given carelessly. If it appears so often that people click through it, or after the act as a notification, it is not a yes at all. A useful approval shows the exact thing, binds to that exact thing, and stops counting if the thing changes. One message, read and approved. Then the next. ### 8. Zaru: the companion that asks before it acts Zaru is a personal AI that works alongside its user, remembers them and shows its work. Its memory of the person is theirs to read and edit. The principle behind it is that every other AI harness asks the user to trust it, and Zaru shows the user instead. Its site describes it as "The AI that remembers you and shows every step" and states: "Nothing gets sent until you say yes." Zaru is sold by My Zaru, Inc. at myzaru.com [19]. Here is what the third lever looks like in our own use. When Zaru's mail tool sends an email for our founder, by default the send does not happen. The tool answers that approval is pending, and the message waits in Zaru's web app under Approvals until he approves that one message. We report this as measured in the company's own use on 28 October 2026, not as a property verified for every account. ### 9. How the three fit together The three levers are separate products, and they connect through general interfaces rather than private ones. Carbon Forge's documentation states that it holds no code written for AEGIS or for Zaru; every connection is one of its general surfaces: the MCP endpoint, signed webhooks, the git archive and imports [20]. One connection matters for this paper: a landing rule on a protected trunk can name an AEGIS workflow as a gate, satisfied only by that workflow's own approval [15]. Put together, a person can follow one piece of agent work end to end. The runtime limited what the agent could touch while it worked. The record holds what it changed, all or nothing, with the sentence it wrote about why. The approval held the consequential act until a person said yes to that act. None of this requires trusting the model to report on itself. ### 10. What is not done yet We state the limits plainly, because a paper about traceability that hid its own gaps would refute itself. **AEGIS is in beta.** Its home page still prints "Pre-alpha" at the time of writing [6], and the outward wording is being brought into line. Its design has run ahead of its implementation: several of its design records are marked partially implemented. Reliability, cost and latency figures that appear in internal design work are modelled, not measured, and none is claimed here. **Carbon Forge has documented limits.** In its own words: "No offline work", "No automatic merge", "No merge queue and no built-in CI", "No per-directory permissions", "No git push into Carbon" [21]. It is not a real-time collaborative editor (one writer per page at a time), and its search is English only [14]. Nothing in this paper claims any throughput or scale figure for Carbon Forge; the Scion figures in section 5 describe Anthropic. **Zaru's approval step is described as measured in our own use.** By default, a send from its mail tool waits for approval. Whether that default holds for every account, and in every configuration, has not been verified. The open-source Zaru command-line harness is a separate surface and is pre-alpha. **No product makes an AI system safe by itself.** These products keep a person in a position to see, explain and stop. They do not decide well on the person's behalf, they do not make a deployment compliant with any regulation, and they have not been audited by a third party. We make no customer, user or adoption claim. **The argument in section 1 is a synthesis.** The scholarly quotations are given with attribution to the works cited; readers who want them verbatim in context should read the sources. ### 11. Disclosure 100monkeys AI, Inc. (100monkeys.ai) builds AEGIS by 100monkeys.ai, Carbon Forge and Zaru, the products described in sections 4, 6 and 8. Zaru is sold by My Zaru, Inc. This paper was drafted by an AI agent of 100monkeys.ai from the company's evidence pages and public documentation, and is issued by the company under the name of its founder, Jeshua ben Joseph, who is the contact for it: jeshua@100monkeys.ai. To start with the record: [https://carbonforge.dev/?utm_source=100monkeys.ai&utm_medium=article&utm_campaign=push-2026-10-28](https://carbonforge.dev/?utm_source=100monkeys.ai&utm_medium=article&utm_campaign=push-2026-10-28) ### References Every URL below was fetched on 28 October 2026 between 15:55 and 16:03 UTC and answered HTTP 200, except reference 1, whose DOI resolver refused automated access; its metadata was confirmed through the Crossref API at 15:55:57 UTC. 1. Merton, R. K. (1940). Bureaucratic Structure and Personality. *Social Forces*, 18(4), 560 to 568. [https://doi.org/10.2307/2570634](https://doi.org/10.2307/2570634) 2. Braverman, H. (1974). *Labor and Monopoly Capital: The Degradation of Work in the Twentieth Century*. Monthly Review Press. [https://monthlyreview.org/product/labor_and_monopoly_capital/](https://monthlyreview.org/product/labor_and_monopoly_capital/) 3. Davies, D. (2024). *The Unaccountability Machine: Why Big Systems Make Terrible Decisions, and How the World Lost Its Mind*. Profile Books. [https://profilebooks.com/work/the-unaccountability-machine/](https://profilebooks.com/work/the-unaccountability-machine/) 4. Bainbridge, L. (1983). Ironies of automation. *Automatica*, 19(6), 775 to 779. [https://doi.org/10.1016/0005-1098(83)90046-8](https://doi.org/10.1016/0005-1098(83)90046-8) 5. Regulation (EU) 2024/1689 (the AI Act), Article 14: Human oversight. [https://artificialintelligenceact.eu/article/14/](https://artificialintelligenceact.eu/article/14/) 6. 100monkeys.ai, home page of AEGIS by 100monkeys.ai, read 28 October 2026 at 15:47 UTC. [https://100monkeys.ai/](https://100monkeys.ai/) 7. Firecracker microVM. [https://firecracker-microvm.github.io/](https://firecracker-microvm.github.io/) 8. Temporal, durable execution. [https://temporal.io/](https://temporal.io/) 9. GNU Affero General Public License, version 3. [https://www.gnu.org/licenses/agpl-3.0.html](https://www.gnu.org/licenses/agpl-3.0.html) 10. aegis-orchestrator, source repository. [https://github.com/100monkeys-ai/aegis-orchestrator](https://github.com/100monkeys-ai/aegis-orchestrator) 11. AEGIS documentation. [https://docs.100monkeys.ai/](https://docs.100monkeys.ai/) 12. Anthropic (13 October 2026). Redesigning source control at Anthropic. [https://www.anthropic.com/research/redesigning-source-control](https://www.anthropic.com/research/redesigning-source-control) 13. Carbon Forge docs: Source control on the substrate. [https://carbonforge.dev/docs/p/features/source-control-on-the-substrate](https://carbonforge.dev/docs/p/features/source-control-on-the-substrate) 14. Carbon Forge docs: Overview. [https://carbonforge.dev/docs/p/overview](https://carbonforge.dev/docs/p/overview) 15. Carbon Forge docs: Working in lanes. [https://carbonforge.dev/docs/p/guides/lanes](https://carbonforge.dev/docs/p/guides/lanes) 16. Carbon Forge docs: The Carbon paradigm. [https://carbonforge.dev/docs/p/architecture/carbon-paradigm](https://carbonforge.dev/docs/p/architecture/carbon-paradigm) 17. Carbon Forge docs: Source control at agent scale. [https://carbonforge.dev/docs/p/use-cases/source-control-at-agent-scale](https://carbonforge.dev/docs/p/use-cases/source-control-at-agent-scale) 18. Model Context Protocol. [https://modelcontextprotocol.io/](https://modelcontextprotocol.io/) 19. Your Zaru, My Zaru, Inc. [https://myzaru.com/](https://myzaru.com/) 20. Carbon Forge docs: The full workflow with AEGIS and Zaru. [https://carbonforge.dev/docs/p/use-cases/full-workflow-with-aegis-and-zaru](https://carbonforge.dev/docs/p/use-cases/full-workflow-with-aegis-and-zaru) 21. Carbon Forge docs: Source control: how it is built and why. [https://carbonforge.dev/docs/p/architecture/source-control](https://carbonforge.dev/docs/p/architecture/source-control) This work is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0), [https://creativecommons.org/licenses/by/4.0/](https://creativecommons.org/licenses/by/4.0/). Copyright 2026 100monkeys AI, Inc. --- Source: https://100monkeys.ai/datasheets/ Datasheets ## One page on each product A one-page PDF for each of the three products 100monkeys.ai builds, for reading offline or passing to a colleague. The longer argument behind them is our paper [Red levers](https://100monkeys.ai/papers/red-levers). ### AEGIS by 100monkeys.ai The open-source orchestrator that holds AI agents inside their limits. In beta. [Datasheet (PDF)](https://100monkeys.ai/datasheets/aegis.pdf) · [100monkeys.ai](https://100monkeys.ai/?utm_source=100monkeys.ai&utm_medium=referral&utm_campaign=push-2026-10-28) ### Carbon Forge The record people and AI agents share, where every change carries its reason. [Datasheet (PDF)](https://100monkeys.ai/datasheets/carbon-forge.pdf) · [carbonforge.dev](https://carbonforge.dev/?utm_source=100monkeys.ai&utm_medium=referral&utm_campaign=push-2026-10-28) ### Zaru The AI companion that asks before it acts. [Datasheet (PDF)](https://100monkeys.ai/datasheets/zaru.pdf) · [myzaru.com](https://myzaru.com/?utm_source=100monkeys.ai&utm_medium=referral&utm_campaign=push-2026-10-28) Carbon Forge: public workspaces are free, and every account includes one free private workspace; see [carbonforge.dev/pricing](https://carbonforge.dev/pricing). --- Source: https://100monkeys.ai/blog/run-a-scheduled-agent-with-aegis [Blog](https://100monkeys.ai/blog/) · Guide · 28 October 2026 ## Run a scheduled agent with AEGIS: schedules, runs and what you see when one fails Also in: [Español](https://100monkeys.ai/blog/es/run-a-scheduled-agent-with-aegis), [Português](https://100monkeys.ai/blog/pt/run-a-scheduled-agent-with-aegis), [日本語](https://100monkeys.ai/blog/ja/run-a-scheduled-agent-with-aegis) Disclosure: 100monkeys.ai builds AEGIS, so read this guide as a maker's account. It was drafted by one of our AI agents from the public AEGIS documentation, chiefly the [Schedules](https://docs.100monkeys.ai/docs/workflows/schedules) page and the [Schedule Tools](https://docs.100monkeys.ai/docs/reference/management-tools#schedule-tools) reference, and reviewed by the company. Every field, route and message below is quoted from those pages. We did not run these calls for this guide, and where the docs leave a step open we say so. AEGIS by 100monkeys.ai, in beta, is a self-hosted orchestrator that runs autonomous agents in isolated, policy-enforced runtimes. This guide puts one of your agents on a timer, reads back what each fire did, and shows the four outcomes a fire can have, so a run that did not happen is as visible as one that did. ### What a schedule is The docs define it in one sentence: "A schedule starts one of your agents or workflows as you, either once at a time you choose or again and again on a recurrence." Three consequences follow, and each one shapes the steps below. - A schedule is your own object, "never a field of the agent or workflow it runs". - It runs as a person. "A schedule always runs as a person. A service account, or an operator acting for no person, cannot make, change, pause, resume, run or delete one." - Each fire is an ordinary run. "At each fire the orchestrator starts the run exactly as `aegis.task.execute` or `aegis.workflow.run` would for you, with the schedule's intent, input and connections." ### Step 1. Pick the agent and the timing Use an agent you have already run once by hand with `aegis task execute `, so you know what a good run looks like. Then choose one of two timings. You give exactly one of them. - **Once:** `at`, an RFC 3339 time "at least one minute from now and at most a year ahead". - **Recurring:** `recurrence` with `cron`, `timezone` and `jitter_seconds`. The cron has five fields (minute, hour, day of month, month, day of week), "no seconds field and no `@daily`-style shorthand". The time zone is an IANA name and defaults to `UTC`. Jitter delays each run by a random amount up to that many seconds, at most 3600. Two limits to plan around: "A schedule runs at most once every 5 minutes", and you may hold at most 25 schedules that are not deleted. ### Step 2. Choose what the run may reach A scheduled run reaches only the connections its `profile` or `contexts` name, and "a schedule with neither reaches none of your connections." A schedule carries one or the other, never both. If your agent reads mail or a repository, name the profile now; otherwise the fire will be refused for a missing connection, and the refusal will say so. ### Step 3. Create the schedule There is no `aegis schedule` shell command in the CLI Reference. You create a schedule with the REST route `POST /v1/schedules` (scope `schedule:write`), with the MCP tool `aegis.schedule.create`, or from the Schedules page in Zaru. The tool takes these arguments, as the reference lists them: ``` aegis.schedule.create { "name": "Morning inbox triage", "target_kind": "workflow", "target": "email-inbox-triage", "intent": "Sort the new mail", "input": { "mailbox": "ann@example.com" }, "recurrence": { "cron": "*/30 * * * *", "timezone": "UTC", "jitter_seconds": 300 } } ``` That example is the docs' own schedule. Swap `target_kind` to `agent` and `target` to your agent's name. The answer is `{"schedule": {...}}` with its `state`, `next_run_at` and `last_run`. Read `next_run_at` back before you walk away. ### Step 4. Fire it once, now Do not wait for the first scheduled time to learn whether it works. The owner can start one run immediately with `POST /v1/schedules/{id}/run` or `aegis.schedule.run_now`. It runs "exactly as a fire starts it: as the owner, with the schedule's target, input, connections or profile, and attachments", and "nothing else changes": the schedule keeps its state and timing. ### Step 5. Read the runs ``` aegis.schedule.runs { "schedule_id": "", "limit": 20 } ``` The route is `GET /v1/schedules/{id}/runs?limit=`. Runs come newest first, each with its `scheduled_time` (`null` for a run started now), `fired_at`, `outcome`, `detail` and `execution` (its `id`, `kind` and `status`). Take the execution id to the CLI to read the run itself: `aegis task logs `, with `--errors-only` when you want only the failures. ### Step 6. Know the four outcomes Every fire is recorded once per scheduled time, so a fire Temporal repeats "answers the first fire's record instead of starting a second run". Each record has one outcome: - `started`: the run started, and the fire records its execution id. - `skipped_overlap`: "The run the previous fire started is still running, so this fire starts nothing." Zaru shows it as "Skipped: the last run was still running". - `skipped_paused`: the schedule is paused. - `refused`: "The run could not start. The fire records the refusal's sentence, for example a required connection that was not chosen." A `started` outcome says the run began, not that it succeeded. The run's own status is in `execution.status`, and the reason it failed is in its logs. ### Step 7. Know what happens when fires keep failing "When the last three fires of a recurring schedule were all refused, the schedule pauses itself, with the reason 'Paused after three runs could not start: .'" Read `paused_reason` on the schedule, fix the cause, then resume with `aegis.schedule.resume`. A fire missed while the orchestrator restarts "is still made up to 10 minutes late; later than that, the time is skipped." ### Step 8. Approvals still apply A scheduled run acts as you, "so every tool call that waits for your approval in a conversation waits for it in a scheduled run too". In Zaru the request is listed on the Approvals page "From your schedule ". ### What the docs leave open - A shell command. The CLI Reference lists no schedule subcommand, so self-hosters use the REST routes or an MCP client. - Who "you" is on the local stack. Schedules run as a person and need `schedule:write`, while the `aegis init` stack runs with no IAM. The docs do not say how a schedule is owned there; we did not test it. ### Next To put a person between the scheduled agent and anything it sends, read [How to give an orchestrator an approval step](https://100monkeys.ai/blog/approval-step-for-an-agent-orchestrator). To read what a run did, read [Reading an AEGIS execution log](https://100monkeys.ai/blog/reading-an-aegis-execution-log). [Install AEGIS from 100monkeys.ai](https://100monkeys.ai/) --- Source: https://100monkeys.ai/blog/reading-an-aegis-execution-log [Blog](https://100monkeys.ai/blog/) · Guide · 28 October 2026 ## Reading an AEGIS execution log: what a sealed tool call records Also in: [Español](https://100monkeys.ai/blog/es/reading-an-aegis-execution-log), [Português](https://100monkeys.ai/blog/pt/reading-an-aegis-execution-log), [日本語](https://100monkeys.ai/blog/ja/reading-an-aegis-execution-log) Disclosure: 100monkeys.ai builds AEGIS, so read this guide as a maker's account. It was drafted by one of our AI agents from the public AEGIS documentation, chiefly [Deploying & Running Agents](https://docs.100monkeys.ai/docs/agents/deploying-agents), the [CLI Reference](https://docs.100monkeys.ai/docs/reference/cli), the [SEAL Protocol](https://docs.100monkeys.ai/docs/gateway/seal-protocol) page and the gateway's [Observability](https://docs.100monkeys.ai/docs/gateway/observability) page, and reviewed by the company. The log lines, fields and codes below are the docs' own examples, not output we captured for this guide. AEGIS by 100monkeys.ai, in beta, runs each agent in its own isolated runtime and sends its tool calls through a signed protocol called SEAL. This guide reads one run from the outside in: the execution record, the iteration log, and then what the SEAL layer records about a single tool call, allowed or refused. ### Why the execution is the unit The [Executions](https://docs.100monkeys.ai/docs/concepts/executions) page puts it plainly: "Each execution is the unit of observability and replay in AEGIS. Logs, tool calls, blackboard snapshots, and refinement trajectories are all anchored to an execution ID." Every step below starts from that id. An execution runs the loop "Execute, Evaluate, Refine" and finishes "when the agent produces output that satisfies its evaluation criteria, when the iteration budget is exhausted, or when an unrecoverable failure occurs." ### Step 1. Find the execution id `aegis task execute` prints it as it starts (`Execution started: `). For runs you did not start yourself, list them: ``` aegis task list aegis task list --agent-id aegis task list --limit 20 ``` A scheduled run carries its execution id in the schedule's runs list; a workflow run is listed by `aegis workflow executions list`. ### Step 2. Read the execution record ``` aegis task status --output json ``` The docs say this "returns the execution record, including status, start/end timestamps, total iterations, and each iteration's status and validation scores." Read the iteration count first. One iteration that passed is a clean run; several iterations mean the output failed validation and was refined, and the log will show why. ### Step 3. Read the iteration log ``` aegis task logs ``` The docs' example of what a run prints, line for line: ``` [2026-02-23T10:00:01Z] Execution a1b2c3d4-1111-... Started [2026-02-23T10:00:01Z] Iteration 1 Started [2026-02-23T10:00:03Z] Tool: fs.write /workspace/solution.py (234 bytes) [2026-02-23T10:00:04Z] Tool: cmd.run python /workspace/solution.py [2026-02-23T10:00:05Z] Tool: fs.write /workspace/result.json (89 bytes) [2026-02-23T10:00:06Z] Iteration 1 Completed [2026-02-23T10:00:06Z] Validation: exit_code=PASS json_schema=PASS (score=1.0) [2026-02-23T10:00:06Z] Execution a1b2c3d4-1111-... Completed (1 iteration, 5.2s) ``` Read it as three kinds of line: the lifecycle (started, completed), one `Tool:` line per call the agent made, and a `Validation:` line with each validator's verdict and the score. Add `--errors-only` to see only failures, `--verbose` for more detail, and `--follow` to watch a live run. For a workflow, `aegis workflow logs --transitions` shows only the state changes. ### Step 4. Know what stands behind each Tool line Each `Tool:` line is one call that went through SEAL. "Every tool call is wrapped in a `SealEnvelope`": the protocol (`seal/v1`), a `security_token` (a JWT issued at attestation), an Ed25519 `signature`, the `payload` (for MCP-style calls, a JSON-RPC `tools/call`), a `container_id` and an integer `timestamp`. The token's claims are what tie the call to your run: `sub` (the caller), `scp` (the name of the security context), `wid` (the workload), and `exec_id`, which "ties every call in a session to one audit chain". So the execution id from Step 1 is the key that joins the log line to its envelope. ### Step 5. Read why a call was allowed The gateway runs nine checks before it forwards a call: the protocol field, the token's signature and expiry, the caller's registered key, the envelope signature over a canonical message, a timestamp within 30 seconds, and finally the security context named in `scp`. That last check denies anything on the deny list, allows a call only when a capability matches its tool, path, domain or subcommand and rate limit, and otherwise denies "(default deny)". The context cannot change mid-session: "callers cannot widen their context, switch contexts, or impersonate a different one." ### Step 6. Read a refusal A refused call is not a silent gap in the log. On the SEAL Gateway it answers a numeric code. The ones you will meet most: - `2000` to `2006`: policy. Tool not granted, tool on the deny list, path outside `path_allowlist`, command outside `command_allowlist`, domain outside `domain_allowlist`, rate limit reached, no capability matched. - `1003` `TOKEN_EXPIRED`: the token expired, the timestamp was outside the 30-second window, or the `jti` was already seen, which is how a replayed envelope shows up. - `1001` and `1002`: a signature that is malformed or does not verify. The docs say to "switch on `error.code`, not on the status", and note one trap: the orchestrator's own `POST /v1/seal/invoke` answers a refusal with a string code such as `TOOL_NOT_ALLOWED` instead of a number. ### Step 7. Read the audit record The SEAL Protocol page lists the events each call produces, including `ToolCallAuthorized` and `PolicyViolationBlocked`, and what each captures: the envelope's signature, timestamp and `jti`; the token's `sub`, `scp`, `wid` and `exec_id`; the tool name and "payload digest (not the full payload, payloads are not logged by default)"; and "the policy decision (`ALLOW` or `DENY` plus the deciding rule, if any)". The signature is what gives non-repudiation: "only the holder of the ephemeral private key could have produced a valid signature." On a standalone SEAL Gateway those rows live in the `gateway_events` table. There is no REST endpoint for them yet; the docs give SQL instead: ``` SELECT event_type, created_at, payload FROM gateway_events WHERE payload->>'execution_id' = 'exec-1234' -- Postgres JSONB syntax ORDER BY created_at; ``` The table is append-only, so ship it to your SIEM by polling for ids above the last one you sent. ### What the docs leave open - The two event lists differ. The SEAL Protocol page names `PolicyViolationBlocked`; the gateway's `gateway_events` table, as Observability lists it, does not. Which table holds a denial is not stated. - Ports. The SEAL page puts the orchestrator on `8080`; the CLI's default API port is `8088`. - The gateway has no metrics endpoint and no OTLP traces yet; the Observability page says so itself. ### Next For what a reviewer needs beside these logs, read [A traceability checklist for AI agents in production](https://100monkeys.ai/blog/ai-agent-traceability-checklist). [Install AEGIS from 100monkeys.ai](https://100monkeys.ai/) --- Source: https://100monkeys.ai/blog/aegis-on-firecracker [Blog](https://100monkeys.ai/blog/) · Guide · 28 October 2026 ## Self-host AEGIS with Firecracker: the setup the docs describe, and what runs today Also in: [Español](https://100monkeys.ai/blog/es/aegis-on-firecracker), [Português](https://100monkeys.ai/blog/pt/aegis-on-firecracker), [日本語](https://100monkeys.ai/blog/ja/aegis-on-firecracker) Disclosure: 100monkeys.ai builds AEGIS, so read this guide as a maker's account. It was drafted by one of our AI agents from the public AEGIS documentation, chiefly [Firecracker Deployment](https://docs.100monkeys.ai/docs/deployment/firecracker), [What are Agents?](https://docs.100monkeys.ai/docs/agents/overview), [Infrastructure Requirements](https://docs.100monkeys.ai/docs/deployment/infrastructure) and [Podman Deployment](https://docs.100monkeys.ai/docs/deployment/podman), and reviewed by the company. Every command and configuration block is copied from those pages. We ran none of them for this guide. AEGIS by 100monkeys.ai, in beta, is a self-hosted orchestrator for autonomous agents. Its docs describe Firecracker microVMs as the isolation for hardened production. Read the first line of that page before you buy hardware: "Firecracker support is planned for a future release and is not yet available. The Docker and Podman runtimes are the current deployment targets." This guide covers what you can do today: check a host, read the configuration the docs document for the planned runtime, and run the Podman path that ships now. ### Why Firecracker, in the docs' words "Docker containers share the host kernel: a container escape vulnerability could give a malicious prompt-injected agent code execution on the host. Firecracker provides hardware-level isolation via KVM." The page's comparison gives each agent "a dedicated guest kernel per agent", a blast radius on escape "bounded to single microVM", and storage over virtio-fs, "shared memory, no network", where containers use NFS. The trade it states is a boot of about 125 ms against about 100 ms for a container. The design keeps agents unchanged across runtimes: "Switching a node from Docker to Podman or Firecracker requires only a config change: no agent manifest changes needed." That is why preparing now is not wasted work. ### Step 1. Check the host for KVM Firecracker needs KVM, which the docs say means "bare-metal Linux servers with Intel VT-x or AMD-V CPU virtualization extensions", or cloud instances that are bare metal or have nested virtualization. It is "NOT supported on standard EC2 instances without bare-metal, most VMs (including standard VMs on most cloud providers), and macOS (Docker Desktop)." The docs' checks, copied: ``` # Check for KVM device nodes ls -la /dev/kvm # Verify CPU virtualization extensions grep -cw vmx /proc/cpuinfo # Intel (should return > 0) grep -cw svm /proc/cpuinfo # AMD (should return > 0) ``` If `/dev/kvm` is missing on a cloud VM, that host will not run the Firecracker runtime when it ships, whatever else it has. ### Step 2. Check the kernel Run `uname -r` and compare it with the docs. Two pages give two minimums: What are Agents? lists "Bare-metal or KVM-passthrough host, Linux kernel 5.10+", and Infrastructure Requirements lists "Linux kernel 5.15+" with "KVM support for Firecracker (planned later phase)". Plan for 5.15 or later and you satisfy both. ### Step 3. Read the configuration the docs document The planned runtime is configured in `aegis-config.yaml` under `runtime.firecracker`. The page's block, copied: ``` runtime: type: firecracker firecracker: # Path to the jailer binary jailer_binary: /usr/local/bin/jailer # Path to the Firecracker VMM binary firecracker_binary: /usr/local/bin/firecracker # User/group for the jailed process uid: 65534 # nobody gid: 65534 # Kernel image for microVMs kernel_image_path: /opt/aegis/vmlinux # Root filesystem for agent microVMs (minimal Linux + Python) rootfs_path: /opt/aegis/agent-rootfs.ext4 # CPU and memory limits vcpu_count: 2 mem_size_mib: 512 # cgroup version (v1 or v2) cgroup_version: v2 ``` Read it for what it asks of the host: a jailer and a Firecracker binary, an unprivileged uid and gid, a guest kernel image, an agent root filesystem, and per-VM CPU and memory. The jailer "drops privileges before starting the VMM": a `chroot` jail, a pre-created tap interface and cgroup, and `seccomp` filters. Each microVM gets its own tap device, and "outbound traffic from the microVM is routed through the orchestrator proxy (SEAL), not directly to the internet." Do not deploy this block today. The docs do not say where the kernel image and root filesystem come from, and the runtime that reads them is described as "in development". ### Step 4. Run AEGIS today on Podman For production now, the docs point to the [aegis-deploy](https://github.com/100monkeys-ai/aegis-deploy) repository: "`aegis-deploy` is the recommended production deployment path. It includes OpenBao (secrets management), TLS via Caddy, and full observability." Its quick start, copied: ``` # Clone the deployment repo git clone https://github.com/100monkeys-ai/aegis-deploy.git cd aegis-deploy # Copy and edit environment configuration cp .env.example .env # Edit .env with your values (GHCR credentials, passwords, LLM API keys) # Install system dependencies (Ubuntu) make setup # Authenticate with GitHub Container Registry make registry-login # Generate SEAL signing keys make generate-keys # Deploy the full stack make deploy PROFILE=full # Validate all services are healthy make validate # Bootstrap secrets make bootstrap-secrets ``` Podman runs agents rootless, which the docs credit with eliminating "the privileged daemon" and mapping container root "to an unprivileged host UID". For evaluation on one machine, the one-line installer printed on [100monkeys.ai](https://100monkeys.ai/) is `curl -fsSL https://get.100monkeys.ai | bash`, which brings up the local Docker stack; the docs mark that stack as "for local testing and evaluation only". ### Step 5. Keep the switch to a config change Write your agent manifests without pinning isolation, so the node decides. The manifest field `isolation` accepts `inherit`, `firecracker`, `docker` and `process`, and its default is `inherit`, "from node config". The configuration reference's example sets the node's `default_isolation` to `docker`, a value that "works with both Docker and Podman runtimes". When Firecracker ships, the change is the node's, not each agent's. ### Step 6. Follow the work The page ends: "Monitor progress on Firecracker support in the [aegis-orchestrator GitHub repository](https://github.com/100monkeys-ai/aegis-orchestrator)." That is where a release that ships the runtime will be named. ### What the docs leave open - A date or version for Firecracker support. - Where the guest kernel (`vmlinux`) and the agent root filesystem come from, and how to build them. - The minimum kernel: 5.10 on one page, 5.15 on another. - Other pages still describe Firecracker as the hardened production runtime without the "not yet available" warning, so read the Firecracker page itself as the current word. ### Next To install the evaluation stack and run a first agent behind an approval, read [Install AEGIS on a fresh Ubuntu VPS and run your first approved task](https://100monkeys.ai/blog/install-aegis-on-ubuntu-vps). [Install AEGIS from 100monkeys.ai](https://100monkeys.ai/) --- Source: https://100monkeys.ai/blog/install-aegis-on-ubuntu-vps [Blog](https://100monkeys.ai/blog/) · Guide · 28 October 2026 ## Install AEGIS on a fresh Ubuntu VPS and run your first approved task Also in: [Español](https://100monkeys.ai/blog/es/install-aegis-on-ubuntu-vps), [Português](https://100monkeys.ai/blog/pt/install-aegis-on-ubuntu-vps), [日本語](https://100monkeys.ai/blog/ja/install-aegis-on-ubuntu-vps), [Deutsch](https://100monkeys.ai/blog/de/install-aegis-on-ubuntu-vps), [Français](https://100monkeys.ai/blog/fr/install-aegis-on-ubuntu-vps) Disclosure: 100monkeys.ai builds AEGIS, so read this guide as a maker's account. It was drafted by one of our AI agents from the public AEGIS documentation at [docs.100monkeys.ai](https://docs.100monkeys.ai/docs/getting-started) and reviewed by the company. Every command below is copied from those docs or from our home page. We did not run this exact sequence on a fresh VPS for this guide, and where the docs disagree with each other we say so instead of guessing. AEGIS by 100monkeys.ai, in beta, is a self-hosted orchestrator that runs autonomous agents in isolated, policy-enforced runtimes with durable state. This guide takes a fresh Ubuntu server to a running local stack, then runs one agent behind a human approval gate, so the agent's work stops and waits until you answer yes. ### Before you start Know what the quick install is for. The Getting Started page says it plainly: `aegis init` "is designed for local testing and evaluation only. It uses an in-memory secrets store and does not deploy Keycloak (IAM) or OpenBao (secrets management)." The Infrastructure Requirements page lists its IAM as "None (unauthenticated)" and its TLS as "None". For production the docs point to the [aegis-deploy](https://github.com/100monkeys-ai/aegis-deploy) repository instead. So on a VPS, treat this stack as a private lab. The CLI's health checks default to host `127.0.0.1` and port `8088`. Do not open that port to the internet; reach the box over SSH. You need: - An Ubuntu or Debian server you can reach over SSH with a user that can run `sudo`. The installer "runs on Ubuntu or Debian (it needs `apt-get`)". - An x86_64 machine. The release the installer pins carries the Linux x86_64 archive, `aegis-linux-x86_64.tar.gz`. - An API key for a model provider. The docs' provider page covers OpenAI, Anthropic and Ollama, under the bring-your-own-model alias system. ### Step 1. Run the installer Copy the line from [100monkeys.ai](https://100monkeys.ai/), where it is printed, and run it as your normal user: ``` curl -fsSL https://get.100monkeys.ai | bash ``` Read the script first if you prefer. The docs say `https://get.100monkeys.ai` redirects to `install.sh` on the `main` branch of [aegis-orchestrator](https://github.com/100monkeys-ai/aegis-orchestrator). On Linux it installs `curl`, `ca-certificates` and `fuse3` where missing, installs `libfuse3` where the binary needs it, and installs Docker Engine (`docker-ce`) when Docker is absent. When Docker runs but your user cannot reach it, it adds you to the `docker` group. It then installs `aegis` to `/usr/local/bin/aegis` and starts the stack with `aegis up --tag `. To pin a release, set `AEGIS_VERSION` to a release tag before running it; the docs list every published package on the Releases page. ### Step 2. Check the binary and the stack ``` aegis --version aegis status ``` `aegis status` reports local stack health. If you were added to the `docker` group during the install, log out and back in so new shells carry the group. ### Step 3. Run the guided setup and choose a model provider ``` aegis init ``` The wizard "prepares stack files, configures the node, starts Docker Compose services, verifies health, and can optionally load smoke-test agents". Accept the hello-world smoke test when it asks; the next step uses it. The configuration it writes maps the model aliases `default`, `smart`, `judge` and `tool-judge` on the provider you choose. The hello-world agent names `smart`, and an alias the node does not map fails with `Model alias '' not found`, so finish the provider prompt. Stack files go to `~/.aegis` unless you pass `--dir`. ### Step 4. Run hello-world once, unattended Prove the loop works before you add a gate: ``` aegis task execute hello-world \ --input '{"task": "Write a Python function that returns the Fibonacci sequence up to n."}' \ --follow ``` `--follow` streams iteration events. The agent generates code, runs validation, and either succeeds or refines across iterations until its validators pass. ### Step 5. Write a workflow with an approval gate An approval in AEGIS is a workflow state of `kind: Human`. Save this as `approved-task.yaml`. It follows the shape of the example on the Building Workflows page, cut down to one agent and one gate: ``` apiVersion: 100monkeys.ai/v1 kind: Workflow metadata: name: approved-task version: "1.0.0" description: "One agent drafts, a person approves, then the run completes." spec: initial_state: DRAFT states: DRAFT: kind: Agent agent: hello-world timeout: 600s transitions: - condition: on_success target: APPROVE - condition: on_failure target: FAILED APPROVE: kind: Human prompt: | Draft: {{DRAFT.output}} Approve? (yes/no) timeout: 86400s transitions: - condition: input_equals_yes target: DONE - condition: input_equals_no target: FAILED DONE: kind: System command: "echo 'Approved'" transitions: [] FAILED: kind: System command: "echo 'Rejected or failed'" transitions: [] ``` ### Step 6. Deploy it and start a run ``` aegis workflow deploy ./approved-task.yaml --force aegis workflow run approved-task \ --input '{"task": "Write a Python function that returns the Fibonacci sequence up to n."}' ``` The run command prints an execution id. Watch it: ``` aegis workflow logs --follow --verbose aegis workflow executions get ``` When the draft is done, `executions get` shows the current state as `APPROVE (WAITING FOR HUMAN SIGNAL)`. Nothing after the gate runs until someone answers. ### Step 7. Read the draft, then answer ``` aegis workflow signal --response yes ``` Answer `no` to send the run to `FAILED` instead. A gate that nobody answers expires after its timeout; with the default behaviour the run is marked failed with the reason `human_input_timeout`. One thing to know: the docs do not agree on the word. The Human Approvals page says a yes-or-no gate takes the responses `["yes", "no"]`; the Building Workflows page signals `--response approved`; the CLI page shows `--response "approve"`. We use `yes` because it is what the `input_equals_yes` transition is named for. If the run does not move, check `executions get` and try the other forms. ### What this does not cover - Production. Use aegis-deploy, which adds Keycloak, OpenBao, TLS through Caddy and observability. - Exposing the API. With no IAM on the `aegis init` stack, anyone who reaches port 8088 can act on it. - Hardware sizing. The docs give a dependency matrix (Docker 24.0+ or Podman 4.0+, PostgreSQL 15+, SeaweedFS, Temporal for workflows) but we did not find a minimum RAM figure for the local stack, so we do not state one. ### Next For the reasoning behind the gate, read [How to give an orchestrator an approval step](https://100monkeys.ai/blog/approval-step-for-an-agent-orchestrator). For what to record around each run, read [A traceability checklist for AI agents in production](https://100monkeys.ai/blog/ai-agent-traceability-checklist). If you want your agents' notes and code in one record they can read and write over MCP, see [Connect Claude Code to Carbon Forge over MCP](https://carbonforge.dev/guides/claude-code-mcp). [Install AEGIS from 100monkeys.ai](https://100monkeys.ai/) --- Source: https://100monkeys.ai/blog/ai-agent-traceability-checklist [Blog](https://100monkeys.ai/blog/) · Guide · 28 October 2026 ## A traceability checklist for AI agents in production: what to log, what to sign, what to show the reviewer Also in: [Español](https://100monkeys.ai/blog/es/ai-agent-traceability-checklist), [Português](https://100monkeys.ai/blog/pt/ai-agent-traceability-checklist), [日本語](https://100monkeys.ai/blog/ja/ai-agent-traceability-checklist), [Deutsch](https://100monkeys.ai/blog/de/ai-agent-traceability-checklist), [Français](https://100monkeys.ai/blog/fr/ai-agent-traceability-checklist) Disclosure: 100monkeys.ai builds AEGIS, an open-source agent orchestrator, and maintains the awesome-agent-traceability list cited below. This checklist is vendor-neutral: every item can be met with open tools, and none requires our products. It was drafted by one of our AI agents and reviewed by the company. When an AI agent acts on a real system, someone will later ask what it did and why. This checklist is the work to do before that question arrives: what to log on every run, what to sign so the log can be trusted, and what to put in front of the person who reviews it. Each item names an open standard or tool from the [awesome-agent-traceability](https://github.com/100monkeys-ai/awesome-agent-traceability) list. The frame comes from our paper [Red levers: traceable, deterministic agents in production](https://100monkeys.ai/papers/red-levers), which defines an agent system as safe in production when a person can see every decision it made, why it made it, and stop it. Logging serves the first, the recorded reason serves the second, and the review step serves the third. ### Part 1. What to log #### Step 1. Give every run an identity Assign each run an id at the start and carry it through every model call, tool call and side effect. Without it, a log is a pile of events nobody can group. Use trace and span ids from the [OpenTelemetry semantic conventions for generative AI](https://opentelemetry.io/docs/specs/semconv/gen-ai/), which define shared names for model calls, agent steps and tool invocations, so traces from different frameworks read the same way. The conventions for [agent spans](https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-agent-spans/) cover creating and invoking agents. #### Step 2. Record the request and the intent, in words Log what the agent was asked, by whom, and the reason it was given. Then, at every consequential act, log the agent's own one-line statement of why. A reason written at the moment of the act is evidence; a reason reconstructed afterwards is a story. #### Step 3. Record the model and its settings For each model call: provider, model name and version, the parameters that change output (temperature, maximum tokens, tools offered) and token counts. A behaviour you cannot tie to a model version cannot be reproduced after the provider updates it. #### Step 4. Record every tool call with its inputs and outputs Name the tool, the arguments, the result, and the time. Redact personal data before storage rather than after; [Presidio](https://github.com/data-privacy-stack/presidio) is one open option. A tool call that wrote somewhere should also record what it changed: the diff, the record id, the message id. #### Step 5. Record each policy decision If a policy engine allowed or refused a call, log the decision and the rule that made it. [Open Policy Agent](https://github.com/open-policy-agent/opa) keeps decision logs for exactly this. A refusal is as important to keep as an allow: it shows the limit held. #### Step 6. Record identity and reach Log which credential or token the run used and what that credential could reach, not its secret value. The reviewer's question is often "could it have done worse", and the answer is the scope it held. #### Step 7. Make the run replayable Store enough to re-run the work: inputs, the state at each step, and the order of events. Durable execution engines such as [Temporal](https://github.com/temporalio/temporal) keep a workflow event history that lets a workflow be replayed deterministically. ### Part 2. What to sign #### Step 8. Make the log append-only and chained A record that can be rewritten after the fact proves nothing. Write events to an append-only store and chain each entry to the one before it by hash, so a removed or edited entry breaks the chain. The IETF [SCITT](https://datatracker.ietf.org/wg/scitt/about/) working group defines signed statements registered in append-only transparency services, a ready-made shape for this. #### Step 9. Sign what the agent produced When a run produces an artifact (a build, a report, a released file), attach a signed statement of how it was made. The [in-toto Attestation Framework](https://github.com/in-toto/attestation) carries such statements, and [SLSA](https://slsa.dev/) defines levels of build provenance. For media, the [C2PA specification](https://c2pa.org/specifications/specifications/2.1/index.html) attaches signed provenance manifests, including for content produced or edited by AI. #### Step 10. Sign the approval If a person approved an act, record who approved it, when, and exactly what they saw. Bind the approval to the content: if the act changes after the approval, the approval no longer counts. ### Part 3. What to show the reviewer #### Step 11. Show the act, not a summary The reviewer should see the email, the diff or the command that will run, rendered from the run's own output. A summary written by the same model that wants approval is not a review surface. #### Step 12. Show the reason beside the act Put the agent's recorded intent next to the change it made. "Why is this line here" should be answered by the sentence written when the line landed. #### Step 13. Show the limits it ran under Show the policy and credential scope next to the run. A reviewer who sees that the agent could only write to one branch reads the run differently from one who has to assume it could reach everything. #### Step 14. Give the reviewer a stop Every review screen needs a way to refuse, and the refusal must hold. Article 14 of the EU AI Act, as quoted in Red levers, asks that people overseeing high-risk systems can "intervene in the operation of the high-risk AI system or interrupt the system". Citing it here is about the shape of the control, not a claim of compliance. ### Checking yourself Pick one run from last week and try to answer, from records alone: who asked, what the agent called, what it changed, under which policy, who approved, and whether the record could have been edited since. Each question you cannot answer maps to a step above. ### How we apply it We build tools for parts of this list. AEGIS by 100monkeys.ai, in beta, is a self-hosted orchestrator that runs agents in isolated, policy-enforced runtimes with durable state; [How to give an orchestrator an approval step](https://100monkeys.ai/blog/approval-step-for-an-agent-orchestrator) shows its approval gate as a worked example, and [this install guide](https://100monkeys.ai/blog/install-aegis-on-ubuntu-vps) gets it running on a server. [Carbon Forge](https://carbonforge.dev/?utm_source=100monkeys.ai&utm_medium=referral&utm_campaign=guides-2026-10-28) keeps code and prose in one record where blame shows the intent written at landing. [Install AEGIS from 100monkeys.ai](https://100monkeys.ai/) --- Source: https://100monkeys.ai/blog/approval-step-for-an-agent-orchestrator [Blog](https://100monkeys.ai/blog/) · Guide · 28 October 2026 ## How to give an orchestrator an approval step: a pattern, with AEGIS as the worked example Also in: [Español](https://100monkeys.ai/blog/es/approval-step-for-an-agent-orchestrator), [Português](https://100monkeys.ai/blog/pt/approval-step-for-an-agent-orchestrator), [日本語](https://100monkeys.ai/blog/ja/approval-step-for-an-agent-orchestrator), [Deutsch](https://100monkeys.ai/blog/de/approval-step-for-an-agent-orchestrator), [Français](https://100monkeys.ai/blog/fr/approval-step-for-an-agent-orchestrator) Disclosure: 100monkeys.ai builds AEGIS, the worked example in this guide, so read the AEGIS parts as a maker's account. The pattern itself is general and applies to any orchestrator. This guide was drafted by one of our AI agents from the public AEGIS documentation and reviewed by the company. An approval step is a point in an automated run where the work stops, a person reads the exact thing about to happen, and the run continues only on that person's answer. Most orchestrators can pause. Fewer make the pause hold. This is the pattern we use, step by step, with AEGIS by 100monkeys.ai, in beta, as the worked example. ### The pattern in one paragraph Put the gate after the agent has prepared the act and before the act happens. Show the reviewer the prepared thing itself, not a summary of it. Decide in advance what silence means. Route both answers explicitly. Let the reviewer answer from wherever they already are, and keep the answer in the run's history. Bound the retries so a rejected draft cannot loop forever. ### Step 1. List the acts that need a person Not every step needs a gate; a gate on everything teaches people to click through. Gate the acts that leave the sandbox and cannot be taken back: sending a message to someone outside, merging to a protected branch, spending money, deleting data, publishing. Everything else can run under a policy written in advance. Our paper [Red levers](https://100monkeys.ai/papers/red-levers) calls these the two kinds of stop: limits set before the run, enforced by the runtime, and an approval at the act, bound to one act. ### Step 2. Split the agent's work at the act An agent that drafts and sends in one step cannot be gated in the middle. Split it into a state that prepares and a state that acts, so the gate has a place to stand. In AEGIS a workflow is a declarative state machine, and the gate is a state of its own, `kind: Human`: ``` spec: initial_state: DRAFT states: DRAFT: kind: Agent agent: draft-agent transitions: - condition: on_success target: APPROVE APPROVE: kind: Human prompt: | About to send: {{DRAFT.output}} Approve? (yes/no) timeout: 86400s transitions: - condition: input_equals_yes target: SEND - condition: input_equals_no target: DISCARD ``` The shape follows the Building Workflows page of the [AEGIS docs](https://docs.100monkeys.ai/docs/workflows/human-approvals); `draft-agent`, `SEND` and `DISCARD` stand for your own agent and states. ### Step 3. Put the exact thing in front of the reviewer The prompt is the reviewer's whole view, so render the prepared output into it. AEGIS prompts take Blackboard templates: `{{DRAFT.output}}` above is the earlier state's output, and the docs show scores from earlier states as well, such as `{{QUALITY_CHECK.output.score}}`. A reviewer who is shown "the agent wants to send an email" is approving a description; a reviewer shown the email is approving the email. ### Step 4. Decide what silence means Every gate needs a timeout and a rule for when it passes. On the Human Approvals page, `timeout_seconds` defaults to 3600. With `reject_on_timeout: false`, the default, an unanswered gate fails the run with `human_input_timeout`. With `reject_on_timeout: true`, silence is treated as a no and the run takes the rejected route. Pick the second when a missing answer should be a clean no rather than an error. Never make silence a yes. A note on fields: the Human Approvals page uses `timeout_seconds` and the conditions `approved` and `rejected`; the Building Workflows page uses `timeout` and `input_equals_yes` and `input_equals_no`. Use one form consistently, and check the Workflow Manifest Reference for the version you run. ### Step 5. Route both answers, and bound the loop A no is an answer, not a failure to handle later. Give it a target state: discard, or send the draft back to the agent with the reviewer's feedback. If you route a rejection back to the drafting state, the run now has a loop. AEGIS bounds it: `max_state_visits` per state (default 5, ceiling 20) and `max_total_transitions` per run (default 50, ceiling 100). Set them to the number of tries a reviewer will tolerate. ### Step 6. Let the reviewer answer from where they are A gate nobody sees is a timeout. In AEGIS the same gate can be answered three ways: - From the command line: `aegis workflow signal --response yes`. - From your own client: list waiting gates with `GET /v1/workflow-gates?status=pending` and answer one with `POST /v1/workflows/executions/{id}/signal`, with a body such as `{ "response": "yes", "feedback": "Keep the flag name short." }`. - In Zaru Web: a gate of a run you started appears as one of your pending approvals, with one button per allowed word. The docs add that Zaru's companion is offered no tool that answers a gate, in any mode, so the model that prepared the act cannot approve it. That last property is the one to look for in any orchestrator: the agent must not hold the key to its own gate. ### Step 7. Keep the answer An approval is evidence. After a gate is answered or times out, AEGIS keeps it listed: `?status=answered` returns each gate with the word chosen, the feedback, when it closed and what the run did then. Record who answered too; the approve endpoint on the Human Approvals page takes an `approved_by` field, and a rejection requires a `reason`. ### Step 8. Test the gate before you trust it Run the workflow three times: answer yes, answer no, and let it time out. Confirm each route lands where you meant, and that nothing after the gate ran before the answer. Then change the draft after the gate is posted and confirm the reviewer sees what will actually run. If your orchestrator binds the approval to a description instead of the content, this is where you find out. ### Where to go next To try the pattern end to end on a server of your own, follow [Install AEGIS on a fresh Ubuntu VPS and run your first approved task](https://100monkeys.ai/blog/install-aegis-on-ubuntu-vps). For what to log and sign around each gate, read [A traceability checklist for AI agents in production](https://100monkeys.ai/blog/ai-agent-traceability-checklist). For the same approval idea in a personal assistant, see [Set up a Zaru assistant that handles your email and calendar with approvals](https://myzaru.com/guides/email-and-calendar-with-approvals?utm_source=100monkeys.ai&utm_medium=referral&utm_campaign=guides-2026-10-28). [Install AEGIS from 100monkeys.ai](https://100monkeys.ai/) --- Source: https://100monkeys.ai/blog/blame-that-remembers-why [Blog](https://100monkeys.ai/blog/) · 28 October 2026 ## Blame that remembers why: what a change should carry when the author was an agent *This essay was written by an AI agent of 100monkeys.ai and reviewed for publication by the company. We build Carbon Forge, the source control it describes in its last section, so read that part as a maker's account.* Every engineer has run blame on a line that made no sense and found a name, a date and a commit message that said "fix". The name was a colleague. You walked over, or you sent a message, and the colleague remembered, or remembered enough. Blame was never really a record of why. It was a pointer to a person who held the why in their head. That arrangement quietly assumes the author is still around and still remembers. When the author is an agent, both assumptions fail. The session that wrote the line is gone. Its context window was discarded an hour after it landed the change. There is nobody to walk over to. If the reason was not written down at the moment of the change, it does not exist anywhere. So the question is worth asking directly: when the author of a change is an agent, what should the change carry? ### The reason, in the author's own words, at the moment of writing The first thing is the intent: one sentence the author wrote, before landing, saying what the change is for. Not a summary generated later from the diff. A diff can tell you what changed; only the author can tell you what it was meant to do, and the only time that sentence is cheap to get is the moment the author is about to land. Humans write poor commit messages because the cost of a good one falls on the writer and the benefit falls on a stranger months later. Agents do not have that excuse. Asking an agent for one honest sentence of intent costs nothing, and a system that requires it on every landing gets it every time. The interesting design question is not whether to ask, but where the answer lives, and whether it survives. ### The whole change, or none of it The second thing is completeness. An agent asked to rename a configuration key will touch the code that reads it, the default file that sets it and the page that documents it. If those land as three separate events, there is a window in which the code and the documentation disagree, and if one of the three fails, the window never closes. A change made by an agent should land as a unit: the code and the prose that explains it, written together or not at all. The reason this matters more for agents than for people is volume. A person makes a handful of these changes a day and notices a half-landed one. A fleet of agents makes many, and nobody is watching each one land. ### No silent merges The third thing is honesty about conflict. When two authors change the same thing, a system can either guess at a combined result or stop and say so. Text merging that guesses well most of the time is a reasonable trade for people, who read the result. It is a poor trade for agents, because the guess is made by neither author, and the record then holds a line that nobody intended. A conflict should come back named, with enough context for the caller to decide, and the decision should be bound to the state the caller actually saw. If the ground moved again before the decision landed, the decision should be made again. That is slower in the rare case and much easier to audit in every case. ### A history that cannot be rewritten The fourth thing is permanence. The point of carrying the reason is to be able to read it later, and that only works if later readers can trust that the record they read is the record that was written. History that only grows, where an undo is a new change rather than an erasure, gives an auditor something to stand on. A release that names one fixed state of everything, and keeps naming it, gives the same guarantee for "what shipped". ### Approval bound to exactly what was approved The fifth thing is the human signature. When a person approves an agent's work, the approval should attach to the exact state they looked at. If the agent patches anything afterwards, the approval should stop counting. Anything looser turns review into a ritual: someone said yes to a version that no longer exists. ### How we built Carbon Forge around those five We build Carbon Forge at 100monkeys.ai, and the five properties above are the ones we designed it to hold. Each sentence below is what the product's public docs state. Carbon Forge keeps code, files and prose in one record on the server, and people and agents read and write it through the same tools. An agent does not clone. It opens a lane, which is a set of patches over the trunk, and every read on the lane composes the trunk as it stands now with those patches. A landing is one changeset: every page, code tree and file it names is written in one transaction, or nothing is. A code change and the page that documents it land in the same changeset, together or not at all. Carbon Forge never merges text by itself. A patch that no longer applies is reported as a named conflict, and the caller answers it against the trunk it saw. Every revision and every changeset is hash-chained, and a revert is a new landing, so history only moves forward. A cut names one sealed snapshot of the workspace and never moves, so a release has one answer for as long as the workspace exists. On a protected trunk, a landing-rules page names the approvers each path needs, and an approval binds to the lane's exact state, so a later patch voids it. And the property this essay started with: blame, grep, diff and history run on the server, and blame shows next to each line the intent the agent wrote when it landed it. Ask why a line is there, and the answer is the author's own sentence, written at the moment it mattered. Two more things a skeptical reader will want to know. Git is a projection: every code tree renders to a git history and pushes to GitHub fast-forward only, so existing git tooling keeps working. And agents reach Carbon Forge over MCP with the same tools the editor uses, with tokens that can be held to a preset such as SCM reader, which writes nothing. ### What we would like to hear If you run more than one agent against the same codebase, the useful question is not which tool you use but what your record can answer a month from now. Pick a line an agent wrote last month and ask your system why it is there. If the answer is a name and "fix", the reason has already been lost. *Disclosure: 100monkeys.ai builds Carbon Forge, the record people and agents share, alongside AEGIS by 100monkeys.ai, an open-source agent orchestrator in beta, and Zaru, a companion that shows its work. This essay was drafted by one of our agents. Public Carbon Forge workspaces are free and every account includes one free private workspace. The source-control design is described in full here: [https://carbonforge.dev/docs/p/features/source-control-on-the-substrate?utm_source=100monkeys.ai&utm_medium=article&utm_campaign=push-2026-10-28](https://carbonforge.dev/docs/p/features/source-control-on-the-substrate?utm_source=100monkeys.ai&utm_medium=article&utm_campaign=push-2026-10-28)* --- Source: https://100monkeys.ai/blog/the-approval-is-the-product [Blog](https://100monkeys.ai/blog/) · 28 October 2026 ## The approval is the product: why an agent orchestrator should make you say yes First published on [Medium](https://medium.com/@jeshua_46811/the-approval-is-the-product-why-an-agent-orchestrator-should-make-you-say-yes-1f1b2d71af61); this copy points search engines to it. *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/](https://100monkeys.ai/)*