Animus/ Blog
runtime ↗animus.team ↗github
← All posts
TUTORIAL · 6 min read · The Animus Teamfleetoperations

Running an autonomous agent fleet with AO

Last Tuesday, a new security patch dropped. By Wednesday morning, I had twelve nearly identical pull requests open across twelve different repositories. Each one updated the same dependency, ran the same CI pipeline, and needed the same review. The only difference was the repo name. If that sounds familiar, you are not alone. Portfolio builders and small studios face a scaling problem that has nothing to do with user traffic. Surface area is the enemy, and maintenance compounds faster than code. There is a way out. AO, also known as Animus, is an open-source Rust daemon that turns a single YAML file into an autonomous software delivery fleet. You define what you want, schedule when it runs, and the system handles the rest. Here is how it works.

The Problem Is Surface Area, Not Traffic

Every new repo adds boilerplate, dependency drift, and open pull requests to monitor. A linter rule changes, and your weekend turns into a manual copy-paste marathon. You do not need another dashboard. You need an operator that never sleeps.

The Stack: Three Open-Source Pieces

The AO fleet is not a single tool. It is a stack of components that share one philosophy: declarative configuration, scheduled execution, and hands-off results.

Core AO / Animus is the orchestration engine. It is 108,000 lines of Rust across 16 crates. You define agents, phases, workflows, and cron schedules in .ao/workflows/custom.yaml. The daemon dispatches tasks to models like Claude, GPT, or Gemini inside isolated git worktrees. Quality gates run, and results merge back to main through pull requests. You keep the YAML in version control, so your entire delivery pipeline is auditable in a single commit.

Source: https://github.com/launchapp-dev/ao

ao-fleet-pack installs a pre-built brain-repo agent team. It includes a conductor that scans your organization every five minutes and queues work; a fleet-manager that starts and stops daemons; a template-syncer that keeps shared packages consistent; a brain-reviewer that reviews and merges pull requests; and others that reconcile incomplete work and optimize workflows based on outcomes.

The pack also ships ready-made workflows with built-in cadences. The scan-compare-dispatch cycle runs every five minutes. The PR review and merge sweep runs every ten. The self-improving quality audit runs every three hours. You install the pack into a single brain repository, and the agents go to work.

Source: https://github.com/launchapp-dev/ao-fleet-pack

ao-fleet-tools provides the glue. It ships ao-fleet-monitor.sh, which renders a live dashboard of every project under ~/.ao and includes a --watch mode that refreshes every sixty seconds. A watchdog shell script runs via cron every five minutes to check all fleet daemons, restart any that have crashed, and log health events back to the brain repo. A worktree cleanup script purges build artifacts every fifteen minutes. There is also a Node.js MCP server, so any MCP client can query fleet state in plain language, including fleet.status, fleet.agents, fleet.queues, fleet.workflows, fleet.prs, and fleet.tasks.

Requirements are modest. You need the AO CLI installed, the gh CLI authenticated, and Node.js 22 or newer for the MCP server.

Source: https://github.com/launchapp-dev/ao-fleet-tools

One Brain, Many Repos

The architecture rests on a brain repo pattern. One central repository holds the fleet pack, agent definitions, cron schedules, and knowledge files. The brain's conductor agent scans the org, detects drift, and queues work. Individual project repos only need the base AO daemon and their own local configuration. The fleet-wide work is dispatched from the brain. Because monitoring scripts auto-discover projects from ~/.ao, there is no central registry to maintain by hand.

Cross-repo pull requests work like this. Agents such as pr-reviewer-org and brain-reviewer use the GitHub MCP server and the gh CLI to discover open PRs organization-wide, fetch diffs and CI status, leave reviews, and merge when checks pass. The cross-repo-execute workflow converts approved actions, stored in the brain repo's knowledge/actions/ directory, into real pull requests in target repositories.

This opens concrete patterns that save hours every week:

  • Upgrade React to v19 across all frontend packages. One task spawns N pull requests.
  • Fix TypeScript strict mode violations in every repo with a TypeScript codebase.
  • Patch a single CVE across the org. One task, multiple repo PRs.

Monitoring and Self-Healing

A fleet is only useful if you trust it to stay alive. AO runs as a Rust daemon in autonomous mode. The watchdog cron job fires every five minutes, checks every fleet daemon, restarts any that have crashed, and logs health events back to the brain. For a live view, the monitor script shows every discovered project and its status. You do not have to wonder if a repo is drifting. The conductor already knows.

The Local-First Reality

One important detail from LaunchApp's public documentation is that AO Cloud, a hosted version of Animus orchestration, is planned but not yet shipped. The fleet runs entirely local-first on your own infrastructure today. You bring your own API keys, and you keep your code on your own machines. That is good news for privacy, but it means you are responsible for the host.

Why This Pattern Is Real

These ideas are not theoretical. Nader Dabit, who works on Devin at Cognition, published a guide on running cloud-agent fleets that validates the exact architecture AO uses: isolated worktrees, review loops, playbook-driven repetition, and org-wide PR automation. Devin has reportedly merged 1.2 million pull requests across hundreds of organizations using these patterns. The difference is tooling. Devin is SaaS-first. AO is local-first, open-source, and driven by YAML you can version control.

Source: https://nader.substack.com/p/how-to-run-a-fleet-of-cloud-agents

Start Small, Scale Wide

You do not need to automate everything on day one. A practical path looks like this:

  1. Install the AO CLI and authenticate gh.
  2. Create a brain repo and install ao-fleet-pack.
  3. Configure a single agent, like the PR reviewer, with a ten-minute cron schedule.
  4. Let the conductor scan your org and open its first cross-repo task.
  5. Watch the dashboard, read the logs, and expand the fleet as your confidence grows.

Autonomous delivery is not about replacing engineers. It is about replacing the repetitive work that keeps engineers from building. With a single YAML file and a cron schedule, AO turns that promise into a running daemon.

Sources

  1. AO Core README, agents, phases, workflows, schedules, decision contracts: https://github.com/launchapp-dev/ao
  2. ao-fleet-pack README and workflow reference: https://github.com/launchapp-dev/ao-fleet-pack and https://raw.githubusercontent.com/launchapp-dev/ao-fleet-pack/main/workflow-reference.yaml
  3. ao-fleet-tools README, watchdog, monitor, cleanup scripts, MCP server: https://github.com/launchapp-dev/ao-fleet-tools
  4. LaunchApp Org Profile, repo map, stack overview, cloud roadmap: https://github.com/launchapp-dev
  5. animus-cli README, mention of ao-sync service and CLI setup: https://github.com/launchapp-dev/animus-cli
  6. "How to Run a Fleet of Cloud Agents" by Nader Dabit: https://nader.substack.com/p/how-to-run-a-fleet-of-cloud-agents