4.3 KiB
2026-07-17 Agents WG
Raw Gemini-transcribed meeting notes and transcript available on Google Docs
Date: July 17, 2026 Attendees: Luca Chang, Madhavi Pasumarthi
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), 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: 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 illustrating the two-level architecture (supervisor, sub-agents, tools) with the proposed
agent/liston 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).