6.7 KiB
2026-06-19 Agents WG
Raw Gemini-transcribed meeting notes and transcript available on Google Docs
Date: June 19, 2026 Attendees: Luca Chang, Madhavi Pasumarthi, 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 and that it could be merged into the existing agent use cases research, 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.
- @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.