7.1 KiB
2026-06-05 Agents WG
Raw Gemini-transcribed meeting notes and transcript available on Google Docs
Date: June 5, 2026 Attendees: Luca Chang, Caitie McCaffrey, Sriram Panyam, Thierry Damiba, Madhavi Pasumarthi
Discussion
The meeting opened with an extended discussion on how agents, state, and memory relate to MCP, grounding the group's mental model before moving to conformance test scaling, extension versioning, and the official promotion of the tasks extension.
Agents as Messaging Patterns
Madhavi raised questions about how state management works in agentic tasks, specifically whether conversation history and session context should reside on the client or server side. Sriram and Luca clarified that tasks carry state bound to the task itself, not all agent state. Agent-level state (context windows, conversation history, compaction) remains an application-level architectural decision managed by the host, not something MCP prescribes.
The conversation broadened into what it means for an MCP server to "be" an agent. Caitie argued the distinction is largely marketing-driven rather than reflecting a fundamental protocol difference. Differentiating protocols based on the compute running behind them, she noted, would be like having a different protocol for static web apps than for a large microservice. The meaningful question is what messaging semantics the protocol needs to support for agentic behavior: true streaming responses, progress notifications, partial results, and steering. She noted the MCP docs were rewritten that week to frame the protocol around messaging patterns (request-response, subscription-notification, elicitation, long-term tasks, triggers) rather than lifecycle.
Caitie observed that most agentic frameworks are iterations of while loops over plans, tools, and context. Agent orchestration logic — handoffs, planning, routing — is the job of the agent loop, not MCP. MCP's role is defining how to pass context, state, and tools between components. She also drew an architectural distinction: the LLM recommends tool calls but does not execute them; the agent loop or harness does. This separation enables governance, progressive discovery, and tool search without depending on the LLM to enforce those constraints.
Memory Management Outside Core
Madhavi asked whether a memory extension (vector DB integration, persistent context) was planned. Luca said no current plans exist, though the group would investigate if protocol-mediated use cases emerged. Caitie took a stronger position: MCP is a wire protocol and will not embed memory management. If a new messaging pattern emerges that memory stores require, MCP would support that pattern, but the protocol would not dictate memory implementation. Sriram added that existing primitives — resources and tools — can already serve as memory access mechanisms today.
Conformance Test Scaling
Sriram demonstrated a conformance reporting tool he built independently of his SDK, capable of running against multiple conformance repositories and generating detailed pass/fail reports by SEP and suite. He expressed strong interest in contributing to conformance test maintenance.
Caitie noted the conformance team (Paul and Felix) is small and struggling to scale while heads-down on the upcoming release. She identified that they likely need a proper working group structure to accept more contributors and committed to raising the scaling question at the next maintainers meeting.
Extension Versioning
Luca reported that Peter left a comment on the versioning proposal arguing that SEP-2133 already covers extension versioning needs. Peter's position: capability negotiation is already scoped to a base protocol version, and minor/patch distinctions are redundant because non-breaking additions are mediated by per-extension settings and are backwards-compatible by definition.
Luca disagreed on one point: when the base protocol makes a breaking change that invalidates extension behavior. An extension specification is effectively a point-in-time snapshot of the base protocol it depends on. If a future spec release removes something an extension relies on (e.g. the subscription mechanism that tasks uses for notifications), the extension breaks with no way to signal that incompatibility.
Caitie saw merit in both positions. She suggested the group publish a semantic version for the extension spec regardless of whether it participates in protocol negotiation, since SDK maintainers need a way to indicate which features they support. She proposed working through the concrete case of integrating tasks and triggers as co-dependent extensions to test whether capability negotiation alone suffices. If a client supports tasks-as-today and triggers-as-today separately, the combination requires additional declarations beyond what either extension specifies independently. Luca agreed this creates a matrix quickly — either a new revision of one extension declares the combination as an optional setting, or a third extension must depend on both.
The group concluded that this does not need to be solved immediately for tasks to ship, but that concrete cases should be worked through. Caitie committed to commenting on the proposal with metadata and store use cases.
Tasks Extension Promoted to Official
Luca confirmed that David had approved dropping the experimental label from the tasks extension, citing SEP-2133: once an extension is accepted via a SEP, the experimental designation can be removed. Luca verified during the meeting that he had permission to rename the extension repository, and the rename was completed.
Regarding documentation, Sriram noted that enabling GitHub Pages on the repository would produce a default URL at modelcontextprotocol.github.io. Luca clarified that a custom URL (like MCP Apps has) requires organization admin privileges held by Den or David. Caitie confirmed she does not have org admin access but committed to requesting it at her next maintainer sync.
Caitie also identified that the docs navigation incorrectly references "MCP Tasks." The group agreed the branding should be simply "Tasks" since the MCP prefix is redundant — unlike "MCP Apps," which has established brand identity.
Follow-ups
- @CaitieM20: Re-review the conformance test PR for tasks coverage now that it has been rebased on #318.
- @CaitieM20: Raise conformance test scaling at the next maintainers meeting.
- @CaitieM20: Comment on the versioning proposal with concrete use cases for metadata in stores and clients.
- @CaitieM20: Request Den or David enable GitHub Pages and provision a custom URL for the tasks extension repo at the next maintainer sync.
- @CaitieM20: Fix documentation navigation to brand the extension as "Tasks" rather than "MCP Tasks."