Agents WG Meeting Notes

Date: December 2, 2025
Attendees: Luca Chang, Peter Alexander, Victor Lu, John Baldo, Mike Kistler

Discussion

Tasks Update

The group briefly discussed the now-accepted Tasks proposal (#1686) from the 11/25 specification release. The current proposal doesn't currently appear likely to change in a significant breaking way when promoted from its experimental state. Minor breaking changes such as adding new Task statuses remain possible. Partial results could be a significant breaking change depending on how exactly they're proposed, which will need to be handled carefully.

SEP-1792: Add agencyHint Tool Annotation

The proposal (#1792) was introduced to the group, with discussion focusing on how agencyHint differs from existing annotations like openWorldHint and idempotentHint.

It was noted that this addresses a common concern: developers want to know if a tool will be "agentic" in order to apply governance policies and additional UX controls.

However, the use case still felt somewhat vague to some participants. The underlying need for a more complex set of indicators about the behaviors of tools may suggest that we need a more generalizable system for tool governance. Since hints cannot be easily consolidated if we end up with redundant ones, careful consideration is warranted before adding new ones.

For the time being, @LucaButBoring will work with the SEP author to finalize the proposal and raise it to the Core Maintainers for further discussion.

Issue #1917: Add Pending or Submitted Status to TaskStatus

This issue was raised for initial thoughts from the group. The group discussed a specific example of a task dispatched to a worker pool as a practical scenario where there could be a meaningful difference between "submitted" and "working" statuses.

A "submitted" status would be useful in that it would enable a more transactional execution model, where a task is only marked as "working" once a worker picks it up from a queue. However, it is still unclear how other systems would benefit from seeing this additional status. A "submitted" status was originally included in #1686, but was ultimately dropped as no client implementations were able to meaningfully benefit from it.

@LucaButBoring will follow up with the issue author to determine if there is a concrete use case that the new status would enable.

SEP-1904: Add Filtering Support for tasks/list

This proposal (#1904) was introduced with a note that it may fit better under the Primitive Grouping WG, as they're already planning to build filtering uniformly across the protocol on top of Groups.

Concerns were raised that this may be nontrivial for servers to support, considering both the range of filter operators and how filtering interacts with pagination, whereas it is very easy for clients to do this filtering themselves. This mirrors the same reasons tool filtering gets pushback.

Several members of the discussion wanted to see concrete evidence that the lack of filtering is a significant pain point for servers before supporting the proposal, as Tasks are still new and the full range of potential scaling challenges remains hypothetical.

SEP-1905: Task Result Streaming and Immediate Result Acceptance

This proposal (#1905) was introduced with a note that @LucaButBoring made a recommendation to split it into two separate SEPs: one for partial result streaming and one for polymorphic immediate results.

An alternative approach was suggested during the discussion to solve partial results at a general request level, and then to allow Tasks to simply inherit the same mechanism. The challenges associated with creating a schema for partial results are inherent to JSON-RPC.

It was also noted that A2A solves this for its Task primitive in its JSON-RPC protocol binding in a way that MCP could follow.

The idea of breaking out of the JSON-RPC envelope altogether was also raised, which would extend to binary streaming very well in the future, though that would be a much more radical change to the protocol and would likely face much more resistance.

Schedule Note

The next two meetings may be canceled due to holiday travel being expected to reduce attendance. A decision will be made on this within the next week.

Follow-ups

• SEP-1792: @LucaButBoring to summarize the feedback and relay it to the SEP author. Once other minor issues (such as the reference to the now-removed taskHint) are addressed and a PR is raised following the new SEP format, @LucaButBoring will raise this to the Core Maintainers for further review.
• Issue Add pending or submitted status to TaskStatus #1917: @LucaButBoring to relay feedback to the issue author.
• SEP-1904: @LucaButBoring to relay feedback to the SEP author.
• SEP-1905: @LucaButBoring to relay feedback to the SEP author.
• @LucaButBoring to decide whether or not to cancel the next two meeting occurrences.