From 340268f3a436976b055e991f77cd4a4e09855f30 Mon Sep 17 00:00:00 2001 From: Luca Chang Date: Mon, 20 Jul 2026 13:46:54 -0700 Subject: [PATCH] Publish 6/5-7/17 meeting notes --- meetings/2026-05-19.md | 2 +- meetings/2026-06-05.md | 54 ++++++++++++++++++++++++++++++++++++++++++ meetings/2026-06-19.md | 45 +++++++++++++++++++++++++++++++++++ meetings/2026-06-26.md | 33 ++++++++++++++++++++++++++ meetings/2026-07-10.md | 30 +++++++++++++++++++++++ meetings/2026-07-17.md | 35 +++++++++++++++++++++++++++ 6 files changed, 198 insertions(+), 1 deletion(-) create mode 100644 meetings/2026-06-05.md create mode 100644 meetings/2026-06-19.md create mode 100644 meetings/2026-06-26.md create mode 100644 meetings/2026-07-10.md create mode 100644 meetings/2026-07-17.md diff --git a/meetings/2026-05-19.md b/meetings/2026-05-19.md index 771bb64..d1a544a 100644 --- a/meetings/2026-05-19.md +++ b/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. diff --git a/meetings/2026-06-05.md b/meetings/2026-06-05.md new file mode 100644 index 0000000..4101dd9 --- /dev/null +++ b/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." diff --git a/meetings/2026-06-19.md b/meetings/2026-06-19.md new file mode 100644 index 0000000..6f974f5 --- /dev/null +++ b/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. diff --git a/meetings/2026-06-26.md b/meetings/2026-06-26.md new file mode 100644 index 0000000..884c117 --- /dev/null +++ b/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). diff --git a/meetings/2026-07-10.md b/meetings/2026-07-10.md new file mode 100644 index 0000000..562606d --- /dev/null +++ b/meetings/2026-07-10.md @@ -0,0 +1,30 @@ +# 2026-07-10 Agents WG + +> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/11lst_-ThXzZx6f8_HVMn0FIvQ2_HCmOKm4DfvPRhrUQ/edit) + +**Date:** July 10, 2026 +**Attendees:** Luca Chang, Madhavi PDB, Thierry Damiba + +## Discussion + +With no formal agenda, Luca noted that most SDKs remain in finalization and that he has been occupied with AWS's requirements for handling the protocol upgrade. Madhavi presented a revised version of her [analysis comparing her team's agent platform to MCP](https://github.com/modelcontextprotocol/agents-wg/pull/20), building on discussions from two weeks prior. + +### Agent Capability Card Proposal + +Madhavi proposed adding an `agent/list` primitive to MCP that returns a registry of sub-agents and their high-level capability descriptions rather than a flat list of all available tools. Routing becomes two-phase: a supervisor LLM selects a sub-agent from summarized capability descriptions (three sub-agent descriptions instead of, say, 70 individual tool descriptions), then fetches only that sub-agent's full tool list for dispatch. She argued this reduces tool sprawl, improves routing accuracy, and decreases latency compared to presenting all tools simultaneously. + +The proposal generalizes her team's production architecture, which is built on the [Deep Agents](https://docs.langchain.com/oss/python/deepagents/overview) framework — a clarification that emerged mid-discussion, after the term had initially read as a generic architectural pattern. In that platform, the agent registry (a dictionary of sub-agent names mapped to capability descriptions), supervisor checkpoint threading, and sub-agent routing are existing features; the proposal aims to bring analogous routing semantics into MCP itself so that teams can use MCP as their agent layer without a separate orchestration framework like LangGraph or LangChain. + +### Redundancy with Existing MCP Constructs + +The bulk of the discussion turned on whether the primitive is functionally distinct from what MCP already provides. Luca's position was that existing surfaces can already carry the same information: each sub-agent can be modeled as a tool whose free-form description embeds its constituent tools' descriptions — structured schema being unnecessary when the only consumer is an LLM — and the `instructions` field on MCP servers (currently in the initialize result, moving to `server/discover` in the next spec version) provides additional routing context. Even the two-phase retrieval itself could be expressed as a `resolve_subagent_tools` tool on the server that holds the registry: since that server already contains all tool definitions locally, an `agent/list` primitive would replicate what a tools-based approach accomplishes without new protocol surface. + +Madhavi's counterargument was operational rather than semantic. Modeling sub-agents as tools backed by separate remote MCP servers introduces security, load-balancing, and infrastructure overhead that her enterprise has no appetite for; in her current system, all tool objects are already initiated in memory, and routing is achieved by selecting which subset of tools to expose to the LLM per thread rather than by making network calls to separate services. She also argued an explicit agent-level primitive would let clients prioritize agent routing over direct tool calls, improving response quality. The question of why this cannot be expressed with existing tool machinery was left open for the proof of concept to answer. + +### Toward a Proof of Concept + +Luca acknowledged the proposal had improved since prior discussions and identified what would make the case decidable: a side-by-side example showing what setting up sub-agent routing via MCP requires today versus with an agent capability primitive, combined with updated sequence diagrams, to concretely illustrate the gap between current and target state. Madhavi confirmed she is already working on an example and intends to add an agent capability card object to an MCP codebase locally as a proof of concept. + +## Follow-ups + +- **@madhaviai**: Build a side-by-side POC comparing the current MCP approach to the proposed agent capability card approach, with updated sequence diagrams; share intermediate progress with @LucaButBoring ahead of the next meeting. diff --git a/meetings/2026-07-17.md b/meetings/2026-07-17.md new file mode 100644 index 0000000..f5d135f --- /dev/null +++ b/meetings/2026-07-17.md @@ -0,0 +1,35 @@ +# 2026-07-17 Agents WG + +> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/1Roz7Y_VPLNKK_Kio-PBfE5keUgLDoT9hPEtI-LihIQs/edit) + +**Date:** July 17, 2026 +**Attendees:** Luca Chang, Madhavi PDB + +## Discussion + +The meeting continued the `agent/list` discussion from the previous week, with Madhavi presenting the production architecture her team migrated to and demonstrating observability traces to ground the technical conversation. + +### Deep Agent SDK and Production Context + +Madhavi demonstrated a trace from her SDLC system in Langfuse (an OpenTelemetry-based observability dashboard), which contains three sub-agents: release management, vulnerability scanning, and summarization. The trace showed the supervisor routing a complex query (checking failed pipelines, pending approvals, and generating insight charts) through multiple sub-agents with full span visibility of each handoff. A performance comparison highlighted the trade-off: the multi-agent flow with chart generation took several seconds, while a direct opaque MCP call answering a simpler question completed in 1.28 seconds. Madhavi noted the Deep Agents framework is most justified when tool counts exceed 50-60, where bucketing into sub-agents improves routing accuracy. + +### OpenTelemetry Trace Context in MCP + +Luca noted that the upcoming `2026-07-28` protocol version adds `traceparent`, `tracestate`, and `baggage` fields in `_meta` for OpenTelemetry trace context propagation ([SEP-414](https://modelcontextprotocol.io/seps/414-request-meta)), which could improve observability across MCP client-server communication. Madhavi expressed interest in leveraging this in her MCP integration, though the Python SDK's implementation status is uncertain. + +### `agent/list` and the Server Question + +The core technical debate resumed from the [prior meeting](https://github.com/modelcontextprotocol/agents-wg/pull/20): what MCP server would an `agent/list` operation be called against? Luca's position was that introducing a new RPC method implies the existence of an MCP server to call it on — "asking for a wire shape without having a wire." Madhavi's position was that she explicitly does not want a separate registry MCP server (additional deployment unit, operational burden, network hops), but wants the routing benefit of agent-level bucketing for her 71-tool system. + +The impasse resolved when Luca proposed that `agent/list` could live on the same MCP server that already provides the tools. The server would expose sub-agent definitions via `agent/list`, with one constraint: each sub-agent may only declare tools that exist on that same server's `tools/list`. The host application would then construct the sub-agents locally based on those definitions — the application runs the LLM, but the sub-agent definition comes from the server. This avoids a separate registry server while preserving the two-phase routing benefit (select sub-agent by capability description, then fetch only that sub-agent's tool subset). Madhavi confirmed this likely addresses her use case. + +### V1 Scope: Two-Level Hierarchy + +Luca and Madhavi agreed to restrict the initial design to a two-level hierarchy: supervisor and sub-agents with tools. Madhavi confirmed her team operates exclusively at two levels in production — a prior Databricks-related component that was initially considered for agent status was ultimately registered as a plain tool. + +They briefly discussed the three-level case. In Madhavi's prior workflows, the third layer was an MCP server providing tools to a sub-agent: the middleware performs a `tools/list` call to the MCP server on behalf of the sub-agent, which then invokes those tools directly. This pattern may generalize from the two-level design but introduces additional complexity that warrants separate treatment after V1. + +## Follow-ups + +- **@LucaButBoring**: Post a sequence diagram and pseudo-code on [PR #20](https://github.com/modelcontextprotocol/agents-wg/pull/20) illustrating the two-level architecture (supervisor, sub-agents, tools) with the proposed `agent/list` on the same server; ping @madhaviai on Discord when posted. +- **@madhaviai**: Test the proposed sub-agent construction approach (MCP server exposes agent definitions via `agent/list`, sub-agents restricted to that server's tools, host constructs sub-agents locally).