Publish 6/5-7/17 meeting notes

meetings/2026-05-19.md

@@ -59,4 +59,4 @@ Madhavi mentioned ongoing research into how the Gemini and DevTools MCP servers
 
 - **@LucaButBoring**: Contact @SamMorrowDrums from GitHub to discuss the [Copilot use case](https://github.com/github/github-mcp-server/blob/main/pkg/github/copilot.go) as a potential adopter of the task abstraction.
 - **@vinoo999**: Submit a pull request to the Agents WG repo summarizing the consumer/coding/enterprise interaction pattern framework.
-- **Madhavi PDB**: Research event notifications and existing patterns in the Gemini and DevTools MCP servers, and document findings.
+- **@madhaviai**: Research event notifications and existing patterns in the Gemini and DevTools MCP servers, and document findings.

meetings/2026-06-05.md

@@ -0,0 +1,54 @@
+# 2026-06-05 Agents WG
+
+> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/1h8o9GyEFshMhIuTKm5n_O7ld6NuLgPfbQUkPgh-LOrw/edit)
+
+**Date:** June 5, 2026
+**Attendees:** Luca Chang, Caitie McCaffrey, Sriram Panyam, Thierry Damiba, Madhavi PDB
+
+## 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](https://modelcontextprotocol.io/seps/2133-extensions) 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](https://modelcontextprotocol.io/seps/2133-extensions): 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](https://github.com/modelcontextprotocol/experimental-ext-tasks), 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](https://github.com/modelcontextprotocol/conformance/pull/262) for tasks coverage now that it has been rebased on [#318](https://github.com/modelcontextprotocol/conformance/pull/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."

meetings/2026-06-19.md

