From 91b1abb64cf070db4392c599c35b0b189620d334 Mon Sep 17 00:00:00 2001 From: Luca Chang Date: Wed, 26 Aug 2026 14:22:46 -0700 Subject: [PATCH] Add 7/24 meeting notes --- meetings/2026-07-24.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 meetings/2026-07-24.md diff --git a/meetings/2026-07-24.md b/meetings/2026-07-24.md new file mode 100644 index 0000000..99e06f8 --- /dev/null +++ b/meetings/2026-07-24.md @@ -0,0 +1,37 @@ +# 2026-07-24 Agents WG + +> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/17k97O9UIKt9fdzk7saxvJzX_qeeVFM7eWXf8qiwcvJc/edit) + +**Date:** July 24, 2026 +**Attendees:** Luca Chang, Kryspin Ziemski, Madhavi PDB, Sriram Panyam + +## Discussion + +The meeting continued the `agent/list` work from prior weeks, anchored by a sketch Luca had posted the day before as a comment on [PR #20](https://github.com/modelcontextprotocol/agents-wg/pull/20): representing an agent as a primitive that points to tools or resources within the same MCP server, which the client then uses to construct a sub-agent locally. Madhavi presented performance traces motivating the primitive, and Kryspin — returning to the group — connected the design to existing agent specifications and harness practices. + +### How Harnesses Already Handle Large Tool Sets + +Kryspin surveyed how current harnesses cope with large MCP tool counts: several, including OpenCode and [OMP](https://github.com/can1357/oh-my-pi), wrap the full tool set into search-and-execute functions rather than exposing every tool directly, and one he demonstrated has an option (`XDEV`) that exposes tools as protocol messages rather than direct function calls; in most cases he has seen such wrapped calls execute as generated Python run through an eval tool. His broader point was that once a tool is registered, its expression becomes the harness's responsibility, and the distinction between data and explicit function calls is eroding — most harnesses ultimately treat a function call as a JSON object passed back to the harness. Luca drew a technical distinction between how the harness represents tools and what the model actually emits: many models do not natively produce JSON, and the translation happens at the service and application layers. He asked Kryspin to trace how OpenCode's runtime actually executes these wrapped calls, since neither was certain of the entry point. + +### Performance Evidence for `agent/list` + +Madhavi demonstrated traces comparing two implementations of the same release-management scenario, captured using the OpenTelemetry `_meta` trace context from [SEP-414](https://modelcontextprotocol.io/seps/414-request-meta) in the Python SDK. A [Deep Agents](https://docs.langchain.com/oss/python/deepagents/overview) implementation — a supervisor handing off via task calls to three scoped sub-agents (pipeline checks, CVE web search, and chart visualization) — completed the request in 4 seconds with roughly 8,000 tokens. The equivalent MCP implementation, exposing all tools flat from a single server, took 36 seconds and consumed roughly 10,000 tokens. Her proof-of-concept application has 17 tools; her team's production servers reach 71 tools per server, where the flat-exposure problem worsens to the point of generating support requests about token burn. This is the gap she is prototyping `agent/list` against, with a Python SDK change already in progress. + +### Designing the Capabilities Field + +Luca and Madhavi worked through what an `agent/list` and `agent/get` response needs to carry. Luca argued the capabilities field only needs to reference tool names: since the client calls `tools/list` anyway, it can cross-reference the association metadata and construct the full sub-agent representation deterministically at the application level, and the harness can reduce what the LLM sees (down to just names and descriptions) to keep input tokens low. Madhavi wanted capabilities kept minimal — free-form descriptions rather than exact tool names — both to avoid overwhelming the LLM and because tool names can collide between sub-agents; in her flow the client uses the description to switch deterministically to a sub-agent, then fetches that sub-agent's tools. They converged on capabilities as association metadata from which any subset can be exposed, with the question of typed tool references versus plain strings deferred to the prototype. + +### Why a Primitive Instead of a Tool or Task + +Kryspin and Sriram both pressed on whether `agent/list` could simply be a tool call. Luca's answer: the primitive exists to differentiate things the client should transform into a sub-agent from things it should not — a task runs on the server, whereas this sub-agent is constructed on the client side from a server-provided definition, not merely an agent-shaped tool. Sriram countered that agents can run anywhere, and once execution location is decoupled, an agent's shape is no different from a task's; he floated whether an MCP server registering itself as an "agent runner" would soften the client-side expectation. Madhavi framed her position as pragmatic: at the core there are only tools and tasks, but the descriptive text around them (agent definitions, capabilities) is what materially reduces routing latency and token cost for business applications. + +Kryspin observed that a client-hydrated agent is really an agent spec question, and pointed to prior art: [Oracle's Agent Spec](https://github.com/oracle/agent-spec) serializes agents as JSON configuration plus markdown, though he knows of no actual adoption, and [Pi](https://github.com/earendil-works/pi) is the most bare-bones portable example — an agent is just a markdown file with an accompanying library, rehydratable on the other side. He argued that tying the work to a recognizable spec could drive the adoption MCP proposals seem to require. The group discussed treating agent configurations as markdown files with front matter (effectively YAML/JSON dictionaries) returned in the `agent/list` response, with resources as a possible convention for carrying them; Kryspin noted that skills over MCP, task support, and a markdown agent config together provide everything needed to hydrate a client-side sub-agent. Luca said whatever the group builds would be prototyped as an unofficial extension first and iterated from there. + +### Tool Scoping and Context Isolation + +Kryspin suggested the likely root cause of Madhavi's token burn was unconstrained tool visibility: a sub-agent definition should carry an explicit allow-list of only the tools it needs (three tools, not 71), should not see host-side tools, and should be context-isolated — no context passed from parent to sub-agent, with communication limited to the invocation's inputs and outputs, since context passing is generally a waste of tokens. Madhavi agreed with the isolation model and confirmed her goal is hiding unnecessary tools from the client's initial calls; her earlier resources-based experiment worked but burned tokens precisely because all tools remained exposed alongside the resource definitions, and the routing instructions did not scale. On her proposal for nested agents (a tree the client navigates to a leaf), Kryspin cautioned that such primitives live or die by client implementers — a great MCP server does not matter if the connecting client is poor — and suggested tools-as-tasks as a possible workaround for nesting. He shared Pi's extension mechanism in chat as an example of a minimalist client design that still supports resources, tools, and agent configs well. + +## Follow-ups + +- **@kziemski**: Update the sub-agent hypothesis document with agent-spec research and a trace of how OpenCode's runtime executes wrapped MCP tool calls; share with @LucaButBoring. +- **@madhaviai**: Review the Pi extension example Kryspin shared as a reference for tool isolation and agent configuration patterns.