From e46ff88e93b1257cf43b52bd51dc54fb575d104c Mon Sep 17 00:00:00 2001 From: Kurtis Van Gent <31518063+kurtisvg@users.noreply.github.com> Date: Mon, 23 Mar 2026 10:21:51 -0600 Subject: [PATCH] feat: add 2026-03-11 weekly meeting notes (#26) --- meetings/2026-03-11_weekly.md | 83 +++++++++++++++++++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 meetings/2026-03-11_weekly.md diff --git a/meetings/2026-03-11_weekly.md b/meetings/2026-03-11_weekly.md new file mode 100644 index 0000000..1562cb4 --- /dev/null +++ b/meetings/2026-03-11_weekly.md @@ -0,0 +1,83 @@ +# 2026-03-11 Transports WG (Weekly) + +## TL;DR +The meeting centered on two major protocol design topics: the schema scope for +Multi-Round Tool Results (MRTR) and a proposal to eliminate Data Layer Sessions +entirely. Regarding MRTR, the group debated whether incomplete response features +should be generic (applicable to all requests) or scoped only to specific +contexts like tool calls. The consensus favored a generic approach, +acknowledging the trade-off in SDK complexity, though the question will be +escalated to David (DSP) for final guidance. The second major discussion +involved Peter Alexander's "anti-sessions" proposal, which advocates for +replacing formal protocol sessions with application-specific IDs passed within +tool calls. This model-maximalist approach gained surprising traction among +attendees for its simplicity and flexibility. The group agreed to draft a formal +SEP for this sessionless approach and present both options (sessions vs. no +sessions) to the core maintainers for early feedback. + +## Detailed Summary + +### MRTR Schema Design: Generic vs. Scoped Features +* **The Dilemma:** Caitie McCaffrey opened the discussion on whether MRTR + features (like `request state` and `incomplete response data`) should be added + to the generic result object (applying to all requests) or scoped strictly to + specific requests (like tool calls). +* **Arguments for Scoping:** Mark Roth argued that allowing incomplete responses + on requests where they logically don't make sense (e.g., `ping` or `task/get`) + forces all clients to handle edge cases unnecessarily. If the protocol allows + it, clients must support it. +* **Arguments for Genericity:** Luca Chang and Caitie McCaffrey countered that + special-casing features introduces bugs and limits future innovation. Mike + Kistler (speaking for SDK maintainers) noted that a generic implementation at + the lower layers of the SDK is actually simpler to build. +* **Consensus & Escalation:** Caitie McCaffrey will draft a summary of the + options and escalate the question to David (DSP) for a final ruling based on + protocol design principles. + +### The "Anti-Sessions" Proposal +* **The Pitch:** Peter Alexander presented an argument to eliminate Data Layer + Sessions from the MCP protocol entirely. Instead of `session create`/`destroy` + mechanics, applications would use specific tool calls (e.g., + `create_shopping_cart`) to generate application-specific IDs, which the model + would then pass into subsequent tool calls. +* **Benefits:** This approach simplifies the protocol, removes the overhead of + session lifecycle management for lightweight sub-agents, and provides greater + flexibility (e.g., sharing a single "basket ID" across multiple sub-agents or + having multiple active state objects at once). +* **The "Model Maximalist" View:** Caitie McCaffrey and Kurtis Van Gent raised + concerns about whether cheaper or open-source LLMs could reliably handle + passing these IDs. Peter Alexander argued from a "model maximalist" + perspective, stating that models are increasingly proficient at instruction + following and variable tracking. +* **Support:** Mark Roth, Mike Kistler, and Geoff Goodman expressed strong + support for the proposal, agreeing that sessions are often confusing and that + leveraging existing tool call mechanisms is more elegant and scalable. +* **Backward Compatibility:** While acknowledging this is a major breaking + change, the group agreed that removing unnecessary complexity now is + preferable to maintaining a flawed feature. + +### Next Steps & Timeline +* **Drafting the SEP:** Peter Alexander will write a formal SEP for the + sessionless proposal by the end of the week. +* **Core Maintainer Review:** Because the core maintainer meeting precedes the + next Transports WG meeting, the group will vote asynchronously on Peter's + draft. Both the original sessions proposal (by Shaun Smith) and the + anti-sessions proposal will be presented to the core maintainers as an "early + preview" to build consensus before Dev Days. +* **Luca's Roadmap:** Luca Chang is out for two weeks. Kurtis Van Gent will + ensure Luca's priority task-related SEPs ("jump scares" and "task continue") + are surfaced at the next core maintainer meeting. + +## Action Items +- [ ] **Caitie McCaffrey** to draft a summary of the generic vs. scoped MRTR + options and escalate to David (DSP) via Discord for guidance. +- [ ] **Peter Alexander** to write a formal SEP detailing the proposal to remove + sessions from the MCP protocol. +- [ ] **Kurtis Van Gent** to follow up with Shaun Smith to ensure the original + sessions SEP is ready to serve as a counter-argument to the anti-sessions + proposal. +- [ ] **Caitie McCaffrey** to initiate an asynchronous thread for the WG to + review and vote on the two session proposals before the core maintainer + meeting. +- [ ] **Kurtis Van Gent** to follow up with Luca Chang regarding the priority + task-related SEPs before Luca's leave. \ No newline at end of file