Add 8/28 meeting notes

meetings/2026-08-28.md

@@ -0,0 +1,42 @@
+# 2026-08-28 Agents WG
+
+> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/1kHHHEz3wx_nCWxl3Pr4fRUruHaMjo313WDBbVsswkJI/edit)
+
+**Date:** August 28, 2026
+**Attendees:** Luca Chang, Madhavi Pasumarthi, Kryspin Ziemski, Veerendra Kumar Sunkavalli, Alex Hancock
+
+## Discussion
+
+The meeting resolved open review comments on the agent discovery proposal ([PR #20](https://github.com/modelcontextprotocol/agents-wg/pull/20)) across three questions. On error contracts, operation-specific error codes will be defined, with upstream error provenance carried in the payload rather than encoded into mutated code numbers. On tool naming, the server-wide uniqueness constraint is retained for agent-declared tools, at the cost of making same-named tools with different semantics unrepresentable across agents. The largest thread was model selection: with the model field removed from agent descriptors, an optional model requirements object — a relative-size role enum and a vision flag — returns in its place, with best-effort fulfillment of model roles left to the client. A closing thread examined what value hosted sub-agents add over the local sub-agents harnesses already provide, landing on context separation and server-encoded workflow knowledge.
+
+### Error Contracts for Agent Operations
+
+The open review question was whether the proposal needs to define errors for the new agent operations at all, given that transport and subscription error codes apply by default to any list route. The answer the group settled on: operation-specific error codes do need to be defined, reusing existing protocol codes wherever an appropriate one exists, and error provenance belongs in the payload rather than the code number. Kryspin relayed a pattern he had seen adopted elsewhere in agent development — distinguishing an error that arrived through a system hop from a direct error by mutating the code, turning an HTTP 402 into a variant like 4020 or offsetting codes into a separate range so a mask can recover the original — but the group's position, argued by Luca, was that a mutated code is not meaningful to the direct client; the response should carry the upstream error code within the actual error message, an approach Luca noted was also used in AgentCore. Madhavi had already updated the proposal's error scoping in response to the review comment.
+
+### Tool Name Uniqueness Across Agents
+
+A reviewer comment on tool naming raised whether tool names must stay unique server-wide when the same name could appear under different agents. Under the proposal's design, the constraint is inherited rather than newly imposed: tools declared on an agent are the same objects returned by `tools/list`, so all tools on a server share one namespace, agent definitions list tool names as capabilities, and the agent manager dispatches directly to registered handlers. One tool can be attached to multiple agents, but a single name can never map to two handlers — which also means no prefix-based routing is needed, since clients pick the correct tool directly from the JSON returned by the agent operations. Kryspin's suggestion of prefixing tool names with agent names was answered by this direct-dispatch model.
+
+What the constraint forbids is the scenario Veerendra raised: a ticket agent and a pipeline agent both legitimately wanting a `search` tool that does very different things. Under the current protocol that situation is simply unrepresentable — the supported pattern is two distinctly named tools, each associated with its own agent, with descriptions carrying the burden of disambiguating similar names. The group weighed relaxing the invariant for agents but retained it: consistency with existing `tools/list` behavior is convenient to hold, the conflict scenario is uncommon, and Veerendra — who framed the trade-off as flexibility versus usability — did not consider it a blocker. The question stays open pending outside evidence: the A2A community has reportedly hit the same problem, and Kryspin committed to finding that example.
+
+Madhavi confirmed the proposal's reference implementation header links her [Python SDK branch](https://github.com/madhaviai/python-sdk/tree/feat/mcp-agents-exp) containing the SDK changes, with the research PR referenced alongside it.
+
+### Model Requirements in Agent Definitions
+
+The draft removed the model field from the agent descriptor — a removal Luca considered on balance correct, since model identifiers have no standardization and model support varies widely across clients — but it reopens the non-trivial question of how a client chooses a model when constructing an agent. Without some expression of preferences or requirements in the agent definition, a host has no basis for picking a model for that agent; Madhavi had dropped the field intentionally because her SDK testing never exercised model selection, not because selection was solved.
+
+The answer the group aligned on is the presets or model-roles pattern, which Kryspin had seen in at least two places spanning harnesses and a provider: instead of naming a specific model — which the client may simply not have — the agent declares a required level of performance or capability (fast, tiny, vision, search-enabled) or an operational role (researcher, scout), and the client maps roles to concrete models, with overrides left to whoever runs it. Luca considered this a reasonable average use case while expecting higher-end implementations to keep tuning against specific models.
+
+Concretely, the field returns to the agent definition as an optional model requirements object — not a string, since the client side may not be human-driven — containing a role enum for relative size (big, medium, small) and a flag for whether a vision model is required, which Madhavi agreed to implement. Several caveats attached: vision support may ultimately belong in a crosscutting role-capabilities concept rather than the agent card, though the card is an acceptable starting point; the field can only be a recommendation, since nothing enforces it; and implementers who control both ends of a connection will likely drop custom metadata such as exact model IDs into the object.
+
+On resolution and fallback, existing conventions offer limited help. An at-sign prefix that bypasses roles and requests a specific provider model — with a fallback waterfall when it is unavailable, in the vein of OpenRouter's fallback behavior — is a pattern Kryspin had observed, but many such conventions exist and none agree, and requesting a specific model leaves only a global default as fallback rather than an appropriate one. The framing that closed the thread, summed up by Kryspin and unchallenged: agent definitions express requirements, while best-effort fulfillment of a model role is ultimately the client application's responsibility based on its own configuration.
+
+### Value of Hosted Sub-Agents
+
+Alex asked what value a client actually gets from a server-defined agent, confirming along the way that the host wrapping the client must facilitate inference for the agent — which is why model capability categories matter at all. The challenge, from his perspective as an agent developer on [goose](https://github.com/aaif-goose/goose): local sub-agents already cover delegation, so a tool that runs a packaged agent has to add value beyond what harnesses provide today. Kryspin's answer was context separation plus encoded workflow knowledge — an MCP server author knows the best way to drive their server's workflow, and hydrating that as a sub-agent on the host side gives it a clean context budget, avoiding collisions with the main session and the compaction problems that follow, with Playwright's 80-plus tools and DOM payloads as the canonical messy case people currently solve by abstracting into code-mode. He noted the problem was sharper a year ago than it is now but considered the pattern worth demonstrating, and is cleaning up an earlier harness-based version of the idea into a [Pi](https://github.com/earendil-works/pi) extension. His own client-side proposal work is otherwise paused pending resources as a first-class primitive; after feedback that his original document was too large, he split it up and plans to bring the narrower proposal to the progressive discovery meeting on Monday.
+
+## Follow-ups
+
+- **@kziemski**: Find the A2A community example concerning identical tool names across agents and assess whether it should change the uniqueness constraint in [PR #20](https://github.com/modelcontextprotocol/agents-wg/pull/20).
+- **@madhaviai**: Add an optional model requirements object to the agent definition in [PR #20](https://github.com/modelcontextprotocol/agents-wg/pull/20) — a relative-size role enum (big, medium, small) and a vision-capability flag — and push the update.
+- **@kziemski**: Clean up the earlier harness-based hosted sub-agent implementation into a [Pi](https://github.com/earendil-works/pi) extension demonstrating the concept.