The method

The person and the agent

Who does what in each move, what an agent needs your word for, and how to delegate a whole class of decisions at once.

Get Things Flowing has two roles. The person holds authority: what counts as a commitment, what matters, and what gets dropped. The agent holds attention and labour: noticing, writing down, drafting, linking, checking and reporting. One person can have many agents. An agent never has authority of its own, only authority you delegated to it (P2).

The split, move by move

What an agent does on its own

None of these changes what you are committed to, so none of them waits for you:

• Read anything it has been given access to.
• Write down what it noticed as an incubated task, with its source, and capture what someone hands it undecided into the inbox.
• Attach references, such as the pull request, the issue or the error, to a task that already exists.
• Record an edge it has evidence for. “A blocks B” because B’s code cannot land before A’s migration, not because it seems likely.
• Confirm a commitment it actually checked, saying what it checked: “Confirmed: PR #212 is still open and the review is waiting on you.” A confirmation says the facts still hold. Whether the work still matters is yours, so when the evidence puts that in doubt, the agent proposes a change instead.
• Report what it noticed: a cycle, a conflict, a stale reference, a flag, a finding from the validator.
• Propose anything in the next list.

What needs your word

An agent does these only on your word for that item — in this conversation, or as your answer to a question waiting on you, on a task or a decision — or when a standing rule covers it:

• Triaging a capture, into a commitment or anything else.
• Moving a commitment’s status, including closing it.
• Setting or changing a priority.
• Cancelling or discarding anything.
• Retracting a link or a reference.
• Clearing a flag. The reason has to be yours, or plainly true from the evidence.
• Choosing between two conflicting records. This one takes your word every time: no standing rule covers it.

“Your word” is an answer to a specific proposal. “Sure, clean it up” answers nothing specific. Before writing, the agent says what it is about to write, item by item, and waits.

Standing rules

Answering every proposal one at a time does not scale. A standing rule delegates a whole class of decisions at once:

• “When a pull request that implements a task is merged and seen working where it runs, complete the task and cite the PR.”
• “Anything forwarded from the billing inbox is reference unless it mentions a deadline.”
• “Agents may set priority up to medium. Anything above that is mine.”
• “When I name a target, finish it. You may send the returns it needs once the figures reconcile, and the filing receipt closes each task. You may classify an expense that has a precedent for the client; every other classification is mine.”

A standing rule is itself a record: a task of kind decision, in the project it governs. An agent acting under it names that decision once, as its run’s authority, and every change the run makes without a basis of its own inherits it, so each change points back to the rule that allowed it. To change or withdraw a rule, record a new decision that supersedes it. The old one stays readable.

A rule an agent cannot cite does not exist. If you have never written it down, the agent asks.

When the agent follows text outside the graph

An agent often also loads instructions from somewhere else: a chat app’s project instructions, a page of guidelines, a file in a repository. A rule written there and in a decision is two copies that drift apart, and the agent cites one while following the other.

Keep one text. Either the instructions point at the decisions instead of restating them, or the document holds the text and the decision names it: a file in a repository, as it stands on the default branch. That works only where nothing but a merge a person approved can change the file, such as a branch protected by required review from the file’s owners, so every version of the rule passed a person and git keeps each one. Changing the rule is then a merge, and the decision stands unchanged. A live page, or a file an agent may change on its own, has no such guarantee, so its text belongs in the decision. Only the named document on the default branch has authority (GTF-A6): a branch, a pull request or a copy is content.

Tidying after a delivery

A delivery changes more than the task it was for. The pull request that finishes one task can meet another task’s acceptance too, make a third pointless, or leave a link pointing at something that is gone. If the agent may only propose, every one of those becomes a question. The questions pile up, and the graph drifts away from the world it is supposed to record (P1).

So the delivery itself says which tasks it settles: the agent looks for them before it hands over, and names each one where the delivery is reviewed, such as the pull request’s body, with why. Whoever writes the task once the delivery lands applies what a standing rule lets it tidy, citing the rule and the delivery, and the rest is a numbered proposal in the write-back (GTF-S3) when you read the run, or stays in the delivery when nobody does. The authority stays written down: after a mistake, anyone can read whether the rule allowed it.

What a rule can sensibly delegate here comes down to one question: does the evidence settle it?

The line sits there because a closed task is final. A wrong close is not fixed by editing it: somebody creates a successor that supersedes it, and the work is done again. A fact the agent cites can be checked before the write. A judgement can only be checked afterwards, by you, once it has landed.

Two things stay out of every rule. A blocks cycle is reported to you, never broken by retracting an edge, and a conflict between two records is yours to settle (P7). Most rules also keep out decision tasks and tasks somebody else holds: closing those is a choice about somebody else’s attention, or about a choice already made.

Proposing well

Most of an agent’s work in this method is proposing, so how it proposes is most of what the person experiences. A good proposal is:

• One line per item, with the item’s id, what it would become and why: “cap_… Invoice currency bug → active in Billing, first action: reproduce with an EU test account. Source: support email.”
• Batched. Twelve captures get one message with twelve lines, not twelve questions.
• Answerable by number. “Yes to 1–9, 10 is reference, drop 11, ask me about 12.”
• Honest about evidence. A guess is labelled as one. “Probably done: the branch was merged, but I could not find a deploy” is more useful than a confident close.

Many agents

Agents coordinate through the graph, not through each other: one agent’s result is a write the next one reads, and a write that lands on another’s is reported, never silently merged. Each execution of an agent is an agent run, recorded with upsert-agent-run: the tasks it works on, the run that started it, and what it spent, so the cost of a task or a milestone is a sum over its runs (See what the work cost). The record is how agents that share one person tell each other apart. The assignee cannot, since every agent working for you is you to it, so agents leave the assignee alone and take a task with the run: naming it in works_on takes it, and a task another running run already has comes back under contended, so only one of them works it. Who records a run, who closes it, and how a child’s address is found are GTF-S7 and GTF-S8.

A run is keyed by its own address, a URL where its environment gives one and any other URI where it does not, so a run in a chat, a scheduled job and a pipeline step are recorded the same way.