Before Giving an Agent a Kanban Board, First Figure Out Who Is Dragging the Cards
Kanban boards suit human collaboration because complex topology is hidden in human brains. Loop Agents need to make these relationships explicit, and cards quickly become insufficient. Gongye Ju proposes using MCDT to organize Agent/Session collaboration, with Humans only as Input/Output nodes; observability should also shift from process metrics to key fact nodes.
Kanban often feels awkward in Agent scenarios.
In a tweet, Gongye Ju offered a judgment: kanban is not suitable for Agents, especially Loop Agents. Its expressive power is too weak; in essence, it is just a few Ordered Grouped Lists being shuffled around.
Kanban is a product of the past era of human collaboration. The complex topological relationship networks and large amounts of tacit knowledge behind tasks exist in human employees' heads. The kanban itself can be simple because it does not need to carry complex relationships.
Agent work requires making tacit knowledge explicit. Once unfolded, these relationships exceed the expressive power of kanban, and also exceed humans' tracking ability.
Jiayuan (JY) Zhang once asked: What if your codex/claude code has a kanban board? In the image, the kanban is very neat, divided into Backlog, Todo, In Progress; cards have numbers, owners, and update times. The question in the comments is more direct: who is responsible for dragging cards to done, a human or an Agent.
Some commenters said the kanban is only useful if the Agent updates it itself; if a human still has to drag cards, the human becomes an intern's project manager. Another reply is more specific: the card says it's halfway done, but on disk there is only a half-broken diff; when the human comes back, they have to re-figure it out. The kanban needs to connect to replayable checkpoints; adding a To Do column won't solve it.
Gongye Ju's solution is MCDT (Montone Co-Design Theory). It provides the ability to characterize optimization strategies for monotonicity and computability of Requirement/Functionality relationships in the network structure formed between work units, and can be used in loop engineering as the internal structure for collaboration between Agents/Sessions.
In one sentence: MCDT in the loop, Human on the loop. Human is an Input/Output node in the MCDT network.
Humans define goals, what is wanted. Humans define acceptance criteria, what it is. Inside the loop, the system plans internal Todos from the current state toward the acceptance goals. Humans can decompose goals, distribute verifiable properties across multiple time stages, and fine-tune the execution path inside the Loop.
Monitoring a fixed set of kanban boards/Todos may not be very effective. They are dynamic, adjusting as goals change and facts unfold. Cursor/Codex/Claude-Code have all displayed related tasks, but as steering and coding proceed, they easily fail to match tasks.
Someone in the comments added another angle: a kanban used with an Agent is more like an interface between the human and the Agent. Humans define goals and acceptance criteria; cards at the result level are I/O nodes. The Agent's internal Todos do not all need to be put on the kanban.
The focus of building Agent observability should shift from process metrics to outcome metrics, centered on key fact nodes. Cards can remain, but don't expect a fixed checklist to fully describe what happens inside the Loop.
Reference links:
发布时间: 2026-11-01 22:28