AEGIS Orchestrator
AEGIS by 100monkeys.ai 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 and in beta.
curl -fsSL https://get.100monkeys.ai | bash
Website · Documentation · Discussions
AEGIS is built for teams that want automation to be useful in production, not just impressive in a demo. If you are a DevOps engineer, SRE, or developer trying to run agents with predictable behavior, strong isolation, and operational visibility, this repository is the place to start.
Why AEGIS
An agent's autonomy should be bounded by the infrastructure it runs on, not by its prompt, so AEGIS enforces limits the agent cannot argue its way past. Security policy is declarative and deny-by-default, agent runs are isolated with Docker for local development and Firecracker micro-VMs as the production direction, and secrets are held by a keymaster so agents never see the credentials they use. Workflows are durable, so their state survives a crash or a restart.
- Deterministic control: explicit workflows, typed manifests, and orchestrator-managed execution reduce hidden behavior and ad hoc agent sprawl.
- Built-in security controls: network and filesystem access are policy-governed, runtimes are isolated, and production deployments can layer IAM and SEAL gateway controls on top of the orchestrator boundary.
- Reliable operator workflows: the CLI provides repeatable stack bring-up, status, update, and shutdown paths with health checks and machine-readable output.
- Auditable automation: structured logs, machine-readable CLI output, and orchestrator-mediated dispatch make agent activity easier to inspect and automate around.
- Clear path to production: Docker supports local development, while Firecracker-backed isolation is the intended production direction.
What AEGIS Is
AEGIS Orchestrator is the layer that manages agent lifecycle, workflow execution, runtime isolation, security enforcement, and the operator experience around all of it. It gives you a controlled environment for running autonomous systems while preserving the things infrastructure teams care about most: predictable change, traceability, and blast-radius containment.
Quick Start
1. Install the CLI
curl -fsSL https://get.100monkeys.ai | bash
That installer installs the aegis CLI from a pinned GitHub release, installs local prerequisites such as Docker when needed, and then runs aegis up --tag <pinned-version> to bring the local stack online. Re-running it is intended to be idempotent.
If you prefer to install the CLI from source yourself instead of using the installer:
cargo install aegis-orchestrator
2. If you installed the CLI manually, initialize a local AEGIS stack
aegis init
aegis init is the guided first-run path when you are not using the one-shot installer. It prepares stack files, configures the node, starts Docker Compose services, verifies health, and syncs built-in agents and workflows.
3. Check health
aegis status
4. Deploy an agent
aegis agent deploy <manifest.yaml>
See the Agent Manifest Reference for the schema and the Deploying Agents guide for examples.
5. Execute a task
aegis task execute hello-world --input "Write a Python function that sums 2 numbers together and outputs the result."
6. Stop the stack when you are done
aegis down
What You Just Started
A local AEGIS setup gives you an orchestrator API, a gRPC surface, and supporting services needed for workflows and agent execution. The generated local stack typically exposes:
- Orchestrator API:
http://localhost:8088
- gRPC:
localhost:50051
- Prometheus metrics:
http://localhost:9091/metrics (bound to 127.0.0.1 by default; deployments must set METRICS_BIND=0.0.0.0 for cross-pod scraping)
- Temporal UI:
http://localhost:8233
This is enough to start understanding the operator model: the orchestrator owns lifecycle, policy enforcement, and execution visibility, while agents run inside controlled runtimes. Local defaults are tuned for development bring-up rather than full production hardening.
Core Concepts
Deterministic execution
AEGIS is designed to make automation easier to reason about. Workflows are explicit, configuration is typed, and execution flows through the orchestrator rather than through a loose collection of direct agent integrations. That structure gives operators a more reproducible orchestration layer and gives developers a clearer contract for how work is scheduled, executed, and observed.
Security and isolation
AEGIS centers security controls in the orchestrator. Network and filesystem policy are defined in manifests, development runs use Docker-backed isolation, and the production architecture is aimed at Firecracker micro-VM isolation. At the protocol layer, SEAL verifies tool calls end to end, and orchestrator-mediated dispatch keeps agent actions behind a control boundary. Local stack templates prioritize fast setup, so IAM and SEAL gateway auth are not enabled in every local dev path by default.
Reliability and auditability
The CLI supports repeatable bring-up and shutdown flows such as aegis init, aegis up, aegis status, and aegis down. Structured logging via tracing, health checks, and machine-readable --output <text|table|json|yaml> modes make AEGIS friendlier to both human operators and automation pipelines, while explicit stack commands reduce drift in routine local operations.
Building blocks
- Agents: stateless units of autonomous work defined by manifests.
- Executions: individual agent runs with a managed lifecycle.
- Workflows: explicit orchestration across states and agents.
- Swarms: multi-agent coordination with bounded control.
- Security policies: the permissions and runtime constraints that keep execution contained.
Common Commands
# Start the stack if it has already been initialized
aegis up
# Show current stack health
aegis status
# Generate a node config file
aegis config generate --out ./aegis-config.yaml
# List agents in a machine-readable format
aegis --output json agent list
# Start the daemon with verbose logs
RUST_LOG=debug aegis daemon start
Interactive and streaming workflows remain text-first. For the current command surface, flags, and behavior, use the CLI Reference.
Learn More
Start here if you are new:
Use these when you are ready to configure and build:
Development
Git hooks
A pre-push hook lives in .githooks/pre-push. Activate it once after cloning:
git config core.hooksPath .githooks
Every git push will then run:
cargo fmt --all && \
cargo clippy --workspace --locked -- -D warnings && \
cargo build --release && \
cargo test --workspace --locked && \
cargo doc --no-deps
The push is blocked if any step fails.
Building from source
If you want to work from source instead of the install script:
git clone https://github.com/100monkeys-ai/aegis-orchestrator
cd aegis-orchestrator
cargo build --release -p aegis-orchestrator
The CLI README and crate READMEs go deeper on command surface and internals:
Related
We build two other products at 100monkeys.ai:
- Carbon Forge: source control for people and agents. Code, files and prose live in one record on the server, an agent opens a lane instead of cloning, and a landing is one changeset written whole or not at all. Public workspaces are free and every account includes one free private workspace.
- Zaru: a personal AI assistant that helps with messages, planning, follow-ups and scheduling, and shows you what it did. Its terminal harness is open source: zaru-cli.
License
Copyright © 2026 100monkeys AI, Inc.
Licensed under the GNU Affero General Public License v3.0 (AGPL-3.0).
