Here is a code for the first month of Carbon Forge, free: CARBONFORGE100. 💯

It is limited in two ways. It stops after 100 uses, and it stops on 12 November, whichever comes first. Checkout asks for a card, and the first month is not charged.

Carbon Forge is source control for agents and people working in the same workspace. 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. When you want to know why a line is there, blame shows the intent the agent wrote when it landed it.

You do not need the code to start. Every account includes one free private workspace, and public workspaces are free. The code covers the first month of a plan that adds more.

https://carbonforge.dev/pricing?utm_source=hashnode&utm_medium=social&utm_campaign=fomo-code-2026-10-29

Zaru handles your email, calendar and web research. You watch each step as it happens, and by default nothing gets sent until you say yes. This guide sets it up for the two jobs where that yes matters most: your inbox and your calendar.

Why approvals, for email and calendar

An assistant that drafts is useful. An assistant that sends without asking is a risk, because a sent email and a moved meeting cannot be taken back. Zaru is built around the line between the two: in the site's words, "Anything that sends a message or changes your calendar waits for your yes." Reading, sorting and drafting happen on their own; the send waits for you.

Step 1. Create a free account

Press Get Zaru free on myzaru.com. It opens the sign-in page, where you can sign in with Google or register with an email address. The Register form asks for your email and, optionally, your first and last name. The site puts it simply: "Free plan. No card. Just your name and email." Zaru is in beta, and anyone who registers gets the Free plan right away. The Free plan costs nothing and has no time limit; the plans page lists what the paid plans add.

What follows the Register button, such as a confirmation email or the first screen, is not described on this site, so we do not describe it here.

Step 2. Tell Zaru who you are

Zaru saves what matters about you as you talk: how you write, what you care about, what you keep explaining. You do not have to wait for it to learn. Open Settings > Memory and write a few lines yourself, for example:

• How you sign emails, and how formal you are with clients versus friends.
• Which senders always matter, and which newsletters never do.
• Your working hours, and the times you do not take meetings.

You can return to Settings > Memory at any time "to read every word of it, change it, or start over." Check it after the first week; it is where a wrong assumption about you would show.

Step 3. Connect your email and calendar

Connect your email account and your calendar from inside the app. Once connected, Zaru "reads, drafts and plans in them." This site does not name the settings screen or list which providers are supported, so follow the app's own prompts for the connection.

Step 4. Give it a first inbox task, and watch

Start small and specific. In the chat, ask something like:

Go through today's unread email. Tell me which three need a reply from me, and draft a reply to each.

As Zaru works, "each step appears in the chat as Zaru takes it, in plain words": which messages it read, what it decided, what it drafted. This is the point of watching the first run closely. If it misread a sender's importance, correct it in the chat or in Settings > Memory, and the next run starts from the correction.

Step 5. Approve, edit or decline the send

When a draft is ready to go, Zaru stops and asks. Nothing is sent until you say yes. Read the draft as it will be sent. If it is right, approve it. If it needs a change, say what to change and let Zaru redraft, then read the new version before you approve it. If it should not go at all, decline.

Approve one message at a time while you are getting to know it. The approval is only worth something if you read what you are approving.

Step 6. Do the same with your calendar

Zaru plans in your calendar as well as your inbox. Try:

Find a 30-minute slot with Sam next week that avoids my mornings, and propose it.

You watch each step in the chat as it goes. Creating or moving the event is a change to your calendar, so it waits for your yes, the same as an email.

Step 7. Put a daily job on a schedule

Once a task works well by hand, schedule it. Zaru runs scheduled workflows, for example a morning pass over the inbox on weekdays. A scheduled run "runs as you, and anything it would send still asks for your yes, just as in the chat." You come back to drafts waiting for approval, not to messages already sent.

Step 8. Optional: reach the same Zaru from your editor

If you work in Claude Code, Cursor or another MCP client, "Connect Zaru's MCP server to Claude Code, Cursor or any MCP client, type zaru init, and you are talking to the same companion, with the same memory, from your editor."

A note on "by default"

Approval before sending is how Zaru behaves by default, and it is the setting this guide assumes. Before you rely on it, send yourself a test: ask Zaru to email you, and confirm it stops and asks before the message leaves.

What is open, and what is not

The Zaru harness, zaru-cli, is open source under Apache-2.0, and the AEGIS Orchestrator underneath it is open source under AGPL-3.0. The web app at ask.myzaru.com is not open source.

Related guides

• How to give an orchestrator an approval step, the same idea for teams running their own agents (100monkeys.ai)
• Connect Claude Code to Carbon Forge over MCP, shared memory for coding agents (carbonforge.dev)
• Zaru FAQ

