SAW: A SAFe-Based Harness for Coordinated AI Agent Teams

The coordination problem SAW is built to solve

Most teams that adopt a coding agent hit the same wall after a few weeks. The agent can write a function, but it has no idea which ticket the work belongs to, which reviewer signs off, or what counts as done. Every session starts from a blank prompt, and the process knowledge lives in a human's head. SAW's answer is to encode that process as files the agent reads: 11 SAFe agent profiles under .claude/agents/, 24 slash commands under .claude/commands/, and 20 model-invoked skills under .claude/skills/. The README describes the intended audience as any team with repeatable processes, naming software, marketing, research, legal and operations. That breadth is honest about what the harness actually is: a set of conventions and guardrails, not a code generator. The SAFe framing matters because it supplies the vocabulary (roles, quality gates, cadence) that the agent profiles are named after. If your team does not already think in those terms, the vocabulary is overhead you are importing along with the tooling.

Hooks, commands and skills: how the three layers actually divide work

The architecture is three layers, and the split is the most interesting design decision in the repository. Hooks sit at the bottom and fire automatically: the README describes them as automatic guardrails for format checks and blockers, which means they run whether or not a human asked for them. Commands sit in the middle and are user-invoked, with examples like /start-work and /pre-pr. Skills sit on top and are model-invoked, described as domain expertise that loads automatically through Skills 2.0 frontmatter. The practical consequence is that a skill can surface without anyone typing its name, so the quality of your skill descriptions determines what the model pulls in. The same content is mirrored across provider directories (.claude/, .gemini/, .codex/, .cursor/), which is why the repository ships a sync script rather than a single install. The README notes that agent teams are experimental, and separately documents Dark Factory, a tmux-based way to run persistent autonomous agent teams on remote servers. Those two pieces are where the autonomy lives, and they are also where the repository is least settled.

Installing SAW and running a first ticket

SAW is distributed as a template repository. The README instructs you to click "Use this template" or copy the provider directory into your project, then run the setup script to replace placeholders such as {{TICKET_PREFIX}} and {{PROJECT_NAME}}. For Claude Code, the quick start copies the harness directory, customizes the placeholders in one pass, and then invokes a workflow command. The README gives this example:

# Copy harness to your project
cp -r .claude/ /your-project/.claude/

# Customize placeholders across all provider files ({{TICKET_PREFIX}}, {{PROJECT_NAME}},
# and the rest) in one pass:
bash scripts/setup-template.sh

# Start working
/start-work TICKET-123

After the copy and the setup script, the harness directories should be present in your project and the placeholder tokens should be gone. The Gemini CLI path is similar but installs the CLI first and uses a namespaced command:

cp -r .gemini/ /your-project/.gemini/
npm install -g @google/gemini-cli
export GEMINI_API_KEY="your-api-key"
/workflow:start-work TICKET-123

Codex CLI copies two directories and runs in natural language rather than slash commands:

cp -r .codex/ /your-project/.codex/
cp -r .agents/ /your-project/.agents/
npm install -g @openai/codex
export OPENAI_API_KEY="your-api-key"
codex

Cursor is the outlier. You copy the rules directory and open the project; the README states that rules activate automatically based on file context, and that @rule-name invokes agent roles manually:

cp -r .cursor/ /your-project/.cursor/
cursor /your-project

That is the whole quick start. There is no server to run and no service to configure, which is the point: the harness is files your existing assistant reads.

The manifest is the price of admission

Since v2.10.0 the sync script requires a manifest, and the README is explicit that this is what protects your customizations: files you mark as protected are not overwritten. That is a real safeguard, and it is also a maintenance obligation. The upgrade flow has two paths. The automated path initializes sync metadata once, then previews and applies a version with --dry-run before dropping the flag:

./scripts/sync-claude-harness.sh init
./scripts/sync-claude-harness.sh manifest init --yes
./scripts/sync-claude-harness.sh sync --version v2.11.1 --dry-run
./scripts/sync-claude-harness.sh sync --version v2.11.1
./scripts/sync-claude-harness.sh sync --version v2.11.1 --scope .claude,.gemini

The manual path adds the upstream repository as a git remote, fetches tags, diffs two versions with git diff --stat, and cherry-picks directories. Both are documented, and the README points to docs/HARNESS_SYNC_GUIDE.md for the full reference and docs/releases/v2.10.0-UPGRADE.md for rollback options. Note what that implies: rollback guidance lives in a version-specific upgrade document, not in the main README, so a team jumping several versions should read the release notes for each one rather than the top-level instructions alone.

Where SAW is the wrong tool

The harness assumes a process worth encoding. A solo developer fixing a bug on a side project will spend more time reading TEMPLATE_SETUP.md and maintaining a manifest than the guardrails return. The same applies to teams whose work is genuinely exploratory, where the ticket prefix and quality gates would be fiction. There is a second, sharper limitation: the README labels agent teams experimental, and Dark Factory runs autonomous agents through tmux on remote servers. Autonomous multi-agent execution is the part of this repository with the least settled contract, so treating it as a default rather than an experiment misreads the documentation. Finally, the multi-provider support is a copy-and-sync model, not a shared runtime. Four provider directories means four places where a change can drift, and the sync script exists precisely because that drift is expected. If you only ever use one provider, you are carrying directories you will not maintain.

How SAW differs from a plain agent configuration

The obvious alternative is a hand-rolled setup: a CLAUDE.md or AGENTS.md file plus a handful of custom commands, with no roles, no hooks and no skills layer. That approach is lighter and has no sync script to learn. The difference in mechanism is that a plain configuration file is read as context, while SAW's skills are model-invoked through frontmatter and its hooks fire automatically. Whether that automatic layer helps depends on whether you trust the model to select the right expertise without being told. A second comparison point is Cursor's own rules directory, which SAW also targets: the repository ships 18 Cursor rules, and the README says rules activate based on file context and that you invoke agent roles manually with @rule-name. So on Cursor the invocation model is closer to the hand-rolled approach than to the Claude Code path, which is worth knowing before you pick a provider. The project also cites six Anthropic engineering papers as the source of its patterns, and ships a CITATION.cff and CITATION.bib for teams that need to reference it formally.

Licence, evidence and upgrade cost

SAW is MIT licensed, with a NOTICE file alongside the LICENSE. MIT is permissive, so the practical questions are attribution and the provenance of anything you copy into a proprietary repository; the NOTICE file and the CITATION files exist for that reason. This is not legal advice, and a team with compliance requirements should read LICENSE and NOTICE directly. On upgrade cost, the repository has moved quickly: v2.10.0 landed on 2026-03-19, v2.11.0 on 2026-07-20, and v2.11.1 the same day as a public-accuracy release. The last push to the default branch was on 2026-07-20. Three releases in four months, with two of them on one day, suggests a project still correcting itself in public. The HARNESS_CHANGELOG.yml file and the per-version upgrade documents are where that correction is recorded. Budget for reading them at each bump rather than assuming a sync is mechanical.

Editorial conclusion

Adopt SAW if your team already runs a repeatable, ticket-driven process and wants that process expressed as agent roles, hooks and commands rather than as free-form prompting, and if you are willing to keep a harness manifest current. Do not adopt it if you want a single-agent coding assistant with no ceremony, or if you cannot commit to reviewing agent output before it reaches a branch. Before copying anything, read TEMPLATE_SETUP.md, run bash scripts/setup-template.sh on a scratch copy, and confirm which files the sync script treats as protected so your own edits survive the next version bump.

Frequently asked questions

Official sources

1. bybren-llc/safe-agentic-workflow on GitHub
2. License: MIT
3. Project website
4. README
5. Releases