long-running-agent-harness
Long-running agent harness
Plan and scaffold work so an AI agent can make incremental, verifiable progress across many context windows. Flow: design doc (human + AI) → Initializer once (creates feature list, runbook, backlog, progress) → Coding agent in a loop until done. The implementation backlog defines one work unit per session and helps identify milestones for human check-in. Based on Anthropic: Effective harnesses for long-running agents.
Problem
Agents work in discrete sessions with no memory. Without structure they tend to: (1) try to do too much in one go and leave half-implemented, undocumented state; (2) declare the job done too early; (3) leave bugs or undocumented progress. A harness gives each new session a clear picture of state and one concrete unit of work.
Workflow overview
| Phase | Who | What |
|---|---|---|
| 0. Design doc | Human + AI | Iterate in chat (or doc) with the user to produce one design doc: scope, acceptance criteria, tech stack, run/verify steps. No implementation. |
| 1. Initializer (once) | AI (sub-agent) | Run the Initializer prompt. Reads _working/design.md. Creates/refreshes in _working/: feature list (YAML), runbook, implementation backlog, progress file, optional init script. Does not implement features or create project scaffolding (assumes existing repo). |
| 2. Coding loop | AI (sub-agent each time) | Run Coding agent sessions: read progress → pick one work unit from the backlog → implement → verify using runbook → update progress and feature list → commit. At milestones (e.g. end of a work-unit group): pause, check in with the human; when satisfied, re-run Initializer, then continue. Loop until all features pass or the user stops. |
The top-level agent invokes the Initializer and each Coding session as sub-agents, passing the relevant prompt each time (no need to copy prompts into .cursor/rules/). Use whatever mechanism Cursor provides to spawn a sub-agent or new task and pass the prompt content (e.g. the contents of the Initializer or Coding prompt file).
Phase 0: Design doc (human + AI)
More from michael-f-bryan/skills
working-docs
Use when handling multi-step tasks, investigations, or long sessions where working notes, interim findings, and scratch planning are needed to keep context and handoffs clear.
23doc-coauthoring
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
23test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
19commit-messages
When suggesting or writing commit messages for this repo, follow these rules.
17code-like-michael
Write, refactor, and review code in Michael's style; explicit contracts, thin entrypoints, practical boundaries, anti-ceremony abstractions, deterministic tooling, and architecture that scales from function internals to repository shape.
16wikilinks
When generating or editing markdown content, actively look for existing pages to link to and incorporate relevant wikilinks so content is interconnected. Use when writing notes, docs, or any .md content.
14