5.6 KiB
2026-04-21 Agents WG
Raw Gemini-transcribed meeting notes and transcript available on Google Docs
Date: April 21, 2026 Attendees: Luca Chang, Sriram Panyam, Amruth Lal, Srikalyan Swayampakula
Discussion
The group discussed conformance test development for MCP Tasks, then pivoted to the broader question of how MCP should represent agents as a protocol-level concept.
Task Conformance Tests
Sriram noted the absence of conformance tests for Tasks and shared that he had written experimental tests against the TypeScript SDK reference of the current Tasks specification while building a personal Go reference server. Luca confirmed the gap and pointed Sriram to SEP-2557, which proposes significant revisions to tasks based on identified gaps and intersections with the Transports WG's work on simplifying Streamable HTTP.
Luca stated that conformance tests are planned by the May 15th release candidate date, but the extent of revisions in SEP-2557 mean they will likely need to be written from scratch. Sriram offered to take a stab at conformance tests against SEP-2557 in parallel, with the understanding that the work is experimental and subject to breakage. Luca encouraged this and asked to be kept in the loop given the tight timelines.
Reorienting the Working Group Toward Agents
Luca proposed shifting the Agents WG's focus away from Tasks — which have become more closely aligned with the Transports WG — and toward explicitly defining a concept of agents within MCP. The goal is to avoid overlap with the Skills Interest Group while addressing the remaining gap: there is currently no structured way for an MCP server to represent an agent.
Luca outlined the central design tension: where inference and the agent loop live. If the server owns everything (as in A2A-style approaches), the architecture is conceptually simple but heavy for server implementers. If the client owns inference, the cost is lower since clients already perform inference, but the protocol needs to prescribe how agent definitions are communicated from server to client.
Agent-as-Tool vs. Agent Definition
Amruth asked what value a protocol-level agent concept adds over hosting an agent behind a tool today. Luca responded that the primary benefit is supporting cases where the client does not want to own inference or the agent loop. The status quo assumes clients perform inference, which means having an agent specification on the client is cheaper than running one on the server. Most servers (e.g., the GitHub MCP server) prefer stateless request-response interactions and do not want to host persistent agent loops.
Luca planned to create an organized document listing the various approaches and their tradeoffs, similar to what the Skills Interest Group produced for skills.
Agents as Tasks: The Subtask/DAG Question
Sriram proposed that a client-side agent invocation could be modeled as an opaque, long-running task call. If the task concept were extended to support subtasks or a task DAG, it could map to the structure of agents and sub-agents. Luca noted that while a subtasks proposal exists, previous feedback suggested a strict tree structure is too rigid — a DAG would be more appropriate.
Srikalyan argued that tasks and agents should remain separate concepts: a task defines the work (including constraints like budget), while an agent is the executor that orchestrates sub-agents to accomplish the goal. Agents can operate as parallel processes with independent sessions or as threads sharing context.
Luca observed that the phrase "agent definition" may map onto what others are calling a "task definition" — a non-runtime construct describing what needs to be done, which produces a dynamic task graph when executed. Sriram agreed, noting that a tool call effectively acts as a task invoker.
Multi-Turn Interaction and Sub-Agent Communication
The group discussed how sub-agents communicate with the calling agent. Luca noted that current implementations typically have sub-agents end their loop for the main agent to process the result, rather than supporting mid-loop callbacks. Sampling cannot satisfy this use case because it has become a stateless completion request, and elicitation is strictly for the user. This leaves no primitive for a sub-agent to explicitly request information from its caller during execution.
Sriram raised that parallel sub-agents currently fail when any of them need input, falling back to sequential execution. Luca noted that Claude Code's ability to resume sub-agents with follow-up messages partially addresses this, but a protocol-level primitive for caller-directed information requests would fill the gap more cleanly.
Ownership as the Core Question
Luca concluded that the highest-level question remains who owns inference and the agent loop, as this dictates complexity distribution between server and client. Srikalyan suggested remaining open to the loop existing on either side. Luca acknowledged this but noted that the simplest architectural form (server owns inference via a tool call) is impractical because most servers prefer not to host inference. The group agreed that a document organizing these approaches is the necessary next step.
Follow-ups
- @LucaButBoring: Finalize updated Tasks specification by the May 15th release candidate date.
- @panyam: Develop experimental conformance tests against SEP-2557, keeping Luca in the loop on timeline.
- @LucaButBoring: Create an organized document listing all approaches for defining agents in MCP with tradeoffs.