Get Zaru free

Originally published at https://myzaru.com/guides/email-and-calendar-with-approvals . Zaru: https://myzaru.com/?utm_source=hashnode&utm_medium=article&utm_campaign=push-2026-10-28

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 <AGENT>, 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": "<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 <EXECUTION_ID>, 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: <the last refusal>.'" 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 <name>".

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. To read what a run did, read Reading an AEGIS execution log.

Install AEGIS from 100monkeys.ai

Originally published at https://100monkeys.ai/blog/run-a-scheduled-agent-with-aegis

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 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; 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 <execution-id> --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. For what to log and sign around each gate, read A traceability checklist for AI agents in production. For the same approval idea in a personal assistant, see Set up a Zaru assistant that handles your email and calendar with approvals.

Install AEGIS from 100monkeys.ai

Originally published at https://100monkeys.ai/blog/approval-step-for-an-agent-orchestrator

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. This guide attaches Claude Code to that record over MCP.

Why connect them

A coding agent forgets between sessions unless its notes live somewhere it can read again. Carbon Forge is that somewhere, shared with the people on the project. The docs call MCP "a primary product surface, co-equal with the human editor, against the same atoms, pages, links, and embeddings" (A shared cortex for LLMs). An agent's page is a page a person can open, correct and link to.

Step 1. Try the read-only endpoint with no token

Before you sign up, attach to public content. From Reading a public cortex without an account: "Add the instance's MCP endpoint to your client with no Authorization header. For this instance that is https://carbonforge.dev/api/mcp over Streamable HTTP. With Claude Code:"

claude mcp add --transport http cortex-public https://carbonforge.dev/api/mcp

You get twenty-two read-only tools, rate-limited per IP address. Ask Claude Code to read the page home in the workspace docs; with no token there is no current workspace, so every call names workspace. Remove this entry with claude mcp remove cortex-public before adding the authenticated one, so the agent is not reading two surfaces.

Step 2. Sign in and pick the workspace

Sign in at carbonforge.dev/login with an email link or the 100monkeys button; there are no passwords. Public workspaces are free, and every account includes one free private workspace (pricing). Decide which workspace the agent will use as its memory. A private one keeps the notes to members.

Step 3. Mint a token with the narrowest scope that fits

From MCP tokens: open settings and pick API tokens; choose the workspace and a role cap (viewer, editor or admin); pick a tool-scope; name the token after the agent; copy the secret, which "is shown once, then only the prefix."

For shared memory, Basic LLM memory lets the agent "read and write pages, atoms and tags, and run search, with basic graph reads", which the docs call "the minimum for an LLM that uses Carbon Forge as its memory." For an agent that only recalls, Read-only memory writes nothing. For code work, SCM agent adds lanes, trees and landing (MCP token scopes). A tool outside the scope "answers exactly as a tool that does not exist."

Step 4. Add the server to Claude Code with the token

The docs say to point the client at the endpoint "with the token in the Authorization header". Claude Code sets headers with --header:

claude mcp add --transport http carbon-forge https://carbonforge.dev/api/mcp \
  --header "Authorization: Bearer ‹your token›"

If you put the token in an environment variable and write $CARBON_FORGE_TOKEN instead, your shell expands it before Claude Code sees it, so the secret is still stored in Claude Code's configuration. Treat that configuration as a secret either way, and keep the server in the default local scope or user scope rather than a file you commit.

Step 5. Let the agent ground itself

Start a session and ask Claude Code to call cortex.ground. The docs make it the first call: it "Returns the per-instance README, the calling identity, what the bearer can do, what is reachable, and helper-service health" (cortex.ground). The raw call is:

{ "jsonrpc": "2.0", "id": 1,
  "method": "tools/call",
  "params": { "name": "cortex.ground" } }

The server also delivers the same payload on the initialize handshake and on the first tool call of a session, so an agent that skips this step is still oriented. Read the capabilities block to confirm the token can write.

Step 6. Write memory, then cite it

Ask the agent to record what it learned as a page, for example a decision and its reason, and to read that page at the start of the next session. Two properties make this memory rather than a cache. Every save writes a revision and nothing rewrites one, so you can read what the agent wrote last week. And "every entity-returning tool decorates the result with a clickable permalink so an LLM can hand a working URL back to its human" (How MCP works): ask the agent to cite the permalink of every page it relied on, and check them.

For code, the same record holds it. An agent opens a lane instead of cloning, and a landing is one changeset, written in one transaction or not at all (Working in lanes).

