You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Proposal: agent task lists are per-process and ephemeral — let agents persist plans as draft issues
Motivation
buzz-dev-mcp's todo tool is how an agent decomposes work into steps. Its own module doc describes the storage:
In-memory session task list with _Stop and _PostCompact hooks.
…
State is per-process (Vec<Item> behind a Mutex). Items are {text, done} — no ids; the LLM provides a full replacement list.
The surrounding machinery shows the list is treated as important:
_Stop returns objection text if the agent tries to end a turn with open items.
_PostCompact re-injects the full list after context compaction/handoff.
Replacing the list while dropping an open item triggers a soft warning.
So Buzz already cares that an agent finishes what it planned. But the plan itself:
dies with the process — a crash, restart, or harness swap loses it entirely;
has no ids, so nothing external can reference a single step;
is invisible to humans — it lives in the agent's session, not in the workspace;
cannot be reviewed before the work happens.
That last point is the one that motivates this proposal. Today an agent's intent only becomes visible through its effects.
a draft status already exists — KIND_GIT_STATUS_DRAFT (1633) in buzz-core's kind.rs, and buzz issues status accepts draft
A draft issue is, semantically, exactly "proposed but not accepted."
Proposed solution
An opt-in, per-agent propose mode: the agent explores read-only, decomposes the work, and persists its task list as draft issues with rationale — executing nothing. A human reads the plan as ordinary issues, accepts or edits it, and execution is dispatched afterwards.
Minimal first slice:
a way for todo (or a sibling tool) to persist the current list as draft issues, with stable ids per item;
a per-agent setting that makes an agent propose rather than act;
linkage from each draft item back to the session/turn that produced it.
The tool's existing shape mostly carries over — the change is where the list lives and whether the agent proceeds.
Why this shape
Two-key safety. Propose (cheap, read-only, reviewable) → approve → execute (privileged). A proposing agent needs no write access at all, so the blast radius of a misbehaving plan is zero.
Relevant to the ACP permission default.buzz-acp defaults --permission-mode to bypassPermissions, which skips the per-tool-call permission flow. A propose-only agent doesn't need that flow, because it isn't acting. This is a way to get a reviewable checkpoint without adding blocking prompts to a chat UI.
Plans survive. Compaction, handoff, restart, and crash currently lose the list; _PostCompact exists precisely because that hurts.
The channel is the UI. No new panel surface required.
Open questions
Round-trip cost. This must be opt-in per agent — it would be wrong as a default, since many agents should just get on with it.
Who executes an accepted plan? The same agent in a second, privileged pass; a different agent; or a human. This proposal deliberately doesn't decide.
Issue volume. One issue per task could be noisy. An alternative is one draft issue per plan, with items as a checklist — probably the better v1.
Overlap with Configurable orchestration workflows (user-defined; agent + human-in-the-loop; progress + artifacts) #3871. Configurable orchestration workflows include per-run artifacts (plans, diffs, summaries) that later steps read. That covers plans inside a workflow run; this covers an agent's own task list outside one. If the maintainers would rather these be one mechanism, that's a reasonable outcome — happy to fold this in.
Duplicate search
Searched open and closed issues for task-list persistence, ephemeral todos, and agent draft plans — none found. Closest related:
Proposal: agent task lists are per-process and ephemeral — let agents persist plans as draft issues
Motivation
buzz-dev-mcp'stodotool is how an agent decomposes work into steps. Its own module doc describes the storage:The surrounding machinery shows the list is treated as important:
_Stopreturns objection text if the agent tries to end a turn with open items._PostCompactre-injects the full list after context compaction/handoff.So Buzz already cares that an agent finishes what it planned. But the plan itself:
That last point is the one that motivates this proposal. Today an agent's intent only becomes visible through its effects.
What already exists that this could build on
Buzz already has the durable primitive:
buzz issues— NIP-34 issues (create/get/list/status)KIND_GIT_STATUS_DRAFT(1633) inbuzz-core'skind.rs, andbuzz issues statusacceptsdraftA
draftissue is, semantically, exactly "proposed but not accepted."Proposed solution
An opt-in, per-agent propose mode: the agent explores read-only, decomposes the work, and persists its task list as
draftissues with rationale — executing nothing. A human reads the plan as ordinary issues, accepts or edits it, and execution is dispatched afterwards.Minimal first slice:
todo(or a sibling tool) to persist the current list as draft issues, with stable ids per item;The tool's existing shape mostly carries over — the change is where the list lives and whether the agent proceeds.
Why this shape
buzz-acpdefaults--permission-modetobypassPermissions, which skips the per-tool-call permission flow. A propose-only agent doesn't need that flow, because it isn't acting. This is a way to get a reviewable checkpoint without adding blocking prompts to a chat UI._PostCompactexists precisely because that hurts.Open questions
Duplicate search
Searched open and closed issues for task-list persistence, ephemeral todos, and agent draft plans — none found. Closest related:
Happy to take direction on scope before writing any code.