Planning Work for AI Agents That Forget

A coding agent can do an hour of genuinely good work. Then the session ends, the context window resets, and the next morning it has no idea what it was building or why. People reach for a bigger context window. That is the wrong fix. A context window is working memory, not a record. The fix is to put the record somewhere the agent can always re-read it.

That is the whole idea behind OpenPlanr: a CLI and a Claude Code plugin that turn a feature spec into a structured plan an agent can follow across sessions. The plan is the source of truth. The agent is just the thing that executes it.

The plan lives in files, not in the chat

Every artifact is plain Markdown under .planr/: epics break down into features, features into user stories, stories into tasks. Each task carries acceptance criteria in Gherkin, so "done" is defined before a line of code is written.

---
id: T-014
type: Tech
story: US-003
estimate: 3
---
# 301-redirect retired post slugs
 
## Acceptance
Scenario: a reader hits an old slug
  Given a post was published at /blog/old-name
  And its slug later changed to /blog/new-name
  When a request arrives for /blog/old-name
  Then the server responds 301 to /blog/new-name

Because the plan is files, it is also a diff. It reviews like code, it survives a restart, and two agents a week apart read exactly the same instructions.

Phases, not vibes

A single mega-prompt asking an agent to "build the feature" produces confident mush. OpenPlanr runs a pipeline of narrow agents instead, each with one job and a tight contract:

1. Analyze the codebase on init, so the plan is grounded in what already exists.
2. Turn designs into a design spec.
3. Decompose the spec into stories and tasks.
4. Implement, with a frontend agent and a backend agent taking one task at a time.
5. QA against each task's acceptance criteria.
6. Generate infrastructure config and documentation.

A narrow agent is easier to steer, easier to verify, and far less likely to wander than one prompt trying to hold the whole feature in its head.

Tasks that fit the system you already have

Task generation is ADR-aware. It reads the architecture decisions already recorded in the repo, so new work continues the existing system instead of quietly reinventing it. This is the difference between an agent that adds a second auth pattern and one that uses yours.

Two surfaces, one engine

OpenPlanr ships as both a command-line tool and an in-editor plugin. They share one deterministic engine, so the CLI and the editor can never drift into two different answers for the same project. status with no arguments, for example, emits the same whole-project delivery report either way: every spec, backlog item, and quick task by state, cross-referenced against GitHub and Linear.

Meeting the team where it already works

The plan does not stay trapped in a folder. Tasks sync two ways with GitHub Issues, and provider routing lets the same pipeline run against different model backends. The agent plans in .planr/; the team sees the work in the tracker they already use.

The lesson

Agents do not need more memory. They need a plan they can re-read, written down where a restart cannot erase it. Make the plan a first-class, version-controlled artifact and the agent stops being a clever improviser and starts being a reliable collaborator that picks up exactly where it left off.