Step 7. Watch the audit log and revoke when done

"Every tool call lands in the audit log under the token identity." When the agent no longer needs access, or the token leaks, revoke it from settings; "in-flight calls fail on the next request" (MCP tokens).

What the docs leave unanswered

• The endpoint for an instance on its own host. The anonymous-access page names https://carbonforge.dev/api/mcp "for this instance"; it does not say which URL to use for an instance at its own subdomain or a vanity domain.
• Two paths. The same page uses /api/mcp; the curl example on How MCP works posts to /mcp. We use /api/mcp.
• Token lifetime. The docs describe revoking a token but do not state whether a token expires on its own.
• Client-specific configuration. The docs give no Claude Code command; the one above is Claude Code's documented syntax for a header.

Related guides

• Connect Cursor, Codex and any MCP client to one Carbon Forge workspace
• A traceability checklist for AI agents in production (100monkeys.ai)
• Install AEGIS on a fresh Ubuntu VPS and run your first approved task (100monkeys.ai)

Give Claude Code a record it can cite.

Start free · Read the docs

Originally published at https://carbonforge.dev/guides/claude-code-mcp . Carbon Forge: https://carbonforge.dev/?utm_source=hashnode&utm_medium=article&utm_campaign=guides-2026-10-28

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 list.

The frame comes from our paper Red levers: traceable, deterministic agents in production, 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, 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 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 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 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 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 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 carries such statements, and SLSA defines levels of build provenance. For media, the C2PA specification 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 shows its approval gate as a worked example, and this install guide gets it running on a server. Carbon Forge keeps code and prose in one record where blame shows the intent written at landing.

Install AEGIS from 100monkeys.ai

Originally published at https://100monkeys.ai/blog/ai-agent-traceability-checklist

La presentación habitual de una plataforma de agentes trata de lo que el agente puede hacer sin ti. Puede abrir el pull request, responder el ticket, enviar el seguimiento, trabajar toda la noche. Cuanto menos tengas que tocarlo, mejor se supone que es.

Creemos que esa presentación tiene el valor al revés. La propiedad útil de un sistema de agentes no es lo poco que te necesita. Es la precisión con la que te deja decidir qué puede hacer, y la fiabilidad con la que se detiene en la línea que trazaste. La aprobación no es una fricción alrededor del producto. Para cualquier cosa que actúe en el mundo en tu nombre, la aprobación es el producto.

Dos tipos de sí

Hay dos momentos en los que una persona puede decirle que sí a un agente.

El primero es por adelantado. Antes de que el agente se ejecute, alguien deja por escrito qué puede tocar: qué herramientas, qué redes, qué archivos, qué secretos. Todo lo demás queda denegado. Es un sí que se da una vez, en una forma que una máquina puede hacer cumplir y que una persona puede leer después.

El segundo llega en el momento del acto. El agente ha preparado algo con consecuencias, un correo a un desconocido, un pago, un borrado, y se detiene a esperar. Una persona lee exactamente lo que está a punto de ocurrir y dice sí o no a ese único acto.

La mayoría de los sistemas ofrecen una versión débil de uno y se saltan el otro. Existe una lista de permisos, pero por defecto está abierta. Existe una confirmación, pero aparece tan a menudo que la gente la acepta sin leer, o aparece después del acto, como aviso de lo que ya ocurrió. Ninguna de las dos es un sí en un sentido que importe.

Por qué el primer sí pertenece al entorno de ejecución

Una regla escrita en un prompt es una petición. El modelo puede seguirla. Bajo presión, ante una entrada ingeniosa o simplemente en una tarea lo bastante larga, puede no hacerlo, y nada fuera del modelo se da cuenta.

Una regla escrita en el entorno de ejecución es un muro. Si la política dice que el agente no puede llegar a un host, la llamada de red falla decida lo que decida el modelo. Si al agente nunca se le entrega la credencial, ningún prompt puede hacer que la filtre. Es la diferencia entre límites por promesa y límites por arquitectura, y es la razón por la que el primer sí debe vivir en un orquestador, no en un modelo.

También es la razón por la que el valor por defecto importa más que cualquier regla concreta. Una política que deniega por defecto significa que la ausencia de un sí es un no. Una política que permite por defecto significa que cada hueco en la política es un permiso que nadie concedió. Los agentes encuentran los huecos rápido, no por malicia, sino porque prueban cosas.

Por qué autoalojado

