[notes] Agents WG Meeting, November 4th, 2025

[LucaButBoring]

Agents WG Meeting Notes

Date: November 4, 2025
Attendees: Luca Chang, Che Liu, Peter Alexander, Shaun Smith, Mike Kistler, Kryspin Ziemski

Discussion

This week's Agents WG meeting continued work on #1686, focusing on feedback integration and emerging implementation challenges as the proposal moves toward the 11/25 spec release.

Task Message Association and Scope Questions

The group discussed whether task message association via relatedTask metadata should remain in scope for the initial release. While there was some agreement that message association could be treated as a separate concern, removing this metadata has broader implications for real-world usage patterns. The most significant concern centered on the input_required status: without message association, there's no clear mechanism to signal which requests are blocking a task from advancing. The group will need to come to a decision on this scoping question before the next meeting.

Related to this discussion, the group noted that input_required is mentioned throughout the proposal but hasn't been formally added to the list of statuses in the data model, which needs to be corrected.

Task Acceptance: Notifications vs. Responses

The question of whether task acceptance should use notifications or responses surfaced again, tying back to the broader concerns around message association and task lifetime management which are documented as a design decision in the SEP. This will be discussed further following this meeting.

SDK Implementation Philosophy and Automatic Opt-in

Following the Core Maintainers meeting from the previous Wednesday, the group discussed approaches to task augmentation in the reference SDKs. The TypeScript and Python implementations will automatically opt in to task augmentation when available, treating this as an opportunity to bolster adoption by making the feature accessible by default.

However, it was noted that the C# SDK takes a different philosophical stance, avoiding automatic behavior in favor of explicit developer control. The group agreed this is an acceptable divergence, and other SDKs will likely establish their own positions on this question. The Java SDK, for instance, follows a similar philosophy to C#.

Connection Management and Server-Side Termination

The group discussed practical challenges around connection management in sHTTP, as it relates to tasks. In most cases, implementations will want to avoid keeping a connection open while polling for task completion, but current SDKs don't provide support for proactively terminating a connection from the server side after e.g. a configurable timeout. An early-termination response pattern would be ideal for this use case, but the group agreed this is better suited for a future SEP rather than expanding the current scope.

Related to this, several features being cut from SEP-1686 will be reintroduced as separate SEPs following the 11/25 release, as there isn't sufficient time to develop them in parallel with the core tasks proposal.

Technically, the current MCP specification does allow for resumable server-side termination of SSE streams, but no SDK currently implements this capability. Attempting to use MCP in this way often results in errors when trying to write messages to the broken response stream.

Session Binding and Identity Challenges

A significant implementation challenge surfaced around session binding for tasks. The current reference implementation only supports task identification via task ID, with no mechanism to bind tasks to sessions or restrict users to viewing only their own tasks. While this was initially an implementation oversight, it also reflects ongoing friction around how MCP handles sessions and identity.

The planned implementation adjustment involves passing the transport session ID into task store methods as an optional parameter. Once #1442 lands, this approach will support both sHTTP and STDIO transports, though the initial implementation will only support session binding for sHTTP.

The group also discussed why session binding needs to be optional. Session binding has to be optional because sessions themselves are optional in MCP (STDIO also does not support them). However, this creates confusion because sessions and identity are poorly defined at the application level. The transport notion of a session is separate from the application notion of a session, and this ambiguity creates challenges for implementers.

The group suggested working with the Transports WG on this, if we can benefit from application-level session semantics for tasks. In the meantime, the proposal should include a clear statement about what session binding means for tasks, providing implementation guidance even in the absence of formal application-level session definitions in MCP.

Follow-ups

• DONE @LucaButBoring: Include input_required status in data models
• DONE @LucaButBoring: Come to a decision on if task association metadata should be in scope
• DONE @LucaButBoring: Clarify explicitly what session-binding looks like for tasks
• DONE @LucaButBoring: Clarify explicitly what it means for a request to be "associated with a task"
• DONE @LucaButBoring: Update reference implementations for latest SEP revisions
• DONE @pwwpche / @LucaButBoring: Meet to discuss notifications vs. responses in more detail

[evalstate]

@LucaButBoring - i want to add that we need to decide how the task state machine is associated with other protocol events (for example, does a related Sampling request automatically put the task in the input required state?).

My understanding was that they were decoupled - but think we should be crystal clear.

[LucaButBoring]

This should be covered in the current proposal, I think:

Input Required Status

1. When a receiver sends a request associated with a task (e.g., elicitation, sampling), the receiver MUST move the task to the input_required status.
2. The receiver MUST include the modelcontextprotocol.io/related-task metadata in the request to associate it with the task.
3. When the receiver receives all required responses, the task MAY transition out of input_required status (typically back to working).
4. If multiple related requests are pending, the task SHOULD remain in input_required status until all are resolved.

[evalstate]

Is it true in reverse though? For example, if a task is awaiting input - by email for example, we could be in input_required without having sent a request right?

[mikekistler]

What does it mean for a request to be "associated with a task"? Is this up to descretion of the server, or does it mean something specific? If it is at the descretion of the server, then how can this be a "MUST"?

[LucaButBoring]

Is it true in reverse though? For example, if a task is awaiting input - by email for example, we could be in input_required without having sent a request right?

This was focusing entirely on in-band message flows, but there are indeed valid use cases for using input_required yourself (such as that). Going to remove this requirement, as noted on the issue.

If it is at the descretion of the server, then how can this be a "MUST"?

It does need to be changed to a SHOULD, that's a good point.