2026-03-10 Agents WG

Raw Gemini-transcribed meeting notes and transcript available on Google Docs

Date: March 10, 2026 Attendees: Luca Chang, Peter Alexander, Che Liu, Nick Venezia, Christian Tzolov, Victor Lu

Discussion

Luca presented a summary of the task-related proposals under consideration for the June 2026 specification release. The proposals are closely related to the Transport WG's SEP-2322: Multi Round-Trip Requests (MRTR), which fully reworks the message flow to scale better for HTTP by minimizing implicit cross-request state.

Commitment to Stabilize Tasks by June

Peter raised the question of whether the goal of moving tasks to a non-experimental state in the June specification is a firm commitment or an aspiration. Luca confirmed that, based on discussions at the December Transport WG meeting, the understanding is that tasks should reach a stable state by June if at all possible. Peter pushed for this to be treated as a commitment rather than a hope, and the group agreed.

Che expressed concern about the timeline, noting that with only March through June remaining and the RFC approval process typically taking one to two months, the window is tight. Peter noted that the group realistically only has a few weeks to solidify the proposals, given the goal of having a release candidate next month. Luca acknowledged the constraints but emphasized focusing on the minimum and best possible changes rather than letting perfect be the enemy of the good, with the expectation that many uncertainties will be resolved at the 3/31 maintainer meeting (in-person). Che proposed a dedicated discussion session for tasks, which Peter and Luca agreed to pursue. Peter noted he would coordinate with Den, who is organizing the schedule for those meetings.

Existing Problems with Tasks

Luca walked through the existing problems with tasks that the proposals aim to solve, as documented in the companion document:

Cross-request capability negotiation: Tasks currently expose a secondary layer of capability negotiation via execution.taskSupport on tools, which requires clients to call tools/list first to prime state before calling any tools. This introduces implicit coupling between retrieving the tools list and calling tools that didn't previously exist.
input_required as an SSE side-channel transition point: In Streamable HTTP, when a client receives the input_required status, it must call tasks/result prematurely to give the server a deterministic opportunity to open an SSE stream for elicitation and sampling messages. This is awkward and difficult to implement correctly.
tasks/result as a blocking method: The contract of tasks/result is that it doesn't return until the entire operation is complete, which inherits the same problems that the overall system was meant to solve and complicates polling implementations.

Additionally, MRTR's execution model — where incomplete requests are returned to clients and retried with appended response messages — directly conflicts with the current task model. Tasks are intended to fill the implicit state gap left behind by MRTR for cases where restarting an entire request is unacceptable.

SEP-2229: Task Jumpscares

Luca presented SEP-2229, which addresses the cross-request capability negotiation problem. The proposal allows receivers to initiate a task independently of whether the requester explicitly asked for one, removing the need for the executionMode field and the associated state contract.

Under this proposal, all parties will be expected to understand how to receive and poll for a task, but will not be required to host tasks themselves (e.g., clients will not suddenly need to run elicitations as tasks). This simplifies the bootstrapping flow significantly. Luca noted that having implemented the current capability handling three times, the existing flow is a headache.

Nick expressed strong support for this change, noting that it directly addresses pain points encountered in real-world implementations involving telco gateway integrations (e.g., KYC verification through Telefonica) with varying response times and authentication mechanisms across different operators.

SEP-2339: Task Continuity

Luca presented SEP-2339, the most significant of the proposals. It introduces a new tasks/continue method and removes tasks/result entirely. Rather than the current flow where clients invoke a tool, poll tasks/get repeatedly, and eventually call tasks/result for a potential SSE stream, tasks/continue encapsulates the entire task state machine into a single method.

This means the server can send elicitation or sampling requests on the same method without the semantic awkwardness of the tasks/result jump. When the result is not yet ready, the server returns the current task status rather than blocking. When the result is ready, it is inlined into the Task object as a union type discriminated on the status, with errors handled similarly.

tasks/get will remain in the protocol for simple use cases such as UI elements that only need to display task status without handling server-to-client requests. Under MRTR, tasks/continue in the input_required state would trigger an incomplete-request rejection, making tasks/get the appropriate method for passive status queries.

In the event MRTR is rejected, tasks/continue would act as the vehicle for SSE side-channeling instead, much like tasks/result does today.

Peter suggested that Task Continuity and MRTR should be reviewed together, as Task Continuity is essentially built to support MRTR. Luca agreed and noted that Task Continuity is fully ready for review, while Task Jumpscares only needs the specific spec language to be drafted.

SEP-2268: Subtasks (Draft)

Luca briefly covered the Subtasks proposal, a draft that introduces receiver-controlled hierarchical breakdown of tasks with each subtask producing its own independent result. Since this proposal does not address any of the existing problems with tasks and is instead an expansion of task features, Luca expects it will likely be deferred.

Peter had previously provided feedback that a strict parent-child hierarchy may be too rigid for all use cases. Luca plans to take the proposal back to the drawing board to remove constraints and allow for more flexible composition, potentially supporting arbitrary graph shapes rather than assuming strict hierarchy and ordering.

Tasks are (not) Progress (Transports WG Draft)

Luca covered a Transports WG-owned draft that adds optional progress metadata (progress/progressTotal) to the Task schema, making progress explicitly queryable and reducing the need for SSE streams in common use cases. This is closely related to MRTR, which does not currently have a clear answer to notifications in general.

Peter questioned whether this is critical for moving tasks out of experimental status, suggesting it may be a nice-to-have improvement. Luca agreed that the two core proposals (Task Jumpscares and Task Continuity) are the critical ones, while Subtasks and Tasks are (not) Progress are secondary.

Implementation Feedback

Luca noted that he has implemented the proposals in the Strands Agents SDK (an AWS project) and in Kiro, but is not aware of anyone else who has implemented tasks end-to-end. Peter confirmed that Anthropic does not yet have task support on Claude. Che suggested reaching out to Caitie, as the VS Code and Microsoft teams tend to be early adopters. Che also noted that Google is not currently using tasks either.

Nick offered to share stable, working workflows involving MCP-based fraud checking and banking operations (SIM swap detection, device location verification, risk scoring) through telco integrations, which involve complex multi-step processes that map well onto the task model.

Timeline and MRTR Implementation

The group discussed the timeline for MRTR and related task changes. The plan is to attempt to accept the proposals, implement them, and iterate during a two-month period before the June spec release. Peter expressed concern that the timeline for starting implementation is short, particularly given that MRTR represents a massive change for SDKs. The 3/31 maintainer meeting is intended to align on final details, with implementation ideally starting by mid-to-end of April.

Follow-ups

@LucaButBoring: Write the spec language for SEP-2229: Task Jumpscares to make it ready for review.
@pja-ant: Review SEP-2229: Task Jumpscares and SEP-2339: Task Continuity and provide feedback.
@pwwpche: Coordinate with @localden to schedule a dedicated task discussion session at the 3/31 maintainer meeting.
@pja-ant: Run the next Agents WG meeting in two weeks (Luca will be out).
Nick Venezia: Share telco/banking workflow information with Luca via Discord.
@pwwpche: Reach out to @CaitieM20 about early adoption of tasks on the VS Code / Microsoft side.

9.6 KiB Raw Blame History