latest release · runtime profiles · suite installer

The operations runtime for AI coding agents.

Alfred handles the operational burden so humans focus on decisions. Design, test, evaluate, secure, and port agents, subagents, and skills across AI coding harnesses — now with runtime profiles, smart per-agent model assignment, worktree-aware installs, and local-first context compaction.

~/projects/alfred-workspace — zsh
$ curl -fsSL https://raw.githubusercontent.com/GOI17/main/install.sh | sh

============================================================
 ALFRED SUITE INSTALLER
============================================================
Edition        coding / memory / full
Harnesses      opencode [installed] · codex-cli [installed] · pi [installed]
Profiles       runtime profiles / decide later
Models         smart defaults for *, orchestrator, developer, temporary
Target path    ~/.alfred/installs/default

Preview:
  + core, agents, skills, profile-manager, adapters, evals
  + ~/.alfred/models.json (model defaults preview)
  + .ai/generated/opencode-install (harness preview)

No files have been written yet.
Apply safe suite install steps now? [y/N]

Runs locally against your favorite harness

opencode Pi Codex Claude VSCode Kiro

Agents are easy to write. Hard to operate.

The first agent demo is always a triumph. The second week is permission sprawl, drift between harnesses, silent regressions, and a graveyard of half-finished skills. Alfred is the runtime layer that makes the second week boring — in a good way.

Drift

Same agent, five harnesses, five dialects

Pi, opencode, Codex, Claude, and VSCode each have their own agent spec, their own skill format, and their own opinion about permissions. Porting means rewriting the same logic over and over.

Token burn

Paying an LLM to do arithmetic

Agents route every task to a provider, even when a local regex, file lookup, or eval can answer the question. Costs balloon and latency goes through the roof for deterministic work.

Security

Prompt-injected privilege escalation

Agents self-modify, broaden their own permissions, and read protected paths because a tool "happened" to return a friendly suggestion. There is no deny-by-default surface.

No regression gate

"It used to work" is not a test suite

Prompt tweaks ship on vibes. A single line change in a system prompt can silently break seven evals, but you have no baseline and no gate to catch it.

Skill chaos

Skills everywhere, triggered by nothing

Skills get bolted on. Nobody knows when they load. Some load eagerly and burn context, some never load because nothing routes to them.

Machine drift

Same agent, different laptop, broken config

PATHs differ, providers are enabled on one machine but missing on another, models disappear, and plugins need local-only overrides. Alfred profiles make that operational state explicit.

Eight pillars, one runtime

Alfred is opinionated about the operational layer and quiet about everything else. Bring your own model, your own harness, your own workflows. We handle the rest.

01

Hexagonal + DDD

A harness-agnostic core with adapters as ports. Core never imports an adapter. Adapters never redefine domain rules.

02

Harness portability

Alfred compiles one source-of-truth into executable adapter previews for opencode, Codex, and Pi while keeping compatibility contracts for harnesses that do not yet have a live adapter.

03

TDD for agents

Every agent, subagent, skill, and policy change must run an eval suite. Improvements are accepted on numbers, not vibes.

04

Granular permissions

Deny by default. No agent may broaden its own permissions. Escalation requires an explicit human trace event.

05

Lazy-loaded skills

Skills activate by trigger and project signal, not by file presence. Cold context stays small; hot context stays relevant.

06

Specialist lifecycle

Temporary subagents come, do one job, and retire. Promotion to a permanent agent requires an explicit human decision.

07

Evals + observability

Every operation emits a trace event. Baselines gate regressions. Replays are reproducible from the trace log alone.

08

Local-first profiles

Detect PATH, provider, model, and plugin availability locally before activating an agent profile. Smart per-agent model defaults and avoided provider calls are traced too.

Built for long-running real projects

Alfred now handles the operational details that show up after the demo: context pressure, worktrees, model drift, and delegation failures.

Compaction

Stay out of the dumb zone

Automatic context compaction triggers around 35% usage, uses local heuristics first, and only offers provider-assisted summaries with approval.

Worktrees

One project identity across worktrees

Alfred resolves the real git directory plus origin URL so worktrees reuse the parent repo identity instead of reinstalling from scratch.

Models

User-owned models per agent

The installer detects local providers, previews ~/.alfred/models.json, and lets you assign per-agent primary models with a global fallback chain without hardcoding specs.

One core. Many adapters. Zero leaks.

The packages/core boundary is enforced by the build itself. Adapters depend on core; core does not know adapters exist. Runtime profiles sit beside adapters, so machine-specific activation never leaks into agent definitions.

Six agents, one coordinator

Alfred ships with one primary agent (the orchestrator) and a panel of subagents. Each has a single responsibility, an explicit mode, and a deterministic scope.

  • orchestrator · primary · coordinates the panel, loads the kernel
  • developer · subagent · coding tasks, follows the architecture kernel
  • qa · subagent · writes and runs evals, designs regression coverage
  • librarian · subagent · owns documentation, lazy-loads skills
  • architect · subagent · DDD boundaries, hexagonal ports
  • reviewer · subagent · policy enforcement, baseline comparisons

orchestrator primary

Coordinates the panel. Loads the kernel. Owns the trace stream.

developer sub

Implements code, skills, and adapters within the kernel.

qa sub

Designs eval cases, runs the runner, owns the baseline.

librarian sub

Curates documentation. Lazy-loads skills by trigger.

architect sub

Owns the domain model. Guards the hexagonal boundary.

reviewer sub

Enforces policy, blocks regressions, signs off releases.

Two profiles. Same agent. No manual config surgery.

Alfred includes packages/profile-manager: shared profile defaults, private machine overlays, secret scanning, local capability checks, and approval-gated activation into ~/.config/<agent>.

Profile what changes between machines

Keep agent behavior stable while letting each laptop or workstation choose the provider, model, plugin set, MCP headers, and PATH-backed tools it can actually run.

  • profiles/ · tracked defaults safe to share
  • profiles.local/ · ignored local overlays for secrets and machine-only plugins
  • doctor/plan/switch · inspect before writing live harness config
  • secret scan · blocks literal tokens in tracked JSON/JSONC
runtime profiles
Runtime profiles
────────────────
Profile strategy   runtime profiles / decide later
Active profile     work / personal / custom
Harness            opencode

Preview:
  + shared defaults under ~/.alfred/profiles
  + private machine overlay for providers, models, plugins, PATH
  + approval-gated activation into ~/.config/opencode

Apply profile activation now? [y/N]

Same agent, every harness

Alfred is harness-agnostic. Adapters compile the same .ai/ source-of-truth into the dialect each runtime expects. Runtime profiles then activate the right machine-local provider/model/plugin overlay for that harness.

Harness Adapter status Source package
Pi Executable spike packages/pi-adapter
opencode Executable translation spike packages/opencode-adapter
Codex Executable translation spike packages/codex-adapter
Claude Compatibility contract .ai/harnesses/claude
VSCode Compatibility contract .ai/harnesses/vscode
ChatGPT / Gemini Memory integrations packages/chatgpt-adapter · packages/gemini-adapter

Stop rewriting agents. Start operating them.

Open the guided installer, choose the edition/harness/profile strategy with explanations, or read the architecture overview before you commit.