Si el entorno de ejecución guarda el primer sí, quien opera ese entorno también lo guarda. Para un proyecto personal quizá no importe. Para un agente que toca tu código fuente, tus clientes o tu infraestructura, quien decide qué puede hacer el agente debería ser alguien de tu organización, en máquinas que controlas, leyendo una política que puedes auditar. Aquí el autoalojamiento no es una preferencia de despliegue. Es donde reside la autoridad.

Por qué el segundo sí tiene que ser exacto

El segundo sí falla de una forma más silenciosa. Si la aprobación se ata a una descripción del acto y no al acto mismo, el agente puede cambiar el acto después del sí. Si la aprobación es un permiso general ("puedes enviar correos"), vuelve a ser el primer sí, dado sin cuidado.

Una aprobación útil en el momento del acto muestra exactamente la cosa, se ata a esa cosa exacta y caduca si la cosa cambia. Un mensaje, leído y aprobado. Después, el siguiente.

Duradero, para que un sí no se pierda

Debajo de los dos tipos de sí hay un requisito práctico: el estado del trabajo tiene que sobrevivir. Un agente que espera una hora a que una persona apruebe algo no puede perder su sitio cuando un proceso se reinicia. Si lo pierde, el sistema o bien abandona el trabajo, lo que enseña a la gente a evitar las aprobaciones, o bien lo reintenta desde el principio, lo que puede repetir actos ya hechos. Esperar a una persona solo es seguro si la espera es duradera.

Lo que construimos para cada sí

En 100monkeys.ai construimos los dos lados, y cada frase de esta sección es lo que dicen nuestras páginas públicas o nuestro propio uso medido.

AEGIS by 100monkeys.ai, en beta, guarda el primer sí. Con las palabras de su página de inicio, traducidas del inglés: "AEGIS es un orquestador autoalojado que ejecuta agentes autónomos en entornos aislados y sujetos a políticas, con estado FSM duradero." Su política de seguridad es declarativa y deniega por defecto. Las ejecuciones de agentes se aíslan a nivel de kernel, en micro-VMs o en contenedores sin root. Los secretos los guarda un keymaster, así que los agentes nunca ven las credenciales que usan. Las llamadas a herramientas pasan por SEAL, un protocolo criptográfico de llamadas a herramientas. Los flujos de trabajo son duraderos, así que el estado sobrevive a un fallo o a un reinicio. Es código abierto bajo AGPL-3.0 y se instala con una línea copiada de su página de inicio:

curl -fsSL https://get.100monkeys.ai | bash

Zaru guarda el segundo sí. Es una IA personal que trabaja a tu lado, te recuerda y muestra su trabajo, y lo que recuerda de ti es tuyo para leerlo y editarlo. Así se ve en nuestro propio uso: cuando la herramienta de correo de Zaru envía un email por nuestro fundador, por defecto el envío no ocurre. Responde que la aprobación está pendiente y espera en la aplicación web de Zaru, en Approvals, hasta que él aprueba ese mensaje concreto. Zaru lo vende My Zaru, Inc. en myzaru.com.

Ninguno de los dos hace seguro a un agente por sí solo. Lo que hacen es mantener a una persona en posición de decidir, antes de la ejecución y en el momento del acto, y esa es la parte que la mayoría de las herramientas de agentes deja fuera.

Lo que nos gustaría escuchar

Si ejecutas agentes que actúan fuera de un sandbox, nos gustaría saber dónde vive hoy tu sí: en un prompt, en una política o en la bandeja de entrada de alguien cuando ya es tarde. Y si has construido un paso de aprobación que la gente no acepta sin leer, nos gustaría aprender cómo.

Divulgación: 100monkeys.ai construye AEGIS by 100monkeys.ai, un orquestador de agentes de código abierto en beta; Zaru, un compañero que pregunta antes de actuar; y Carbon Forge, el registro que comparten personas y agentes. Este ensayo lo redactó y lo tradujo uno de nuestros agentes; el original en inglés está publicado en Medium. AEGIS, su documentación y la línea de instalación están aquí: https://100monkeys.ai/?utm_source=hashnode-es&utm_medium=article&utm_campaign=push-2026-10-28

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/?utm_source=hashnode&utm_medium=article&utm_campaign=push-2026-10-28

A single engineer in a git repository has a loop that fits: clone, branch, commit locally, push, open a pull request, merge. Put ten coding agents in the same repository at the same time and every step of that loop starts to cost something.

Each agent needs a working copy before it can read a line. Each branch starts going stale the moment it is cut, because nine other agents are landing work on main while it runs. Merges are computed by a tool that knows the text on both sides and nothing about what either side meant. And weeks later, when someone asks why a line exists, the answer in the log is whatever the agent typed into a commit message at the end of a long run, which is often "update file".

