4.3 KiB
2026-07-10 Agents WG
Raw Gemini-transcribed meeting notes and transcript available on Google Docs
Date: July 10, 2026 Attendees: Luca Chang, Madhavi Pasumarthi, 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, 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 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.