Alfred is an autonomous engineering team tool built on top of Claude Code, Codex, and OpenCode. It is designed to solve the problem that interactive coding agents forget context after a single prompt and cannot continue working, allowing work to keep moving forward after you step away from the keyboard.
Purpose
Alfred turns Claude Code, Codex, or OpenCode into a spec-driven engineering team. Named agents plan work, write code, test, review each other, and open pull requests. It is suitable for work that needs to keep moving, such as planning features, reviewing comments, follow-up testing, dependency upgrades, and multi-repository deployments. Alfred advances each piece of work to a pull request that you can read, diff, and merge, and remembers what it learns for next time.
Key capabilities
- Autonomous engineering workflow: the planner turns requests into bounded implementation work; the architect can split approved changes across multiple repositories; the senior developer implements one issue in a single worktree and opens a PR; an independent reviewer checks the diff; the test engineer adds coverage; the fixer handles high-priority review findings.
- Role separation: each role has a single responsibility, and stable role identifiers (such as planner, senior-dev, reviewer, test-engineer) control scheduling and GitHub labels. Optional themes only change display names.
- Coordination layer: GitHub issues, labels, branches, comments, and pull requests form the shared coordination layer. Slack is optional and supports planning, status, and trusted control commands, but does not bypass approval gates.
- Local memory and code context: by default, recalled lessons are stored as embedded SQLite. FleetBrain keeps a local operations ledger, review queue, failure history, and work state. Memory candidates must pass structural checks and confidence review before they can affect subsequent runs. Operators can inspect, reject, retire, or roll back lessons.
- Context control: compress successful tool output while preserving complete failure output; read large files through structure-first and incremental views; rank and prune recalled lessons according to the prompt budget; add context impact scope before changes; and provide a pinned, checksum-verified codebase memory MCP binary after the repository scope is explicitly configured.
- Optional add-ons: dense local embeddings, Redis memory, Postgres with pgvector, Headroom compression, or alternative graph tools. These components remain inspectable and reversible.
- Local control interface: alfred manages settings, health,Roles, runs, engines, memory, and logs; alfred serve provides a loopback JSON API and browser interface; the Tauri desktop app uses the same local API; Slack provides an optional collaboration interface. ALFRED_HOME defaults to ~/.alfred and contains the deployed runners, state, logs, worktrees, and prompt overrides.
Usage
Alfred is open source and runs on macOS or Linux. The macOS desktop app (signed) can install or repair the local runtime and open guided setup, with the primary packaging target being macOS on Apple silicon. Signed macOS packages or Linux packages can also be downloaded from the downloads page. For Linux or source installations, as well as unattended setup, the repository scope must be explicitly provided. Before enabling scheduled work, the installation can be verified with a dry run, which resolves roles and checks the lifecycle without invoking engines or changing GitHub, Slack, git, schedulers, or project files.
Use Cases
Alfred is suited to independent developers and small teams who want autonomous work to continue between checkpoints while retaining explicit control over high-risk operations and merge strategies. Typical scenarios include planning features, reviewing comments, follow-up testing, dependency upgrades, and multi-repository deployments.
Limitations
Alfred runs with your local user privileges. Repository configuration controls what Alfred schedules and indexes, but it is not a filesystem or network sandbox. It only schedules work for the repositories you configure. Code change and review roles use separate worktrees. Before engine work begins, it checks locks, authentication, disk space, and spending limits. It stops repeatedly failing runs rather than retrying indefinitely. It keeps planned work behind the configured approval gate. By default, it does not merge its own PRs. It records run events and verification evidence for inspection. Runtime network usage may include configured model providers, GitHub, Slack, optional telemetry, and download endpoints for selected add-ons. Anonymous aggregate telemetry is enabled by default, excludes code, prompts, paths, repository names, branch names, and hostnames, and can be disabled at any time. Agents and project tools can make other network calls with your user account privileges. When a stronger boundary than repository configuration is needed, use a dedicated OS account, virtual machine, or container.
Other Information
Alfred uses reproducible tests and public artifacts rather than claims. Memory benchmarks report their fixtures, denominators, engines, providers, and limitations. Stub runs verify the test framework but do not count as engine evidence. The host scheduler starts a new process for each trigger. The shared runner performs preflight checks, creates or restores worktrees when a role requires it, invokes the selected CLI, records events, and updates GitHub. Alfred does not run a model gateway or long-term coordinator. The code is licensed under MIT, and the documentation and website content are licensed under CC BY 4.0.
