Problem

Clients need to follow up or refine previously created tasks by agents.

Proposal

Option 1: Restartable Tasks

Agents allow tasks to restart processing from terminal states (Completed, Failed and Cancelled).

This option focuses on reusing existing tasks by restarting them when a follow-up or refinement is requested. This simplifies agent development by maintaining local context and referencing previous tasks directly. However, it introduces complexities with parallel follow-ups, task immutability, and bookkeeping. It can also lead to inconsistencies between the client and agent's view of task history and requires the agent to manage refined artifacts and inputs.

Option 2: New Task in same contextId (Preferred)

Context can be thought of as a larger goal from a client perspective. Clients can use the same contextId from the previous task and send a message for refinement or followup. Agents should spawn up new tasks. Tasks cannot restart processing from terminal states (Completed, Failed and Cancelled).

This approach favors creating new tasks for each follow-up or refinement while using the same contextId. This simplifies implementation for agents, enables parallel processing, and maintains task immutability. Clients can keep references to tasks with their state, artifacts, and messages. However, agents need to implement a strategy to infer previous tasks based on the contextId and handle potential ambiguities.

Other Aspects

Task Referencing

• App-to-Agent: Agents infer the previous task based on the contextId. They may use strategies like RAG (Retrieval-Augmented Generation) to retrieve relevant tasks, messages, and artifacts.
• Agent-to-Agent: Clients can optionally provide referenceTaskIds in the Message object to explicitly reference previous tasks. This acts as a hint to the serving agent.

Artifact Referencing

• Agents are expected to infer the relevant artifacts based on the referred tasks. Since agents possess a deeper understanding of the tasks they have created, they are better positioned to identify the appropriate artifact for a given user message.
• In case of ambiguity about which artifact should be used for the follow-up or refinement, the agent will ask for input using input-required. Clients can then pass on the artifact inputs as Parts in the message.
• To preserve explicit linkage between inputs and previously generated artifacts, clients can optionally populate referenceArtifactId in the part's metadata.

Artifact Mutation Tracking

• A follow-up or refinement task may lead to the modification of older artifacts and the generation of new ones. While tracking all mutations of an artifact might be useful, the client is best suited to determine what constitutes the "latest" or intended artifact to be refined. The client ultimately decides what the result is and can reject the mutation.
• Therefore, the serving agent can choose their methodology to maintain consistency in artifact identification. Eg. it can keep the same artifact-name when generating a refinement on the original artifact.
• In case of ambiguity or if the context is not sufficient, the agent will utilize input-required to explicitly request the client to specify which artifact to work with.

Proposed API Change

• Addition of optional referenceTaskIds field in the Message object.
• Optional addition of referenceArtifactId in part metadata of Message object.