Kanban

The trait that decides it is that there is no setup at all. One command from a repository root detects the agent you already installed and opens a board, with no account, no configuration file and nothing to provision. For evaluating whether parallel agents help you at all, that is the cheapest possible experiment.

What comes with that is a research preview's stability. Pick it to find out whether running four agents is useful for your work. Pick ccmanager when you have decided it is and want something steadier.

The dependency is the risk. Cards run unattended because the underlying agent's approval step is being bypassed, which means every write and every command executes without the confirmation the agent's own authors thought necessary. Runtime hooks used the same way can change behaviour across an upstream release without warning.

What it does right is the workspace. Each card gets an ephemeral checkout of its own, so parallel agents cannot collide and abandoning a task costs nothing but a directory.

1. Declaring that one task must follow another is a small feature with a real consequence: work that depends on an interface being written first stops being a race, and the graph is inspectable before anything runs. 2. Per-card checkpointing means an individual task can be rewound without touching its neighbours.

2. Nothing is measured. No completion rates, no comparison between chained and unchained runs, and no accounting of how often parallel agents produce work that later conflicts at merge time.

The sponsor already has an audience and a product, and this exists to make that audience more productive rather than to earn anything itself. That is a sound reason to expect continued investment while the parent's strategy holds, and no reason at all to expect a support commitment.

Moat: belongs to the parent, not to this. Likely path: absorbed into the main product as a feature once the preview stabilises, or quietly retired if the experiment does not convert. Position: adopt it as a free extension of a tool you already use, and expect it to change shape.

The board costs nothing and multiplies something that does not. Every card is a session against a per-developer subscription, so running four in parallel is four times the consumption on invoices that sit outside my control, and there is no aggregate view telling me that is happening.

It is also purely local, so there is no shared deployment to authenticate against and no central record of what was generated. Onboarding is a single command. Not yet: I want per-developer spend visibility before sixty people can start four agents each.

Worktrees are the correct primitive and using them per task is the right instinct: cheap to create, cheap to destroy, and native to the version control I already use, so nothing here invents a workspace concept I have to learn. Running from a package runner means trying it costs nothing and leaves nothing behind.

Permissive licence over a small codebase makes a fork realistic. What is absent is a protocol interface, so my servers are invisible and the agent inside each card is limited to its own tooling.