|
|
|
|
@ -0,0 +1,53 @@
|
|
|
|
|
# 2026-08-07 Agents WG
|
|
|
|
|
|
|
|
|
|
> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/1yyzGQyIe9pWFbzyS6imQwyrQXIhUyoIUZNeSM2bCXr4/edit)
|
|
|
|
|
|
|
|
|
|
**Date:** August 7, 2026
|
|
|
|
|
**Attendees:** Luca Chang, Caitie McCaffrey, Kryspin Ziemski, Madhavi Pasumarthi, Sriram Panyam, Andrew Peek
|
|
|
|
|
|
|
|
|
|
## Discussion
|
|
|
|
|
|
|
|
|
|
The meeting divided between two threads: Kryspin's proposal for an MCP conformance testing harness, grounded in the observation that server developers have no way to evaluate how their tools perform across different agent implementations, and the continuation of the `agent/list` work from prior weeks, now centering on TTL design and cache consistency during rolling deployments. Caitie also previewed the December roadmap, anchored around agentic messaging primitives, which prompted discussion of working group consolidation and the group's relationship to code resources and the broader eventing work.
|
|
|
|
|
|
|
|
|
|
### Conformance Testing and Protocol Boundaries
|
|
|
|
|
|
|
|
|
|
Kryspin opened by asking whether a harness exists to evaluate an MCP server's capability by running it against various models to observe performance and ensure results align with expectations. Luca confirmed no such reference agent currently exists, noting that Pi is minimal and has historically been used for prototyping, but was never intended as a reference harness shape. The discussion surfaced a broader tension: server developers have mental models of how agents will use their tools but no systematic way to test those expectations, and differences between client implementations — such as inconsistent resource support — create integration challenges.
|
|
|
|
|
|
|
|
|
|
Caitie framed the core question: where is the boundary between the MCP protocol and the agent loop, and how vertical should MCP be as a standard? She compared MCP to HTTP or REST — a layer for transferring bits and supporting messaging patterns, not for solving web search or discovery — and noted that the ecosystem around tool search, progressive discovery, and agent optimization is evolving too quickly for the protocol to standardize without stifling innovation. Luca added that this tension manifests across multiple features, citing the removal of streamable HTTP sessions as an example where protocol concepts and client-specific implementations had grown in silos, creating a constant push-pull between standardizing too early and waiting too long.
|
|
|
|
|
|
|
|
|
|
Kryspin proposed building a project that acts as a conformance tester: run an MCP server through a battery of popular open-source agent harnesses, distill the results to define a "minimal loop," and help developers understand how well their tools get called and invoked by various models. Caitie agreed that such a tool would be valuable for the ecosystem and server developers — comparable to MCP Inspector — though she viewed it as outside the core protocol. She suggested that insights from the conformance work could inform future client conformance tests. Sriram enthusiastically supported the proposal, noting it addresses a pain point his team experiences in their own ad hoc conformance testing.
|
|
|
|
|
|
|
|
|
|
### Code Resources and Security Considerations
|
|
|
|
|
|
|
|
|
|
Kryspin suggested introducing code resources as a method to improve agent hydration and interface interaction, proposing they carry a MIME type for agent recognition and enable patterns like LSP usage to decrease token usage and improve results. He envisioned code resources as a way for MCP servers to expose interface definitions — such as callback mechanisms, state diagrams, or approval workflows — that clients could use to construct sub-agents with well-defined lifecycles.
|
|
|
|
|
|
|
|
|
|
Caitie raised security concerns with this approach: taking code from an MCP server in a different trust boundary and injecting it into the client trust boundary is generally inadvisable. She suggested that if this concept is pursued, it should be tried as an extension first rather than added to the core protocol, citing lessons learned from the skills-over-MCP discussion where the group deliberately made bulk code injection harder to avoid creating a vector for malicious code. Kryspin clarified he was thinking more about "code as interface" or limited subsets like PaidAI's Monty interpreter rather than full code modules, though Caitie noted this still relates to broader problems around private registries, trust, and discovery that are solved outside the protocol.
|
|
|
|
|
|
|
|
|
|
### December Roadmap and Working Group Consolidation
|
|
|
|
|
|
|
|
|
|
Caitie previewed the roadmap for the December 15th release, with the goal of finalizing a specification release candidate by the end of October. The major theme is agentic messaging primitives, with priorities including event-driven messaging (coordinated with the triggers and eventing working group), proper streaming support, partial results and steering capabilities, and aligning tasks with event-driven patterns. She emphasized her view that tools and agents are not fundamentally different — they differ only in which messaging patterns they leverage.
|
|
|
|
|
|
|
|
|
|
Caitie flagged the potential for merging the agents working group with the triggers and eventing working group due to overlapping objectives, noting that both have progressed significantly and much of the remaining work is reconciliation. Sriram and Madhavi both emphasized that events and streaming are the highest priority from a product perspective: Sriram identified event support as the single most valuable item on the roadmap, wanting not just events into the LLM but harness primitives to recognize, act on, and generate events from various surfaces like tasks and UI. Madhavi noted that combining streaming and subscription mechanisms provides functionality that rivals separate agent implementations, making these features critical.
|
|
|
|
|
|
|
|
|
|
The group briefly revisited the rejected SEP for agent annotation. Caitie explained that the proposal was declined because there is no consensus on what defines an agent versus a tool, and it remained unclear what clients would do with such metadata. Kryspin argued that an agent is anything that orchestrates effort and does not require an LLM, but Caitie countered that annotations are inherently ambiguous — clients cannot fully rely on them — and the supporting use cases were not sufficiently clear.
|
|
|
|
|
|
|
|
|
|
### TTL and Cache Consistency for Agent List
|
|
|
|
|
|
|
|
|
|
Madhavi proposed establishing a Time-to-Live (TTL) for `agent/list` to ensure effective caching and data freshness. Luca confirmed that any `agent/list` implementation will definitely need a TTL because it references other entities (tools), making consistency more complex than for standalone primitives. The challenge is dependency ordering: if agents reference tools and tool schemas change during a rolling deployment, the system must detect when a cached agent definition has drifted from the underlying tool definitions.
|
|
|
|
|
|
|
|
|
|
The group discussed whether server-side notifications via SSE streams could invalidate client caches when agent definitions change. Luca explained that reliance on such notifications is inherently inconsistent: the streams drop when the MCP server deploys, and from the server's perspective nothing has changed, so no notification is sent. Sriram asked what happens if the notification is lost; Madhavi explained that in the worst case, a tool call would fail with a not-found error code, triggering the client to refresh the agent list.
|
|
|
|
|
|
|
|
|
|
Caitie clarified the caching model: the client caches the tool or agent list and does not have to refresh on TTL expiry — that is the client's choice — but the client should detect stale cache from bad requests and re-fetch the definitions. She emphasized that subscriptions are a performance optimization, not a transactional solution — consistency cannot be enforced through notifications alone, so a fallback mechanism is always required. Madhavi proposed that the `agent/list` TTL would be automatically recognized by the client as the primary fallback mechanism, with the implementation ignoring the tool-level TTL in favor of the agent-level default.
|
|
|
|
|
|
|
|
|
|
Luca raised concerns about cached tool definitions drifting during rolling deployments, where some containers serve the old schema and others serve the new one. Caitie pushed back strongly, arguing that this is an operational concern, not a messaging pattern concern, and the protocol should not add complexity to solve a problem already addressed in API design today — server developers making breaking changes are responsible for versioning their tools or their server. Madhavi explained their deployment approach: rolling deployments are rare and performed during zero-traffic windows, with the team maintaining access to the working version during regression testing to avoid service interruptions. The group concluded that the current approach of using existing TTL settings and cache scopes for `agent/list` operations is sufficient.
|
|
|
|
|
|
|
|
|
|
### SDK Implementation Status
|
|
|
|
|
|
|
|
|
|
Madhavi described her SDK implementation progress: the system is configured to trigger an `agent/list` call whenever a tool call fails with a not-found error code, focusing on the agent's default TTL while ignoring specific tool TTLs. She planned to test these changes locally, including rolling deployment scenarios, to verify that the client correctly processes the agent TTL or a default value if the builder does not define one. She committed to pushing the updated SDK code and a sample MCP server to her [research branch](https://github.com/madhaviai/python-sdk/tree/feat/mcp-agents-exp) for review. Luca agreed to review the submission once available, and the participants concluded that after evaluating the implementation and closing out remaining issues, they will draft a rough specification for the extension.
|
|
|
|
|
|
|
|
|
|
## Follow-ups
|
|
|
|
|
|
|
|
|
|
- **@kziemski**: Draft a proposal for an MCP agent conformance and testing harness; distill popular open-source agent harnesses to define a minimal loop for evaluating server capabilities.
|
|
|
|
|
- **@kziemski**: Draft a proposal detailing the use cases and security considerations for code resources in the MCP protocol, defining the integration method and safety boundaries for the proposed feature.
|
|
|
|
|
- **@madhaviai**: Push the agent SDK and sample MCP server to the [`feat/mcp-agents-exp` branch](https://github.com/madhaviai/python-sdk/tree/feat/mcp-agents-exp), including all updated documentation regarding TTL settings.
|
|
|
|
|
- **@LucaButBoring**: Review the code on the [`feat/mcp-agents-exp` branch](https://github.com/madhaviai/python-sdk/tree/feat/mcp-agents-exp) and provide feedback on the implementation.
|
Luca Chang
Luca Chang