Open source · MIT

Agent Fleet

A persistent, multi-project, multi-machine AI agent that manages your development infrastructure through conversation.

Built on Claude Code.

GitHub Getting started

The problem

An agent session ends, and what it worked out goes with it unless something wrote it down. That covers the state of the project, the reason behind last week's decision and the fix that already failed once. With one project on one machine, re-explaining is a nuisance. With dozens of projects on several machines, the agent's context becomes the thing that needs managing.

People who decide how a team works with agents ask a related question: how agent work stays reviewable, bounded and recoverable when nobody watches every step.

Agent Fleet is one person's answer to both questions, built for daily use and published as open source.

What it does

Session memory and handovers

Each session keeps a running context file. At shutdown a rotation script moves it into a short rolling history and a full session log, and decisions are kept in a record of their own. The next session starts from that handover.

Knowledge loaded only when needed

Instructions sit in five layers: global, foundation, domains, references and project. Each layer loads when a task calls for it, so the context window stays free for the work.

Multi-machine sync

sync.sh keeps the configuration in one git repository and deploys it to every machine, with per-machine overlays for what differs. The setup code covers macOS, Debian and Ubuntu, Arch including SteamOS, Fedora and RHEL, and WSL.

Coordination between sessions

A registry lists every project. Sessions in different projects hand work to each other through an inbox instead of writing into each other's files. The afleet launcher picks the project to open.

Safety rails

A boundary guard blocks writes into another project's directory. Hooks on six session events all run through one wrapper, safe-run.sh, so a broken hook degrades instead of locking the user out. Edits to the most sensitive files need a fresh risk clearance first. Credentials are kept out of the code and stored with strong encryption.

Tests and a test-first discipline

The repository carries about 3,000 automated tests in 198 test files, plus end-to-end tests that run on request. New code is written against a failing test first, and the agent's own configuration enforces that rule.

In daily use

Matthias Gruber runs Agent Fleet on 8 machines across about 78 projects. He uses it every day for this website, his research, his books and his home lab.

One case from October 2026 shows the coordination at work. A research session and an infrastructure session launched a survey study together. The infrastructure session imported the study, smoke-tested it and activated it. The research session then re-checked the result on its own and found that the test cleanup had deleted more rows than the test had created. The fix was applied and acknowledged within the hour. The error was caught by the session that had not made it.

The research programme's use of it is described on the research site: research.matthiasgruber.com/agent-fleet/.

Install

Requirements: Linux, macOS or Windows with WSL; git, curl and Python 3; Node.js 18 or later (setup installs it through NVM if missing); Claude Code with a Max subscription or API access.

git clone https://github.com/JeltzProstetnic/agent-fleet ~/agent-fleet
cd ~/agent-fleet && bash setup.sh
afleet

afleet opens the first session, and the rest of the configuration happens in conversation. The step-by-step guide is under Getting started.

Design principles

Conversation over configuration. You tell the agent what you need and it edits its own setup.
The repository is the sole authority. Deployed files are copies, and every change is made in the repository.
Hooks before rules. A script check costs no model tokens, while a written rule costs tokens in every session. Where a script can do the job, the script is used.
Credentials handled with care. Secrets never sit in plain text in the repository; they are encrypted and deployed only where they are needed.
Inbox instead of cross-project writes. A project changes only its own files and asks others through the inbox.
Test-driven development, enforced. Tests come before the code they test.

Status

Open source under the MIT licence, with one maintainer. Changes are listed in the CHANGELOG.

Contact

Questions, bug reports and feedback: research@matthiasgruber.com, or through the GitHub repository.