What an AI agent needs to resume a project between sessions

MarQ · 2026-11-08

Every new session of an AI agent starts with no memory. To resume a project well it needs structured state it can read in a few calls: what exists, where each task stands, what changed since last time, what decisions were made and what it still has leased. A summary written in a chat is the opposite: it goes stale, leaves out whatever its author did not think was important, and forces the agent to trust it without being able to check.

The problem with summaries

When a session ends it is tempting to ask "summarize this for next time" and paste the text at the start of the next one. It works at first and fails for three reasons:

  • It is an old photo. If something changed between sessions (another person, another agent), the summary lies without knowing it.
  • It loses what did not fit. A summary decides what matters at the moment it is written. The decision made three sessions ago, or the risk someone noted, tends to fall out.
  • It cannot be verified. The agent has to believe the text. With structured state, it can ask the system.

The alternative is for the source of truth to be the board, not the chat, and for the agent to query it when it starts.

Getting oriented without spending context

Reading the whole project at the start is expensive: it fills the context window with tasks that do not matter today. MarQ offers reads designed to go from less to more:

  1. pm_get_project_tree: a compact overview of the project. Metadata, task counts by status and by priority, a requirements summary, tags and a first page of tasks in compact form (no notes or history). With limit: 0 it returns only the summary.
  2. pm_list_tasks: detail through filters, with pagination. You can filter by status, priority, assignee, tags, requirements or text, and sort by priority or by last modification.
  3. pm_get_task: the detail of a single task, for the ones that are actually in play.

The order matters: summary first, then filters, and detail only for what is about to be touched. It is the rule the MarQ skill follows when you ask for marq status.

What changed since last time

The most useful question when resuming is not "what is there?" but "what has changed since I left?". pm_list_tasks accepts updatedSince with an ISO date and sort: updated, so the agent can ask only for the tasks modified since its last session, most recent first. To learn why something changed, pm_get_task_timeline returns the task's history with the author of each change, the previous and new value, and how long it spent in each status.

Where to write down what matters

What is not written on the board is lost when the session closes. These are the places worth leaving a trace:

  • Notes by category on each task: risk, architecture (a design decision), prerequisite (something that must come first) and future_idea or general. They are added with pm_add_future_note and read with pm_get_future_notes. An architecture decision noted today keeps another session from reopening it a month from now.
  • Blockers with a cause: pm_report_blocker marks the task as blocked and records the reason.
  • Status changes with a comment: pm_update_task_status accepts a comment. "Moved to review: the offline case still needs testing" is worth more than a silent change.
  • Time spent: pm_log_time_spent, so metrics reflect real effort.

And a hygiene rule the skill enforces: MarQ must reflect reality, not intentions. A task does not become done without evidence (a commit, a passing test, a person's confirmation).

Picking up what you left half done

If you work with leases between agents, an interrupted session may leave tasks leased. At the start, pm_list_my_task_locks lists the leases the agent has open. It can renew them if it will keep working on them or release them if not, instead of letting them expire and block everyone else for the rest of the deadline.

A startup sequence

A reasonable script for the first minute of a session:

  1. pm_get_project_tree to get oriented.
  2. pm_list_my_task_locks to see what was left leased.
  3. pm_list_tasks with updatedSince to see what changed.
  4. pm_list_tasks with available: true to see what can be leased now (no active lease, neither done nor blocked, dependencies met).
  5. pm_get_task and, if needed, pm_get_task_timeline only for the chosen task.

It does not need to paste anything from the previous chat. To see what this state looks like, open the read-only demo; to connect your agent, follow the installation guide.

Blog