Continue the Agent Conversation or Start a New Task?

Continue an agent conversation when the goal is the same and the next request refines its current work. Start a separate task when the goal, deliverable, or working boundary changes enough to deserve independent ownership. If the previous task's state is unclear, establish that state before asking for another change.

Conversation length alone is a poor decision rule. A long conversation may contain the exact constraint a small follow-up needs. A short conversation may already be the wrong place for an unrelated feature. Ask what the next request must accomplish and which previous facts it actually depends on.

The three scenarios below are fictional. Their files, task identifiers, and outputs are invented teaching examples. They show how to frame the next request; no task has been created or changed by the examples.

Make the decision about the work

Use these questions before choosing where to send a request:

This is a practical editorial decision rule, not a promise about a particular agent product. Anthropic's context engineering article describes context as including instructions, tools, external material, and message history, and argues for selecting relevant information deliberately. Starting another conversation changes only part of that broader situation.

Scenario 1: The same goal needs one correction

Situation. Task T18 is updating the empty-state text in a fictional work-list interface. The draft changes the message in ui/EmptyList.tsx. You notice that “Create your first item” is inappropriate when a filter hides existing items. The goal remains helping the user understand an empty list.

Choice: continue the current task. The new request corrects the meaning of the existing deliverable. It needs the original distinction between a genuinely empty workspace and an empty filtered result. Splitting it into another independently running task could create two owners for the same component.

Send this follow-up:

Continue T18's empty-state copy change in ui/EmptyList.tsx.

The goal is still to explain why the list is empty. Refine the draft so
these states use different messages:

- No items exist: "No items yet. Create an item to get started."
- Applied filters match no items: "No items match these filters. Try
  changing or clearing the filters."

Use the existing state distinction if the component already has one.
If it does not, identify the missing information before adding logic.
Keep this within T18's file ownership and existing delivery boundary.

Return the revised diff and the checks actually performed. Do not mark
the copy as published merely because the local file has changed.

The follow-up restates the correction without restarting the entire design discussion. It also avoids an implementation guess: perhaps the component already receives a filtered-state flag, or perhaps it cannot distinguish the two conditions yet. That question belongs to the current task's source inspection.

If a teammate is already editing the component, continuation still requires coordination. Keeping a conversation does not resolve conflicting file ownership by itself.

Scenario 2: A different goal deserves its own task

Situation. T18's empty-state draft has been delivered. You now want a CSV export of the work list, with filtering and permission rules. The interface is related, but the outcome has changed from explaining a state to delivering a file.

Choice: start a separate task. CSV export has its own acceptance criteria, data handling, and implementation questions. The copy conversation's incidental history should not silently define those decisions.

Here is a complete brief for the new work:

# New task: Investigate filtered work-list export

## Goal

Determine the smallest appropriate design for exporting the applied-filter
result across pages as CSV for a permitted workspace member.

## Relevant context

The list has an existing distinction between no items and no filter
matches. T18 handled wording for that distinction. Its copy work does
not establish export semantics, permissions, or implementation readiness.

Read the current list query, applied-filter representation, and permission
checks. Verify the relevant paths in the selected repository before work.
Do not assume the previous conversation's file locations remain current.

## Acceptance questions to resolve

- Which rows belong to an export, including rows on other pages?
- When are filter values and row data captured?
- Which columns are required?
- What happens with no results or a permission change?
- Which size limit and completion behavior are appropriate?

## First deliverable

A source-linked investigation and proposed implementation plan. Separate
confirmed behavior from open product decisions. Identify files that would
change and any overlap with active work on the list interface.

## Work boundary

Investigation only. Do not modify files, create services, export live
workspace data, open a pull request, or deploy in this first step.
Implementation will be a separately scoped next action after review.

The brief includes only the piece of T18 relevant to the new task. It does not carry every abandoned wording suggestion. It also avoids treating a prior task's permission to edit copy as permission to create an export service.

A separate conversation is useful here because its goal and first deliverable can be judged independently. It is not useful merely because it gives the interface a cleaner appearance.

Scenario 3: The previous state is unknown

Situation. An agent was working on an export change. The last message says “updated the selector,” but you cannot tell which files changed, whether another task owns the same files, or whether anything was committed or deployed. Your next thought is “add a download button.”

Choice: clarify the existing state first. Starting a new implementation task now could duplicate unfinished work. Continuing with “add the button” could also build on a change that exists only in a summary.

Send this state-check request to the existing task:

Before doing more export work, establish the current task state.

The last message said the selector was updated, but I do not yet have a
verified inventory of the deliverable. Inspect the current working state
and report:

1. The original goal and which part is complete, pending, or unknown.
2. Actual changed files and the revision or working directory they belong to.
3. Checks that ran, their results, and the corresponding evidence.
4. Commit, merge, and deployment status separately. Unknown stays unknown.
5. Any other active owner or overlapping change you can establish.

This is a state check only. Do not add a button, repeat implementation,
commit, revert, publish, or deploy. Recommend whether the next UI change
belongs to this task or should be separately scoped once the state is clear.

This request settles a prerequisite to the continue-or-new decision. It does not require rebuilding a complete interrupted-task handoff. You need enough verified state to know whether the next objective extends the current work or starts another deliverable.

If the original task is unavailable, a separately bounded investigation may be necessary. Give it the same narrow purpose: inspect artifacts and establish state. An unavailable conversation does not make its unfinished edits safe to replace.

A new task is not a memory reset

A new conversation may still receive account-level instructions, project guidance, retrieved documents, or other supplied context. It can also operate on the same files and use the same external accounts. “New” does not establish an empty memory, a clean working tree, or fresh permission.

For ordinary development, decide what context should be retained instead of asking the agent to forget everything. Preserve the current goal, constraints, authoritative artifacts, unresolved decisions, and working boundary. Leave out stale guesses and unrelated history.

When a task specifically requires a first-contact or blind evaluation, verify the host's actual isolation controls. A request to ignore earlier messages is not evidence that those messages or external memories are absent. The task-selection rule in this article does not replace that separate evaluation setup.

Reuse this small context-selection template

Intended outcome:
[The result this request must produce.]

Relationship to previous work:
[Same goal with a correction / new deliverable / state not yet established.]

Facts to carry forward:
[Verified constraints, current artifact paths, and decisions still in force.]

Facts to verify again:
[Working revision, ownership, mutable configuration, or unresolved status.]

Next action:
[One concrete deliverable and its completion condition.]

Permission boundary:
[What this step may change and where it must stop.]

Continue when the next request belongs to the same outcome. Separate work that needs its own goal and delivery boundary. Establish uncertain state before choosing either route, so the next instruction has a real starting point.