Start
Introduction
What Flow is, the method it is built for, and where to start reading.
Flow is a task graph across every repository, served over MCP. Your agent reads it at the start of every run and writes back to it before it stops, so the state of your work lives in one record rather than in five chat histories and three issue trackers.
Get Things Flowing is the method for working with it. It is GTD for one person and the agents working for them. Most of these docs describe the method. The rules hold without Flow, and every page names the Flow operation that carries each move out, so an agent reading it knows which call to make.
Where to start
| If you want to | Read |
|---|---|
| Connect Flow to your agent and run the loop once | Quickstart |
| Know what Flow stores, and what it computes on read | How Flow works |
| Understand the method before you rely on it | Principles, then the person and the agent |
| Know what a working day looks like | Sessions |
| Give an agent the rules it follows | The agent protocol |
| Look up a status, an edge, a sequence or an operation | Vocabulary, examples, reference |
Why GTD needs a successor
GTD keeps commitments out of your head and in a system you trust: capture everything, decide what each thing means, and look at the system often enough to keep trusting it. It was designed for one mind, whose bottleneck was remembering. Agents move the bottleneck:
- Agents forget between runs. Whatever an agent knew when its run ended is gone. Anything not written into the system never happened.
- Agents write a lot. Five agent runs in a morning can each capture, close and relink work. A list edited that often goes stale faster than a person can review it.
- Agents are eager. An agent that reads “we should migrate the billing table” in a note may start migrating it. Writing an idea down must not turn it into an instruction.
- Work spans places. One piece of intent crosses three repositories, two chats and a pull request. A plan written as prose in any one of them drifts the day it is written.
What the method changes
Four changes, one for each failure above:
- The system is a graph, not a set of lists. Work is connected by typed edges, and what you can start now is computed from them rather than read off a list somebody keeps in order. See Connect.
- There are two kinds of actor. You hold authority. Agents hold attention and labour: they capture, draft, link and report, and turning something into a commitment stays yours. See the person and the agent.
- Every change to a commitment carries its cause. Starting, closing, parking or dropping one records why, so you in three weeks, or an agent in a new run, can reconstruct the reason without anyone remembering it. See Principles.
- Recovery replaces inbox zero. The inbox is allowed to fill. After a gap you do not clear it first: you ask what is on fire and take the one step that puts you back in control. See after an absence.
The five moves
Capture, Clarify, Connect, Engage and Review: GTD’s stages, renamed where the job changed, and Review also holds what replaces GTD’s full sweep after a gap. They do not run in order: captures arrive all day, and a review happens when a commitment comes due. The loop shows what each move produces and who has the last word on it.
If you are an agent
Read the agent protocol. It is the whole method as numbered rules, each linked to the page that explains it. Flow’s MCP server already sends the short form, the instructions, in the handshake.
Every page here has a Markdown twin at the same path with .md appended. /docs/llms.txt lists them all, and /docs/llms-full.txt is the whole method in one file.