Subtasks, agents, and finishing work

How do agents break down work?

Subtasks are not a checklist field on the parent. They are full, independent cards, indistinguishable from any other card except that they carry a parentId pointing at the card that spawned them.

• You never create a subtask by hand. There is no "add subtask" button anywhere on the board or the detail page. Subtasks only come into existence when an agent working the parent card calls its "Create subcards" tool during a run, and that exact step is logged in the parent's Technical details tab.
• Each subtask is a full card of its own, with its own id, its own place on the Kanban board (in whichever column matches its own status, since it is not nested visually on the board itself), its own status, and its own detail page.
• On the board, a parent carrying children shows a small "N/M" chip (tree icon) summarizing how many subtasks are done; a subtask card shows a ↳ {PARENT-ID} chip identifying its parent.
• On the parent's detail page, the "Plan" section lists every child as a clickable row with its live status.
• On a subtask's own detail page, the experience is intentionally minimal: the breadcrumb chip links back to the parent, and only the Activity tab exists. There is no Conversation, no Technical details, no Artifacts tab, no Pull Requests sidebar section, no Open Local Environment button, no remote control or follow controls, and no Card review or Human input panels. Those all live on the parent, where the agent's actual work and any human decisions happen; the subtask is a tracked unit of that work, not a second place to interact with the agent.
• In List view, a subtask nests under its parent when they share a status group, or stands alone (marked ↳ {parent title}) when they do not.

How do I see which agent is doing what?

The platform presents itself as a single agent identity, ACE. You will not see a roster of differently-named or differently-avatared agents claiming individual cards the way you might on a human team board. What you do get, at increasing levels of detail:

• On the board card itself, the only "who's working this" signal is the run-state badge: a pulsing "In progress" pill, or (once a run is underway) a Queued / Running / Failed / Completed / Cancelled execution badge. If the card has a pending checkpoint instead, that replaces the execution badge; a card shows one signal at a time, never both.
• On the detail page, a Work run / Chat run badge next to the run status tells you whether the current run started from a direct dispatch or from a chat message (see The issue detail page).
• In the Conversation tab, every agent message is attributed to "ACE" with a timestamp: the human-readable narrative of what the agent told you.
• In the Technical details tab, you get the real breakdown: each run is its own collapsible "Agent run" block; inside it, an execution tree shows the orchestrator plus every sub-agent it spawned (labelled by role: Orchestrator, Triage, Planning, Implementation), each with its own tool-call count and token count, and, opened further, the individual turns, messages, and tool calls (with arguments and results) that agent made.
• Multiple runs on the same card (for example, after a "Request changes" rework cycle) show up as separate, separately-numbered "Agent run" blocks in Technical details, each with its own status pill (Working / Waiting for approval / Waiting for answers / Waiting for confirmation / Waiting for review / Completed / Closed / Failed).

Finishing, archiving, and history

A card is finished when it reaches Done. From there:

• If it was built in a scratch sandbox (no repository attached) and was not rejected, the Save & ship banner (see The issue detail page) pushes it into a real repository. It needs an active GitHub connection on the project and delivery:ship.
• Delete issue (sidebar button, with issue:delete) permanently removes the card and its history, with a confirmation step first.
• The board-level Archive issue control (hover menu on any card, or the dedicated hover button on Done-column cards) is present in the UI but has no effect today; deleting is currently the only way to clear a finished card off the board.
• At the project level, Archive and Unarchive work as expected: the archive icon in the project header toggles the whole project between active and archived (read-only). That is a project-wide action, separate from anything at the individual card level.

There is no separate "decision log" screen. The record of what happened lives in the Activity tab (project-wide) and each card's own Activity tab, both showing a day-grouped, attributed timeline of status changes, runs, comments, and resolutions. On the card itself, the permanent "Issue rejected" note and "Request changes history" panel capture the two decisions you are most likely to need to look back on.