Tasks & the agent lifecycle

For anything bigger than a one-shot answer, the agent works through a visible plan. The Tasks card turns a long run from a wall of streaming text into a checklist you can watch complete.

The Tasks card

When a job has multiple steps, the agent calls its update_tasks tool and a Tasks card appears in the transcript — one row per step, each with a status glyph:

• pending — not started yet,
• in progress — the row currently being worked,
• done — checked off.

The card is live: as the agent progresses it re-posts the full list and Mel updates the glyphs in place. Each newly finished step also prints a transcript line — ✓ Completed <task> (n/m) — so consecutive completions read 1/3, 2/3, 3/3. The input footer gains a ☰ n/m progress chip that counts up alongside.

The ordering matters, and it's deliberate: the agent reads and understands first, then writes the task list, then executes. You'll typically see a file read and a short diagnosis before the checklist appears — the plan is grounded in the code, not guessed from the prompt.

Anatomy of a long run

A substantial turn interleaves, in order:

1. Thinking (the collapsible Thoughts section) and short narration.
2. Read-side tool calls — read_file, grep, list_dir — to build context.
3. The Tasks card.
4. Execution: edits (each gated by an approval card unless autonomous) with diff cards, commands with live output.
5. Live check-offs as steps land.
6. A final answer plus the expandable usage summary.

How long can a run go?

A single turn can span up to 80 tool round-trips — enough for the agent to scaffold a project, install dependencies, build, hit an error, fix it, and build again, all from one prompt. A task that is still changing things carries on past that by itself. A command still running after 2 minutes is moved to the background rather than stopped, so a long npm install or cargo build finishes while the agent checks on it — see Background commands.

In-run compaction

Long runs generate a lot of tool output, and context windows are finite. Mel manages this automatically inside the run:

• A long tool result is trimmed, keeping the informative head and tail, and it says how much it left out and where to find the rest. A file the agent has just read is delivered whole.
• When the accumulated context approaches budget, older tool results are compacted in place — no extra model call, no pause — so the run keeps going instead of hitting the window.

This is separate from conversation-level compaction between turns, which is covered in Conversation management.

While it runs

The input stays live during a run — you can keep typing, and a message you send joins the run right away. To stop a run, use the stop button that replaces send while a turn is streaming. Stop means stop: the turn ends, a wait on a command ends at once, and Mel does not pick the task back up by itself. Background jobs keep running, and the Stop message says how many; each has its own Stop in the jobs list above the input. If the agent needs a decision (an approval, or a spawn confirmation during orchestration), the run blocks on the card until you answer — and Mel's notification bell flags blocked or completed agents in tabs you're not looking at.