The agent task list

While DataMind Oda works through a task with several steps, it keeps a task list: one item per concrete step, marked as the work moves. This page covers the tool behind the list: how an update works, the states an item can carry, who owns the list, and the messages an update can return. The visible side, the card and the plan in the chat, is on Oda's to-do list.

How an update works

• Every update sends the whole list. Oda submits the entire list every time, and it replaces the previous one. There are no partial updates and no per-item edits: to change one item, Oda sends the complete list again with that item changed; to drop an item, it sends the list without it.
• An item is its text and its state. Each item carries a short line naming the task, plus one of the three states below. Nothing else travels with it: there is no id, no priority and no other per-item field.
• The text is cleaned first. Oda trims the text of each item before recording it.
• Empty and repeated text are refused. An item whose text is empty once trimmed, or a list that names the same task text twice, is refused, and nothing is recorded.
• The latest update is the list. The list lives in the chat's record, and the most recent update is the list that counts, including after the chat is reopened.
• A single-step task may get no list. The list is for multi-step work; a task with one obvious step can run without one.

The three states

Every item carries one of the three. The same states appear on the card in the chat, under Pending, In progress and Completed; Oda's to-do list covers how the card reads them.

One active task, or several

• How many items may be in progress at once depends on how DataMind Oda is set up. Some setups allow several at once, for example when concurrent subagents or background commands run in parallel; others keep the list to one active task at a time.
• With the one-active rule on, an update that marks two items as in progress is refused with Error: invalid todos: at most one task may be in_progress (got <n>), and nothing is recorded.
• The rule is checked when an update is sent; a chat whose list was recorded earlier keeps it as it is.

Where the list lives

• One chat, one list. The list belongs to the chat that recorded it. Nothing is shared between chats, and a subagent keeps its own list.
• It stays with the chat. The list survives across turns and reopened chats: close the chat, open it again, and the latest list is still there.
• It needs a chat to record into. An update from a run with no chat behind it is refused with Error: todo_write requires an owning agent session before anything is written.

What the chat shows

• Every recorded update leaves an Update to-do list card in the chat, holding the list that was sent.
• While the work runs, the chat shows the current plan from the list. When the next turn starts, the standing plan clears; after a turn ends, the finished checklist stays visible.
• The card's full reading, including what each update changed, is on Oda's to-do list. For the chat around it, see Chat with Oda.

Messages an update can return

A recorded update answers with the counts of the whole list. A refusal arrives with an Error: prefix and leaves the list as it was.

Questions, answered

Does every update send the whole list?

Yes. Each update sends the entire list and replaces the previous one: there are no partial updates and no per-item edits. To record one change, Oda sends the complete list again; to drop an item, it sends the list without it.

What are the three task states?

pending (not started), in_progress (being worked on now) and completed (finished). Every item carries one of them, and each update states the state of every item in the list.

Why was an update refused for having two tasks in progress?

The one-active rule is on in your setup: at most one item may be in progress at a time. An update that marks two is refused with Error: invalid todos: at most one task may be in_progress (got <n>), and nothing is recorded.

Why was an item with empty text refused?

Oda trims each item's text first. When nothing is left, the item is refused with Error: invalid todo: `content` must be a non-empty string.

Why did two identical tasks fail?

Every task text must be unique inside one list. A repeated text is refused with Error: invalid todos: duplicate content "<content>".

Does the task list survive closing and reopening a chat?

Yes. The list stays with the chat's record and survives across turns and reopened chats; the most recent update is the list that counts.

Do subagents share the task list?

No. The list belongs to the chat that recorded it: a subagent keeps its own list, and nothing is shared between chats or agents.

What do the counts in the update's answer mean?

They describe the whole list after the update: how many items are pending, how many are in progress and how many are completed, in the form Updated todo list: <n> pending, <n> in progress, <n> completed.

When does the plan clear from the chat?

While the work runs, the chat shows the current plan. When the next turn starts, the standing plan clears; after a turn ends, the finished checklist stays visible.

Can a task carry an id or a priority?

No. An item is its text and its state, and an update replaces the whole list, so items carry no id, no priority and no other per-item field.