arizuko › concepts › live progress

live progress

While a long task runs, the chat shows one temporary progress line. It appears where the answer will go, and arizuko deletes it when the task ends.

One line, where the answer will go

The line is posted in the place the answer will use. If the request already belongs to a thread, the line stays in that thread. The line never starts a thread of its own. The checklist is one message that changes in place:

⏳ ☑ Read the three log files
☐ Cross-check the timestamps
☐ Write the summary

A minute later, the same checklist message, edited:

⏳ ☑ Read the three log files
⏳ Cross-checking the timestamps
☐ Write the summary

The checklist uses three marks:

☑

Done.

⏳

In progress now. If the plan gives an in-progress wording, such as “Cross-checking the timestamps”, the line shows it. If not, the line shows the plain item text.

☐

Not started.

When the turn ends, arizuko deletes the line: Telegram, Discord, WhatsApp, Slack and the web chat all do so. Nothing of the progress stays above the answer. A channel that cannot both edit and delete shows no progress line.

A hook posts the plan, not the model

The agent plans with the TodoWrite tool. A hook of the harness renders each change of the list into the same editable checklist. A <status> block updates the line for work that has no task list. After a long run with no report, the agent gets one reminder to say what the user gets next, and only where a line can show.

Later updates edit the first message

The first progress update sends the checklist, and every later update edits it. The stored message rows keep the identity of the checklist, so a restart of routd in the middle of a long turn does not lose it.

The chat shows that the agent is busy until the turn ends

The channel also shows that the agent is busy. Telegram, Discord and WhatsApp use their own typing indicator. Slack and GitHub have no such indicator, so they put an eyes reaction, 👀, on the message that started the turn. The indicator stays on until the turn ends, not until the first reply. So an agent that answers and then continues to work still looks busy. If the adapter restarts during the turn, the reaction stays: the adapter records it and removes it when the turn ends.

Channels that cannot edit and delete show only the answer

GitHub cannot edit the comments of the agent here, so a pull request gets no progress comment. The eyes reaction on the comment that started the turn is the whole display.

Email cannot edit a sent message. On these channels, arizuko drops the status updates, and you get only the answer. A stream of separate “still working” posts is what the checklist exists to avoid, so these channels get no fallback. Google Drive comments behave the same way, because the Drive adapter does not edit its replies.

An edit failure appears as an error. routd never posts a replacement message to hide it.

The checklist never counts as the answer

The checklist promises an answer, and it is not that answer. The agent delivers the answer with an explicit tool, such as reply. The terminal text of the agent stays in its transcript. If an addressed turn, or a turn that reported work, ends without a delivery, the agent gets one prompt. If the agent stays silent, a failure notice arrives in the same thread.

Short plans and turns without a plan send no checklist

• A plan with one step sends no checklist, because a one-item list is noise. A plan with two or more items gets a live message.
• An agent that answers without a plan sends no checklist. Short turns do not need a plan and do not make one.

A simple reply needs neither a summary nor a checklist.

The code that renders the checklist

The hook that renders the list is in [ant/src/todo-status.ts]. The code that creates or edits the message, and the end-of-turn mark, are in [routd/progress.go]. retries explains what happens when the turn stops before it finishes the list.