The scale version of the problem

Anthropic's write-up on Scion, published October 13, 2026, describes merges to its monorepo going from about 2,500 a day in May to over 30,000 a day in September. The article sets out three principles for the system they built in response:

• Clients are always online.
• Commits must be cheap, incremental, and lock-free.
• The working copy is optional, and sparse by design.

Most teams will never see 30,000 merges a day, but the shape of the problem arrives the first afternoon you let three agents work on the same service in parallel and spend the evening untangling what they did to each other.

Carbon Forge was built to the three principles that article lists, and it differs where its docs say so: it serves many workspaces rather than one monorepo, and it takes a row lock per entity it writes. The rest of this article walks through the mechanisms that matter when several agents share one codebase. We have no affiliation with Anthropic; their article is the clearest statement of the problem we have read.

One record, on the server

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.

There is no local repository to keep in sync, so there is no "my copy is behind" state for an agent to get into. Agents reach the record over MCP with the same tools the editor uses, so an agent is not a second-class client talking to a side API.

Blame, grep, diff and history run on the server, so an agent that needs to know where a function is called asks the question instead of first pulling down a copy of the repository.

Lanes instead of branches

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.

The useful word there is now. A git branch is a snapshot of main at the moment it was cut, plus your commits. The longer an agent works, the further that snapshot drifts from reality, and the bigger the merge at the end. A lane has no snapshot to drift. When another agent lands work on the trunk, your next read on your lane already sees it, with your patches applied on top.

So the question "does my change still apply?" is asked continuously, on every read, rather than once at the end when the answer is most expensive.

No automatic merge, on purpose

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.

A textual three-way merge is a guess: it is usually right, and when it is wrong it is silently wrong, producing code that compiles and does the wrong thing. A person reviewing a pull request might catch that. An agent landing its fortieth change of the afternoon will not.

When a patch stops applying, Carbon Forge does not guess. It names the conflict and hands it back to the caller, which is the one party that knows what the patch was for. The resolution is made against the trunk as the caller saw it, so it is a decision about real code rather than about a merge base from an hour ago.

Changesets: all of it or none of it

A landing is one changeset: every page, atom, code tree and file it names is written in one transaction, or nothing is.

An agent can time out, lose its connection or be stopped halfway through a change that touches six files. In a system where each file write stands alone, that leaves the codebase in a state nobody intended. With a changeset, the half-finished change does not exist: either the whole landing is on the trunk or none of it is.

The same transaction covers prose. A code change and the page that documents it land in the same changeset, together or not at all. The page that explains a function can move in the same landing as the function.

Blame that answers "why"

Every landing is sealed with an intent: the sentence the agent wrote, at the moment it landed the change, saying what the change is for. Blame shows next to each line the intent the agent wrote when it landed it.

When a reviewer, human or agent, asks why a line is there, the answer is not reconstructed from a diff and a guess. It is the sentence written by the author at the moment of the change, attached to the line.

History is kept the same way. 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.

Review and permissions for agents

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. When the author is an agent that can add a patch at any moment, an approval that survived later patches would not mean much.

Agents also do not all need the same reach. A token can be held to a preset such as SCM reader, which writes nothing. An agent whose job is to read code and report gets a token that cannot change anything.

Git keeps working

None of this asks a team to give up its git tooling. Git is a projection: every code tree renders to a git history and pushes to GitHub fast-forward only, so git tooling keeps working.

The orchestrator: AEGIS

Where code lives is half of running agents in parallel; running the agents is the other half. Our open-source project for that is AEGIS by 100monkeys.ai, in beta. 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." It is open source under AGPL-3.0. The site gives a one-line install, curl -fsSL https://get.100monkeys.ai | bash, and the details are at 100monkeys.ai.

The companion: Your Zaru

The third thing we build is for the person rather than the codebase. Your Zaru is a personal AI companion that works alongside you, remembers you and shows its work: it handles messages, planning, follow-ups and scheduling, and keeps a memory of you that you can read and edit. It runs on AEGIS, it has a free plan, and it is sold by My Zaru, Inc. at myzaru.com.

Trying Carbon Forge

Public workspaces are free, and every account includes one free private workspace; the plans beyond that are on the pricing page at carbonforge.dev/pricing. The engineering docs are public, starting at carbonforge.dev/docs, including the full source-control design.

We would like to hear from anyone running more than one agent against the same codebase: what broke first, and what you did about it. You can sign up at carbonforge.dev.