> For the complete documentation index, see [llms.txt](https://tinyhumans.gitbook.io/openhuman/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://tinyhumans.gitbook.io/openhuman/features/goals-and-todos.md).

# Goals & Todos

Durable user goals and the agent's native TinyAgents work state.

## Long-term goals

OpenHuman keeps a short, human-readable list of durable user objectives in `MEMORY_GOALS.md`. The Intelligence → Goals panel supports adding, editing, and deleting entries, while the goals reflection agent can make small changes based on recent memory and conversations.

The list is deliberately bounded to keep it useful in prompts. Each entry has a stable short id so edits do not depend on ordering. The corresponding RPC surface is `openhuman.memory_goals_*`.

## Agent work state

While it works on a multi-step request the agent keeps a session todo list, the same shape Claude Code and Codex use: one `todo` tool call writes the whole list (`content` + `pending` / `in_progress` / `completed`), scoped to the agent session and held in memory for the life of the process. Thread goals are the per-thread completion contract (`goal_set` / `goal_get` / `goal_complete`).

Neither is a kanban board. There is no per-thread task board, no card CRUD, no approval gate, and no `thread_goals`, `todos`, or `threads_task_board` RPC endpoint. Conversation threads remain the chat/session container.

## In the chat pane

Both show above the composer while the agent works, read-only — the agent owns them, the pane reflects them:

* The **todo checklist** lists every step with its state: completed items strike through and stay, the one `in_progress` item is marked, and the header counts how many are done. It collapses to that header.
* The **goal banner** shows the objective, its status (active, paused, budget reached, complete) and tokens used against the budget when one was set.

Neither has an RPC of its own. Each tool call answers with its state as JSON, so the pane reads the newest `todo` / `goal_*` tool result in the thread — across the live turn and the thread's persisted turns, which is what keeps a goal on screen for the many turns after the one that set it.

## See also

* [Memory Tree](/openhuman/features/obsidian-wiki/memory-tree.md): what goal reflection reads from.