Keep coding agents on task: park it, don't do it

2026-10-054 min read

The detour

You ask for a CSV export. On the way, the agent notices a flaky test, an outdated dependency and a function name it doesn't like. It fixes all three. The export is half done, the diff touches 9 files, and 2 of the fixes land in files another agent is working on.

Telling it to stay focused doesn't help much, because what it noticed is often worth something. It needs a place to put it that's cheaper than doing it.

Park it: one insert, then carry on

The project template has a memory table next to the task board. Anything off-task is one row:

INSERT INTO memory (kind, title, body, paths, author) VALUES ('parked', ?, ?, ?, ?)

The title says what, the body why it matters, paths which files it concerns, and the author is the agent's handle. Then it goes back to the export. Parked rows aren't anyone's job yet. The briefing shows how many are waiting, and at the end of a phase a lead turns them into tasks, conventions or questions.

Questions: ask, and keep going

Some things need you. Should the export include deleted orders? The agent records it with kind question, in the same insert. The guide tells it to pick the reversible option meanwhile: leave deleted orders out behind a flag, add a column rather than drop one, keep the old endpoint next to the new one. It keeps working, and you answer when you look. Open questions stay in the briefing until someone closes them or records the answer as a decision that supersedes them.

Conventions and decisions

Two kinds hold rules. A convention is a rule for the other agents: "API handlers return errors as code and message", "tests live next to the file they test". A decision is a chosen approach, and its body says why and what lost:

kind:  decision
title: Run CSV exports on the existing job queue
body:  Because it already retries and shows progress.
       Rejected: a new cron worker (no retries), streaming
       in the request (times out on large accounts).
paths: src/exports/

A later agent that reaches for streaming in the request finds that someone weighed it, and why it lost. The other kinds are finding, for something learned about the code, and handoff, for unfinished work: its state, the next step and where to look.

Supersede, don't edit

When a decision changes, the agent doesn't rewrite the old row. It inserts a new one with supersedes set to the old id. The current_memory view shows only open rows that nothing supersedes, so agents read the latest version and you can still trace how it got there.

That's a rule in the guide, not a lock. The database would accept an UPDATE. What it does enforce is the shape: the 6 kinds, and a body of up to 2,000 characters.

What every session starts with

SELECT * FROM briefing

The briefing is one list: tasks in progress, in review, blocked or stuck; how many tasks are ready; every open convention, question and handoff; the 10 latest decisions; and a count of parked items to triage. Parked items show only as a count, on purpose. They aren't instructions, and an agent starting its session shouldn't go and do them.

Look before touching an area

The briefing keeps to the latest decisions. Before an agent changes a part of the tree, it looks up everything recorded about it, with ?1 set to %src/exports/%:

SELECT id, kind, title FROM current_memory WHERE paths LIKE ?1 OR title LIKE ?1

That turns up the older decision that's no longer in the latest 10, the finding about the slow query, and the note someone parked about the same file last week.

Copy this prompt to set it up

In Claude Code, /mcp__databased__project sets up the board and memory. In any client, you can paste this instead:

Use the databasedmcp project database named after this repo as shared memory (create it from the project template if list_databases doesn't show it). Read its guide with get_database and follow it from now on, in particular:

- Anything off-task you notice: park it with one insert and carry on with what I asked.
- Anything you need me for: record a question, pick the reversible option meanwhile, and keep going.
- An approach you choose that others should know: record a decision, with "because…" and "rejected…" in the body. Never edit a body; supersede it.
- Before you touch an area, look up current_memory for its paths.

Then run the briefing and tell me the open questions and how many parked items are waiting.

What it doesn't do

databasedmcp doesn't decide what's off-task: the agent does, from the guide and from what you asked. Nothing stops an agent from fixing the flaky test anyway, or from editing a body in place. The guide gives it a cheaper option and the database keeps the record. Parked items don't sort themselves either. A lead agent or you has to read them. And memory is only as good as what goes in it. A decision with no "because" doesn't stop the next agent from trying the rejected option again.

Create an account