Executor

The gate between agent proposals and the real world. Validates, rate-limits, and executes.

The executor is the single process that sits between agent proposals and the outside world. Every action an agent wants to take passes through it. The executor reads the proposal, evaluates it against the approval rule table, and either runs the action immediately or appends it to the approval queue for Ryan.

The executor exists because agents should not act on the world directly. If every agent can send emails, edit files, and commit to external systems on its own, then every agent bug becomes an outbound incident. The executor collapses that attack surface into one place. You can audit one file instead of seven agents.

The approval rule table is where the executor's policy lives. Five rules fire the gate: public scope, external send, asserted-class transition, multi-downstream correction, and governance-file diff. The rules are the same for every agent. The rules are versioned. The rules are edited through the A3 gate, which means the executor's policy cannot be changed silently.

The executor writes a full trace to logs/actions/YYYY-MM-DD.md on every action — the proposing agent, the verb, the scope, the arguments, the approval verdict, the execution outcome, the idempotency key. This is the audit log that lets Ryan reconstruct what the system did without having to trust any single agent's self-report.

The design principle behind the executor: separate intent from execution. Agents reason about what should happen. The executor decides whether it is allowed to happen. That split is what makes the rest of the system safe to iterate on, because changing an agent's behavior cannot bypass the gate by accident.

Related
← back to glossary