anthropics/cwc-long-running-agents: Why Long-Running Agents Need a Harness, Not More Prompts

A compact Bash-and-Git reference architecture that forces evidence, preserves memory, and separates builders from judges.

6 to 7 min read • View on GitHub • More from anthropics

A long corridor of file cabinets and locked doors, with a small agent figure stopped at a results door until it places a read receipt on a desk. The image explains that success cannot be declared until evidence has been inspected and recorded. — The repo’s core idea is simple: no proof, no pass. The harness turns that rule into a physical obstacle the agent has to cross.

Key Takeaways

This repo treats long-running agents as untrusted actors, so it enforces proof before it allows a result to be written.
Its real invention is harness engineering, where hooks, files, and Git shape behavior more reliably than prompt wording.
The evaluator gets a fresh context and fewer tools, which separates judgment from momentum and reduces self-approval bias.
Git, progress files, and stop hooks turn fragile session memory into durable project state that survives interruptions.

The lie this repo refuses to accept

Most agent systems assume the model can judge its own work. This repo rejects that premise. Its sharpest move is a default-fail gate that blocks a pass result until the agent has first inspected evidence.

That sounds small. It is not. It changes the unit of trust from a model’s self-report to a workflow that demands observable proof before success can be recorded.

This is the repo in one flowchart. Read first, log the read, then and only then can the result file be written.

Two desks sit side by side in a split workspace. The left desk is cluttered with open tabs and half-finished edits, while the right desk is clean and focused on a diff, screenshots, and a stamp labeled judge only. The image explains why the evaluator starts from fresh context. — The builder gets momentum. The evaluator gets distance. That split is the difference between activity and judgment.

Harness engineering, not prompt engineering

The repo’s real subject is not a smarter prompt. It is a system of constraints that makes long-running work more accountable. Shell hooks, Git state, and Claude lifecycle events become the actual control surface.

That matters because long-running agents fail in repeatable ways: they drift, they forget, they declare victory too early. This harness is built around those failure modes instead of pretending they do not exist.

The control loop under the hood

The implementation is plain and effective. `.claude/hooks/` contains the interception logic, `.claude/settings.json` wires hooks to lifecycle events, `.claude/agents/` defines the evaluator, and `CLAUDE.md` extends the agent’s operating rules.

# Lightweight JSON parsing inside hooks
path=$(cat | python3 -c 'import json,sys; print(json.load(sys.stdin).get("tool_input",{}).get("file_path",""))' 2>/dev/null)

# Event-driven interception
# Tool call -> hook -> allow or block

The point of the design is not to modify the model. It is to intercept what the model tries to do. That is a different kind of architecture, closer to an operating environment than an application framework.

Why the evaluator gets a fresh context

The evaluator is separated from the builder on purpose. The builder can write and accumulate bias. The evaluator starts with `git diff` and screenshots, and it does not get the same power to edit the world it is judging.

That division is the strongest anti-hallucination move in the repo after the evidence gate. It reduces sunk cost bias by making judgment structurally independent from authorship.

System	Primary goal	How control is enforced	Evidence handling	Memory persistence	Evaluation	Best fit
anthropics/cwc-long-running-agents	Trustworthy long-running execution	Hooks, gates, and session controls	Requires evidence before result writes	Git and progress files	Separate evaluator with fresh context	Reliability-first harnesses
AutoGPT	General autonomy	Prompted tool loops	Usually model-led	Project dependent	Often self-directed	Experimental task chaining
LangChain Agents	Tool orchestration	Developer-defined chains	App-level logic	App-level logic	Externalized by the builder	Flexible app frameworks
Microsoft AutoGen	Multi-agent collaboration	Conversation structure	Conversation based	Conversation state	Peer agents and humans	Collaborative agent systems
CrewAI	Role-based crews	Role orchestration	Task workflow driven	Workflow state	Team-style coordination	Organized agent teams
OpenDevin	Software engineering agent	Environment and task loop	Tool and environment feedback	Session and task artifacts	Task specific verification	Coding and repo work

Memory that survives a broken session

Long-running agents do not just need a brain. They need a notebook that outlives crashes, resets, and context limits. Here, Git and `PROGRESS.md` play that role by pushing memory outside the model and into durable files.

# Session checkpoint on stop
# Conceptually: save state before the context disappears

git commit -am "session checkpoint"

That is a practical insight, not a decorative one. If an agent cannot preserve what it learned, it will relearn the same lesson inside every new session.

The human still has an off switch

The safety story is not hidden. `kill-switch.sh` checks for an `AGENT_STOP` file before tool use, and `steer.sh` gives the operator a low-friction way to intervene. The environment itself becomes the control panel.

That is a cleaner model than waiting for a chat prompt to catch up with reality. The operator can change the world around the agent instead of trying to outtalk it.

What this is, and what it is not

This repo is not trying to be the broadest agent platform. It is a reference harness for teams that care about reliability, oversight, and long-running work more than capability theater.

That is what separates it from systems like AutoGPT, LangChain Agents, AutoGen, CrewAI, and OpenDevin. Most frameworks optimize for what agents can do. This one optimizes for whether you can trust the result.