100monkeys.ai

Blog · Guide · 28 October 2026

How to give an orchestrator an approval step: a pattern, with AEGIS as the worked example

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 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:

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