Animus CLI: An Autonomous Agent Orchestrator in Rust

If you already use Claude Code, Codex, Gemini, OpenCode, or other coding agents, the next bottleneck is not prompting. It is coordination. Animus CLI turns those agents into a local-first delivery system: queued work, isolated git worktrees, YAML workflows, review loops, plugin-managed integrations, schedules, triggers, and MCP control from the tools you already use.

Animus is built for a very specific kind of builder: the solo founder or small team trying to ship across a portfolio without turning every idea into another manual project-management loop. LaunchApp founder Sami describes using it to run 80 agents in parallel across 16 projects. That is the pitch in one sentence. Not one smarter agent, but a runtime that lets many agents work safely at once.

The project is still pre-1.0, but it is not a sketch. At research time, the public repo showed 39 GitHub stars, 1,512 commits, and a latest release of v0.6.31 (published June 30, 2026). The codebase is Rust-native and local-first, with the orchestration daemon, plugin system, CLI surface, workflow engine, queues, logs, and MCP integration all designed around running real work from your own machine or infrastructure.

The problem Animus is solving

Most agent tools are excellent at the single-session experience. You open Cursor, Claude Code, Codex, or another assistant. You give it a task. It edits files. You review the result.

That works until you have more work than one chat can hold.

A founder with five products does not just need an assistant that can write a function. They need a system that can pick the next highest-priority task, branch safely, run the right agent, review the output, ask for rework if needed, open or merge a pull request, clean up the worktree, then move to the next item.

That is the gap Animus targets. It is not another Python framework for building agents from scratch. It is a CLI-native orchestration runtime for coordinating the agents and tools you already use.

How Animus works

Animus is organized around a background daemon and a priority queue. Work enters the system as tasks or subjects, then the daemon dispatches workflows according to available capacity.

Those workflows are declared in hierarchical YAML. The core pieces are simple:

Agents define a named profile: model, tool, MCP servers, permissions, and system prompt.
Phases are reusable execution units. A phase can run an agent, execute a command, or wait for a manual human gate.
Workflows compose phases into pipelines, including skip conditions and post-success hooks.
Schedules and triggers let work run autonomously through cron schedules, file watchers, GitHub webhooks, and other event sources.

The important detail is that Animus treats agent output as part of a delivery pipeline, not as a one-off chat result. Every agent phase returns a typed verdict: advance, rework, skip, or fail.

That gives you a real feedback loop. An implementation phase can make a change. A reviewer phase can inspect it. If the reviewer returns rework, Animus sends the feedback back to the implementer and repeats the cycle up to a configured max_rework_attempts limit.

That is the difference between automation that only runs once and orchestration that can correct itself.

Why Rust matters here

Animus is Rust-native because the job is operationally risky. The daemon may be coordinating many concurrent agents, each working in git worktrees, touching repositories, running commands, producing logs, and potentially opening or merging pull requests.

The public repository is primarily Rust by GitHub language metadata, and the README positions the project as Rust-first. That matters because this is infrastructure code. A local daemon that manages queues, plugins, git state, process execution, and concurrent workflows benefits from Rust's type safety, memory safety, and predictable deployment story.

For the user, the practical payoff is simpler: Animus ships as a command-line tool and daemon rather than a Python library you have to embed, host, and maintain yourself.

Plugin-first, not provider-locked

One of the strongest design choices in Animus is that the core is not tied to a single model company.

Since the v0.4.12 migration, Animus has moved to a plugin-first architecture. Providers, subject backends, triggers, transports, workflow runners, queues, web surfaces, and related integrations live outside the kernel as installable plugins.

That means an Animus project can use providers for tools such as Claude, Codex, Gemini, OpenCode, Ollama, and OpenAI-backed agents. It can pull work from subject backends such as Linear, GitHub Issues, Asana, Jira, SQLite, or Markdown. It can be driven by webhooks, Slack, HTTP, GraphQL, a browser UI, or MCP clients.

This is a different bet from vendor-specific agent SDKs. Animus treats agents as external tools that can be routed, scheduled, and composed.

That also opens the door to cost-aware and complexity-aware routing. A small bugfix can go to a fast, cheaper model. A UI task can go to a vision-capable model. Architecture work can go to a stronger reasoning model. The orchestrator decides where work should go. The workflow does not have to be rewritten around one provider.

Project manifests and repeatable setup

A recent addition makes the system easier to understand: the animus.toml project manifest.

Think of it like package.json or Cargo.toml, but for an agent-orchestrated project. It declares the Animus kernel version, plugins, and packs a project expects. Running animus install resolves those requirements into a lockfile.

That matters because orchestration systems often fail at onboarding. The demo works, but the real repo has hidden local state, missing tools, and mystery configuration. A committed project manifest gives teams a repeatable starting point: clone the repo, install the declared Animus environment, then run the daemon.

Security is part of the product, not a footnote

Animus installs third-party binaries and runs them near your repositories. That is exactly the kind of tool where supply-chain trust has to be designed early.

The plugin signing architecture includes Sigstore cosign keyless signing, optional strict signature requirements, manifest-name checks, reserved provider guards, plugin lockfiles with exact SHA256 hashes, and trust-on-first-use org allowlists. Those controls do not make arbitrary plugins magically safe, but they do show the right posture for a tool that asks developers to automate real work.

For founders, this is the right tradeoff to care about. The goal is not to give agents unlimited power. The goal is to give them repeatable, auditable lanes to operate in.

Where Animus fits in the agent landscape

The agent ecosystem is crowded, but Animus occupies a different slot from most popular tools.

LangGraph is a strong framework for building long-running, stateful agents in Python. CrewAI is useful for composing collaborative agent teams and flows. OpenAI Agents SDK and Anthropic's Claude Agent SDK give developers vendor-backed primitives around their respective platforms.

Animus is not trying to replace those categories directly. It is closer to infrastructure for running existing coding agents as a portfolio-scale delivery system.

A useful shorthand is this:

LangGraph and CrewAI help you build agent applications.
OpenAI and Anthropic SDKs help you build on specific vendor runtimes.
Personal autonomous agents try to be the worker.
Animus coordinates workers across queues, branches, phases, plugins, schedules, and pull-request workflows.

In other words, Animus is not the agent. It is the local control plane for agents.

Who should try it now

Animus is most compelling if you already believe coding agents are useful, but you are tired of manually babysitting each session.

It is for portfolio builders, indie hackers, founder-engineers, and small studios with more product surface area than hands. It is especially relevant if you want agents to work in isolated branches, follow repeatable review loops, run on a schedule, and integrate with your existing task sources.

It is probably not necessary if your whole workflow lives comfortably inside one IDE chat window. If you only need occasional assistance, the orchestration overhead may not be worth it yet.

But if you are starting to think, "I do not need one better coding agent, I need 20 agents working safely without me watching every step," Animus is aimed directly at that problem.

What to do next

Animus CLI is open source at launchapp-dev/animus-cli. Start with the README, install the binary, define a small YAML workflow, and run the daemon against a real but low-risk repository.

If you already use Claude Code, Codex, OpenCode, Cursor, Slate, or Kiro, also look at the companion animus-skills repo. It provides skills and slash commands that teach those clients how to drive Animus through MCP.

The project is early, but the architecture is unusually practical: local-first, Rust-native, plugin-first, model-agnostic, queue-driven, and built around git worktrees rather than abstract demos.

For solo founders, that is the real promise. Not replacing engineers with a magic agent. Giving a small team the operating system to coordinate many agents without losing control.