Skip to content

Proposal: agent task lists are per-process and ephemeral — let agents persist plans as draft issues #3923

Description

@RegardV

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.

What already exists that this could build on

Buzz already has the durable primitive:

  • buzz issues — NIP-34 issues (create/get/list/status)
  • 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:

Happy to take direction on scope before writing any code.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions