Alfred

Why Alfred exists

Interactive coding agents finish a prompt while you sit at the keyboard, and each session forgets what the last one learned. Alfred is built for engineering work that should keep moving while you are away, handled by a small named team that carries its lessons forward: planned features, follow-up tests, reviewer comments, dependency bumps, docs gaps, multi-repo rollouts.

Alfred gives Claude Code and Codex two things a single session does not have. First, a memory: before a run an agent recalls what earlier runs learned, and after a run it files new lessons when it learned something durable, so the fleet stops rediscovering the same repo conventions and re-making the same mistakes. Second, judgment: named agents each do one job, Ra’s al Ghul reviews the code a different agent wrote, and a drafted plan waits behind an approval gate until you approve it. Alfred never merges its own work by default.

You do not sit in front of Claude or Codex and keep prompting every step. You give Alfred the goal, the repos, and the approval rules; Alfred keeps the loop moving until it has a pull request, a review finding, or a decision to bring back to Slack.

That work needs durable coordination: Slack threads and specs that can become scoped GitHub issues, per-firing worktree isolation, role-based engine routing across Claude Code and Codex, review handoff, hard spend caps, and a state machine that keeps multiple agents from colliding. It runs on a Mac or Linux box you choose and uses CLI auth you already pay for.

Alfred installs the engineering loop as a fleet, not as a tiny starter that you assemble later. Batman is the architect for cross-repo work, Drake scopes requests, Lucius implements, Ra’s al Ghul reviews, Bane adds tests, Nightwing handles high-priority review feedback, and the reliability agents keep cleanup, doctor, summaries, and status checks moving.

Under the hood, each agent is a fresh subprocess in its own git worktree, dispatched by the host scheduler (launchd on macOS, systemd --user on Linux), isolated by per-agent IAM, bounded by per-day spend caps with a fleet-wide Claude provider-limit block.

ALFRED_HOME is the runtime root. A fresh install defaults to ~/.alfred. No external agent gateway, hosted memory database, skill registry, or dashboard service is required. Redis Agent Memory runs locally for recalled lessons, and FleetBrain stays on the host for review and reliability state.

flowchart TB
    scheduler["host scheduler<br/><i>survives restarts</i>"]
    role["$ALFRED_HOME/bin/{role}.py<br/><i>one stable role runner per agent</i>"]
    runner["agent_runner module<br/><i>lock · preflight · spend · claude_invoke · codex_invoke · gh · slack</i>"]
    engine["claude -p or codex exec<br/><i>the LLM work, in a fresh subprocess</i>"]
    gh["GitHub<br/><i>issues, specs, PRs, labels</i>"]
    slack["Slack channel<br/><i>your read surface</i>"]
    state[("$ALFRED_HOME/state + Redis Agent Memory<br/><i>JSON · FleetBrain · loopback Redis</i>")]

    scheduler --> role --> runner --> engine
    runner -- "claim / release / PR" --> gh
    runner -- "slack_post(severity=...)" --> slack
    runner <--> state

What you get

Autonomous scheduled runs

Agents keep working on schedule, survive host restarts, and do not depend on one fragile long-running process.

The loop around Claude and Codex

Alfred finds work, scopes it, runs agents in worktrees, checks results, records memory, and routes decisions back to Slack.

Plan-to-PR workflow

Slack requests, specs, and issues become bounded jobs: plan, claim, open a worktree, implement, PR, review, test, report, and merge when your policy allows it.

Role-level engine routing

Route builders and reviewers separately across Claude Code, Codex, or hybrid fallback.

Batman: architect agent

Batman leads the feature above the repo-local work. The parent-plan path reads one agent:large-feature issue, drafts a rollout across every affected repo or monorepo package, waits for approval, and then files scoped child issues so Lucius can pick them up in parallel.

Local memory with an LLM judge

Fleet-brain recalls repo lessons, file touches, failure patterns, and memory candidates. Structural gates and the judge decide what is safe to promote, while the operator can still inspect or override.

Per-firing git worktree isolation

Each claude -p invocation gets a fresh worktree. No cross-firing pollution; safe to crash mid-run.

Issue claim state machine

agent:in-flight → agent:pr-open → agent:done. Race-resistant cooperative coordination via GitHub labels + structured comments.

Visible output

Slack firing reports and shipped summaries show what ran, what opened, what merged, and what needs human review.

Quick start

Install Alfred Desktop-first onboarding for most users, plus a terminal path for headless hosts. Both paths configure the full local engineering fleet.

Let Claude Code or Codex install it A copy-paste prompt for AI-assisted setup: explicit repos, full fleet, no guessed secrets, auth checks before scheduled firings.

Pick your workspace shape One repo, multi-repo product workspace, plan-led work, or Batman bundle planning.

Let Alfred structure the plan Turn rough requests or specs into scoped issue queues, Architect plans, clean worktrees, reviewable PRs, and visible Slack summaries.

Plan in Slack Reply to Architect plans with plain language or structured scope commands before Alfred files child issues.

Add a custom role The Echo tutorial: pick, claim, invoke, act, release, report. The shape every bespoke role inherits.

Read the architecture Why host scheduling, why worktrees, why per-agent IAM. The design constraints that make Alfred opinionated.

How it works One agent firing traced end to end: scheduler trigger, the gates before any spend, claim, isolate, invoke, branch on outcome.

Meet the fleet The full engineering roster: Batman, Lucius, Drake, Ra's al Ghul, Bane, Nightwing, Robin, Huntress, Gordon, automerge, memory, code-map, cleanup, reports, and fleet doctor. What each codename does and how work flows between them.

Alfred Desktop The Mac/Linux app installs or repairs core, guides setup, and operates the local fleet while Slack stays the collaboration surface.

Roadmap

The engineering fleet, local memory, Slack planning loop, and signed Mac/Linux desktop app all ship today in v0.6.0. The next larger categories are content, sales, and ops; each needs its own integrations, prompts, tests, and human-approval rules.

Content

Blog, LinkedIn, SEO drafts, and site-page generation. Human approval before publish.

Sales / SDR

Prospect identification, event-page sourcing, and outreach drafts. Human approval before send.

Ops departments

Personal assistant, finance, and product-ops agents with drafts-only defaults for anything that sends, publishes, or pays.

The full roadmap tracks what is in flight.

Status

Latest release: v0.6.0. Alfred ships a local coding-agent fleet for single operators and small teams: install, full-fleet setup, prompt seeding, GitHub label setup, specs-assisted workspace patterns, doctor, dry-run, Linux/systemd or macOS launchd scheduling, Claude/Codex engine routing, a self-healing reliability core, Slack reporting, isolated worktree execution, FleetBrain GitHub polling, worker heartbeats, Redis Agent Memory recall, a code-structure memory layer over MCP, autonomously captured memory candidates, planning-memory recall, and a signed native Mac/Linux client with a public download page and a Homebrew cask.

The signed desktop app and Linux packages are published on the latest release, so brew install --cask alfred-os installs the app and brew install alfred-os installs the CLI. The design boundary is stable: one operator or small team, one local host, local CLIs, isolated worktrees, GitHub as the coordination layer. PRs are welcome when they strengthen that shape: reliability, setup, docs, tests, new roles with clear scope, or optional integrations that fail cleanly. Bigger shifts, such as a new department or runtime change, should start as a discussion.

License: MIT.