The Development Board
Every piece of work in ACE moves through the same lifecycle on the Development Board. It does not matter whether you opened the ticket yourself, asked for it in Chat, or an agent opened it from an incident, a pull request, or a deployment. It all becomes a card on one Kanban board, and the board is where agents do the work and where they stop to ask you things.
The five columns
The board has exactly five columns, always in this order:
| Column | Meaning |
|---|---|
| Backlog | Captured work. Ideas and triaged issues, not yet queued. |
| Todo | Ready to start. Queued for an agent (or a person) to pick up. |
| In Progress | An agent is planning or implementing right now. |
| Review | Human checkpoint. Waiting on your decision. |
| Done | Finished work. |
There are no other statuses, and there is no priority field. The columns are the status model.
Two things are worth understanding about how a card travels:
- Moving a card into In Progress dispatches it. It is not a bookkeeping move. It starts a real agent run.
- You do not move cards into Review or Done yourself. Those transitions happen through the checkpoint flow below, or automatically as a run finishes. Once a card is In Progress or in Review, its position is owned by the live run, not by you.
The same lock applies to the card's text. A card's request can be edited while it sits in Backlog. Once it leaves Backlog, that request is frozen, so the agent and the record agree on what was asked.
How agents break work down
Agents split large work into subtasks, and a subtask is a full card of its own: its own id, its own status, its own place on the board. You never create one by hand. They appear when an agent working the parent card decides to create them.
The parent card is where the actual interaction happens. It carries the conversation, the execution details, and any decision you are asked to make. A subtask is a tracked unit of that work, not a second place to talk to the agent.
Checkpoints: when a run pauses for you
A Checkpoint is the card's own gate, raised by the run itself. It moves the card into Review and comes in three types: Approval, Questions, and Confirmation.
- Approval: the agent finished a chunk of work and wants your sign-off. It shows a summary and, when relevant, the file changes it made.
- Questions: the agent needs clarification before it can continue. It asks real questions as fields (free text, single choice, multiple choice) and waits for you to submit answers.
- Confirmation: the agent is about to do something costly or hard to undo, such as deploying, merging, or deleting, and wants an explicit go or no-go.
If you do not have approval access, you still see what is being asked. The action buttons are replaced with a read-only note.
"Input needed": a parallel mechanism
Alongside checkpoints there is a second, separate interruption system labelled Input needed. It is not tied to the card's run engine. It comes from a broader human-in-the-loop interaction list, filtered down to the card you are looking at.
It comes in two kinds: an Approval (a description plus a row of buttons the agent defined) and a Form (the same style of questions a Checkpoint can ask).
A Checkpoint and an Input needed request are distinct things, and both can appear on the same Review-column card at the same time. They are shown in their own labelled sections, so read both before deciding.
Your three answers: approve, request changes, reject
Whenever a checkpoint is waiting, you have three ways out, and the difference between the last two matters:
- Approve: the run continues.
- Request changes: the card goes back to In Progress for another attempt. You must say what needs to change, and that feedback is kept in a request-changes history on the card. This is rework, not a cancel.
- Reject: the terminal option. It cancels the active run and any pending checkpoint with no rework attempt, moves the card straight to Done, and marks it rejected. An optional reason is recorded.
Reject cannot be undone. If you want the agent to try again, use Request changes. Reject is for work that should not continue at all.
There is also Stop, for when you do not want to wait for the agent to reach a checkpoint on its own. Stop halts the live run immediately, returns any in-flight subtask to Todo, and forces the card into Review with a fresh checkpoint. From there you choose to approve and resume, request changes, or reject.
What comes out of it
A card is finished when it reaches Done. Along the way, pull requests linked to the card are listed on it, so you can jump from the work item to the code review. The record of what happened stays on the card: its activity timeline, its request-changes history, and, if it was rejected, a permanent note explaining that.