@@ -0,0 +1,45 @@
+# 2026-06-19 Agents WG
+
+> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/1v3qY7dg760SR2ih-diWMzpB1uePOVc7YOQq3kpsVM8U/edit)
+
+**Date:** June 19, 2026
+**Attendees:** Luca Chang, Madhavi PDB, Sriram Panyam
+
+## Discussion
+
+The meeting focused on Madhavi's deep agent research document and how its patterns map onto MCP primitives. The group explored whether sub-agents can be modeled as MCP tools, debated the distinction between hierarchical skills and opaque agent boundaries, and discussed whether an "agent capability card" is necessary or whether existing tool descriptions suffice.
+
+### Research Framing and the Coupling Problem
+
+Luca noted he had reviewed [Madhavi's document](https://github.com/modelcontextprotocol/agents-wg/pull/20) and that it could be merged into the existing [agent use cases research](https://github.com/modelcontextprotocol/agents-wg/pull/10), though the framing would need reworking since the existing document describes use cases while Madhavi's focuses on system architecture. He raised a recurring challenge: the group tends to frame problems such that a particular solution (a first-class "agent" concept) is assumed to be the answer, rather than identifying precise gaps from which the solution would naturally follow. The deep agent system Madhavi described, Luca argued, suffers from high coupling — all components require knowledge of all other components for the design to cohere. A sub-agent only makes sense relative to its supervisor, and a supervisor only works with intimate knowledge of what its sub-agents do.
+
+Madhavi acknowledged the coupling concern and noted she had filtered out middleware and observability concerns to focus on core agent capabilities in production. She proposed that much of the necessary infrastructure may already exist in MCP primitives and that what is missing might be a metadata layer — an "agent capability card" — to wire the pieces together.
+
+### Sub-Agent Encapsulation via MCP Tools
+
+Luca presented two architectural options for expressing sub-agents today. First, multiple agents could be consolidated behind a single MCP server exposing the combined tool surface. Second, a main MCP server could expose one tool per sub-agent, with each sub-agent maintaining its own connection to a dedicated MCP server behind the scenes. In the second model, the supervisor sees only two tools (e.g., "GitHub agent" and "Atlassian agent"), while each sub-agent internally manages its own full tool set.
+
+Madhavi raised a concern about tool visibility: when the client LLM selects a sub-agent (say, the GitHub agent), subsequent turns should expose only the GitHub tool set, not the Atlassian tools. She described her production deep agent system where a supervisor LLM evaluates user context, delegates to the appropriate sub-agent, and the sub-agent operates exclusively with its own tools for the duration of that conversation thread.
+
+Luca argued that if sub-agents are properly encapsulated — each running its own LLM with its own MCP server connection — the tool visibility concern resolves itself, since the supervisor never sees the sub-agent's internal tools in the first place. Madhavi clarified that her desired pattern was different: on the first turn the supervisor identifies which sub-agent to invoke, but on subsequent turns the supervisor LLM directly calls the sub-agent's leaf tools rather than routing through the sub-agent abstraction repeatedly. This progressive inlining pattern introduced questions about multi-layer hierarchies: Sriram asked whether a grandparent agent would need direct knowledge of a grandchild's tools, or if each layer should interact only with its immediate children.
+
+### Hierarchical Skills vs. Opaque Agent Boundaries
+
+Sriram drew a parallel to the hierarchical skills working group, which uses index files for skill discovery in nested directories. Luca distinguished the two models: hierarchical skills imply that something traverses the hierarchy (an LLM progressively loads skills as needed), whereas a deep agent model presents an opaque surface — the supervisor does not traverse the sub-agent's internals. Madhavi added the key differentiator: sub-agents have their own LLMs at every level, making independent decisions rather than simply chaining skill contexts into a single agent's context window. This encapsulates per-provider complexity inside each agent rather than requiring the supervisor to progressively load provider semantics.
+
+### Communication Patterns and Capability Cards
+
+Sriram suggested framing the agent interactions as explicit communication patterns — sequential execution, parallel aggregation, and event injection — arguing this would produce a clearer design narrative than reasoning about agent hierarchies in the abstract. He noted these are the same patterns used in distributed systems generally and would help answer whether tools and tasks already provide sufficient primitives for sub-agent behavior.
+
+The group discussed out-of-band interactions such as user authentication: if a sub-agent needs user input, the supervisor handles communication back to the client rather than the sub-agent attempting direct contact. Sriram noted this aligns with the existing `input_required` semantics.
+
+Madhavi proposed that an agent capability card could scope tool visibility, provide model hints (e.g., routing reasoning tasks to specific LLMs), and manage output formatting requirements. Luca countered that the information in a capability card could equally live in tool descriptions, since the supervisor LLM consumes both in the same way. Sriram acknowledged the card would be more structured, though the information is equivalent.
+
+Luca reframed the question as one of generalizability: any metadata surfaced through a capability card must be useful to an arbitrary client (e.g., VS Code), not just the specific deep agent application under discussion. The test is what a generic client would need to change to leverage the metadata. Madhavi agreed and committed to building a sequence diagram and proof of concept to evaluate whether existing primitives suffice.
+
+## Follow-ups
+
+- **@madhaviai**: Create a sequence diagram illustrating supervisor/sub-agent/MCP server interactions, modeled after the [agent use cases document](https://github.com/modelcontextprotocol/agents-wg/pull/10).
+- **@madhaviai**: Build a proof of concept to evaluate whether existing MCP primitives can surface sub-agent tool sets to the client without modifying core client calls.
+- **@madhaviai**: Register GitHub MCP and additional MCP tools for testing agent orchestration patterns.
+- **@madhaviai**: Rework the research document into a gap-focused format consistent with the existing research documentation.

meetings/2026-06-26.md

@@ -0,0 +1,33 @@
+# 2026-06-26 Agents WG
+
+> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/1lkzw9DMEnYKzNALo_PQ_q5omJZLkrJksuEZ9_-8sSdk/edit)
+
+**Date:** June 26, 2026
+**Attendees:** Luca Chang, Thierry Damiba, Madhavi PDB, Spencer Reagan
+
+## Discussion
+
+The meeting was informal and light on agenda, serving primarily as a status check on tasks implementation and a brief proposal discussion.
+
+### Tasks Implementation Status
+
+Luca provided a status update on tasks. On versioning, he noted that the discussion with Peter on the extension versioning proposals remains pending. On implementation, the primary blocker is SDK readiness for the next spec version: the Go SDK may already support it, the C# SDK is close, but the Python and TypeScript SDKs do not yet. Luca reported he has been focused on implementing the new spec version within Bedrock AgentCore, specifically the gateway component.
+
+### URL Elicitation Scope
+
+Thierry raised a proposal to restrict URL elicitation exclusively to tasks, motivated by the general trend of moving actions toward tasks. Luca pushed back, noting that URL elicitation serves authentication use cases where low latency is critical and tasks are not yet viable. Since authentication flows need to issue a URL elicitation immediately upon detecting missing credentials, wrapping them in a task would add unnecessary overhead. Thierry acknowledged the validity of this use case, and the proposal was shelved.
+
+### July Spec Changes and the Tasks Extension
+
+Spencer asked about the July specification's impact on tasks. Luca confirmed two key changes: the `2025-11-25` version of tasks is being removed from the core specification, and a revised version is being rebuilt as an extension with its own [specification](https://github.com/modelcontextprotocol/experimental-ext-tasks) already available for review. Spencer committed to reviewing the new extension spec.
+
+Madhavi asked about the current experimental status of an agents extension. Luca clarified that the working group oversees the tasks extension but does not currently have a separate agents extension; one could be established once the boundaries of the use case are clearly defined.
+
+### Stateless Operations and Elicitation
+
+Spencer noted that while the shift to stateless operations ([SEP-2575](https://modelcontextprotocol.io/seps/2575-stateless-mcp)) initially concerned him, the stateless structure actually simplified some workflows for his team. Luca clarified that while the message-level operations for elicitation remain largely unchanged, the transport-level operations have been entirely reworked, which affects how elicitation, sampling, and roots function.
+
+## Follow-ups
+
+- **@LucaButBoring**: Check with @CaitieM20 on whether next week's meeting (July 4 weekend) will be canceled.
+- **Spencer Reagan**: Review the new [tasks extension specification](https://github.com/modelcontextprotocol/experimental-ext-tasks).