Haven is a local-first backlog manager for work that spans humans, AI agents, repositories, and real life.
It is not an issue tracker dressed up with MCP. Most issue trackers are good once work has already become an issue: a ticket, a sprint item, a task assigned to someone, a pull request waiting for review.
Haven sits slightly earlier. It is for managing the backlog itself: fuzzy ideas, half-formed bets, evidence, decisions, specs, readiness, ownership, and the question of what is safe to pick up next.
A normal TODO list is too flat. A chat transcript is too ephemeral. A repo-local PLAN.md is useful until the work crosses repositories, needs private context, gets handed to another agent, or turns into a decision someone has to make next week.
I want to ask an AI agent:
What is ready for you to work on?
And I want the answer to come from a real backlog, not old chat and vibes.
The backlog is the bottleneck
A lot of AI tooling is focused on delivery: generate the plan, write the code, run the tests, open the PR, review the diff. That makes sense. It is where the first obvious productivity gains showed up.
But when implementation gets much faster, the scarce work moves upstream. The hard part becomes deciding what should be built, why it matters, what evidence supports it, how ready it is, what depends on what, and what would count as done.
That is backlog management. It is product-management work, not just software-delivery work.
Where Haven fits
Most existing tools do not feel shaped around that problem. Jira, Linear, GitHub Issues, Asana, and similar tools are useful once an organisation needs shared execution, reporting, permissions, and team coordination. They are not primarily built as an AI-readable backlog layer where one person and their agents continuously shape intent into ready work.
That is the gap Haven is trying to fill. It sits upstream, in the product-management work that decides what should be in the backlog, why it matters, how ready it is, and what needs to happen before a human or agent should pick it up.
The to-do app example below is deliberately small, but it shows the shape. A useful backlog is not just a column of tickets waiting to be implemented. It carries priorities, readiness, blocked items, parked ideas, supporting documents, human review, and proof that finished work is actually finished.
The problems I wanted to solve
Haven came out of a set of practical annoyances, not a desire to build another tracker.
-
AI as a first-class collaborator. I wanted to talk to Claude or Codex about the backlog and have it capture ideas, find related items, split something too large, group a theme, attach a mockup, or explain why nothing was ready.
-
Somewhere durable for product intent. Vision docs, research, decisions, assumptions, specs, and evidence needed a good consistent home outside the development repo.
-
Decision provenance. Priorities change quickly in organisations, often because of external factors. I wanted a tool that could answer why a feature was delayed, what we decided to do instead, and what evidence or constraint drove the change.
-
Local files without the repo trap. Local spec files, backlog files, JSON files, and repo-local planning notes. were awkward in public repos. I wanted them versioned and backed up, but not in my GitHub repo.
-
Good backlog practice by default. Readiness should be separate from commitment. Blockers should be visible. Acceptance should be explicit. Context should stay close to the work. "What is next?" should have a real answer. I wanted all this to be table stakes.
-
Work that survives handoff. The next actor might be me, a coding agent, a reviewer, a remote environment, or a future session that has none of the current chat context. I wanted to avoid as many 'agent handoff' docs as possible.
-
A path to remote access without giving up local control. The tool should feel local and file-friendly, but the work should not be stranded on one machine forever. I want to be able to chat to Claude about the roadmap in my car.
How Haven meets those needs
Haven keeps the structure of the work in a local SQLite graph: items, dependencies, grouping, readiness, commitment, ownership, waiting state, artifacts, and completion evidence.
The working material lives as ordinary Markdown files under ~/.haven: specs, research, decisions, handoff notes, delivery evidence, and project documents. The graph answers structural questions. The files hold the thinking.
Haven also records the history of backlog changes, so product decisions do not disappear when priorities move. Splits, merges, parking, reprioritisation, and deprioritisation can keep their rationale, which makes the backlog useful as a record of how decisions changed, not just what the current list says.
A local agent can still read, edit, and grep real files on your computer. However, the canonical backlog does not have to live inside the code repo, and the graph remains queryable by the CLI and by agents through MCP. The public release is local-first today, with cloud sync intended to make the same backlog reachable from remote agents and other machines later.
In practice, most of my interaction with Haven is conversational. I talk to Claude or Codex, and the agent uses Haven's CLI or MCP server to read and update the backlog.
Haven gives the backlog a few simple rules. An item can move from discovery, to definition, to ready, to in_progress, to done. Separately, it can be committed and prioritised, or it can remain floating.
A well-specified idea can sit parked for months. A committed bet can still be fuzzy and need definition before anyone should pick it up. haven next only returns work that is committed, ready, and unblocked. If nothing is eligible, Haven can explain why: not committed, not specified, blocked by a dependency, waiting on a human, or waiting on an external event.
That also reduces the need for separate handoff documents. The next human or agent can pick up the item from the backlog state, linked artifacts, waiting reason, and completion evidence rather than reconstructing the work from chat.
The product philosophy is deliberately simple: Haven is not where the intelligence lives. Haven stores the data, keeps the shape, and exposes operations like capture, split, rank, search, attach, handoff, and complete. The AI brings the semantic work: it reads the context, notices overlap, proposes a split, drafts a spec, or explains why the queue is empty. The human can accept, correct, or reject that work.
Not just software development
Haven is not restricted to software development.
Software is where I felt the problem first, because coding agents make the cost of weak backlog quality obvious. But the underlying model is broader than code: work can be represented as a graph of intent, dependencies, readiness, ownership, and proof.
A project like "launch a small product company" is not only a set of development tasks. It might include market research, positioning, naming, company setup, domain purchase, account creation, policy decisions, product build, launch copy, support documents, and review.
Some of that work is suitable for AI. Some of it can be researched or drafted by AI but decided by a human. Some of it is blocked on real-world action: a payment, an approval, a legal step, an account, a conversation, a judgement call.
That is the kind of shape the graph is meant to hold.
With orchestration on top, an AI can keep advancing the AI-owned, ready, unblocked frontier, while the human is pulled in for judgement, approval, taste, access, risk, or physical-world action.
That is the broader ambition: mixed human/AI projects where the system knows what can move, what is waiting, what needs a person, and what changed as the work unfolded.
Status
Haven is in daily use. I run my own work through it. It is aimed at people who use command-line tools such as Claude Code or Codex.
The local workflow is working end to end: items, dependencies, grouping, handoffs, lineage, haven next, haven dispatch, full-text search, artifacts, generated repo workspaces, and the MCP server.
Haven does not launch agents, run tests, or merge pull requests. It is the backlog and work-document layer those tools can read from and write back to.
The code, install steps, and the fullest documentation now live in the Haven repo on GitHub. There is also a shorter project page for Haven on this site.
As implementation gets faster, the bottleneck moves toward backlog quality. An agent needs to know what work is real, what is ready, what context matters, what would count as done, and what needs a human next.
That information needs to live somewhere more durable than the current chat. For me, that place is Haven.