Add 8/14 meeting notes

meetings/2026-08-14.md

@@ -0,0 +1,61 @@
+# 2026-08-14 Agents WG
+
+> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/1pIP0EmAiUO1ke0TC-gJJAhp0dG5MQ2BV01ugADPmYP4/edit)
+
+**Date:** August 14, 2026
+**Attendees:** Luca Chang, Madhavi Pasumarthi, Kryspin Ziemski
+
+## Discussion
+
+The meeting focused primarily on agent loop semantics and sub-agent execution patterns — how sub-agent loops actually execute, and whether termination and continuation need explicit protocol-level signals — followed by updates on the agents progressive disclosure proposal and SDK implementation status. Kryspin introduced the graph-over-MCP concept as a resource traversal improvement, and the group discussed roadmap timelines for the October specification lock-in.
+
+### Graph-over-MCP and Resource Traversal
+
+Kryspin introduced graph-over-MCP: modeling MCP resources as a hyperlinked graph with internal URI resolution, so that sub-agents can hydrate and understand interconnected resources — a graph-theory-based approach to resource loading, not a framework in the LangGraph sense. The motivating problem is that agents do not treat resources containing links as hyperlink documents: they fail to traverse from one resource to another, producing discovery and resolution failures. In his view, protocol-first resource loading — treating any loaded resource as a protocol — would enable better schema resolution.
+
+How much of this is a protocol gap versus a harness-guidance gap was left open. In practice, resource traversal works when something explicitly tells the agent when to read a resource — a skill, tool result, description, or server instructions — a pattern visible in resource-heavy servers like the Unity MCP server. The counterpoint is that this reflects agent bias toward formats the model understands best, such as markdown: without explicit markdown or well-formed links, agents generally do not understand URIs or internal resource references, and local models in particular struggle due to context limits or incomplete link processing.
+
+### Sub-Agent Loop Execution
+
+Madhavi walked through her `agent/list` flow diagrams. In her design, `agent/list` retrieves registered tool schemas for sub-agents and the client decides which tools to call — calls remain opaque and client-initiated throughout, consistent with MCP's architecture. Her deployment is effectively three-tier: a thin end-user host in front of a heavier service tier that runs the LLM calls, with the MCP server separate behind both. The diagrams need revision to make these physical boundaries explicit, which she took as a follow-up.
+
+The walkthrough prompted a broader exchange about what the "tool loop" in such flows actually is. It is not a structured feature: the model simply loops until it reaches a self-determined completion criterion — a colloquial, in-practice loop rather than deterministic code. This is a real reliability concern for weaker models: in Kryspin's testing with DeepSeek models on a similar hydrated-loop approach, small tool surfaces worked but large tool surfaces produced context window exhaustion and hallucinated tool executions — known failure modes when a model effectively acts as its own harness without structured guidance. Whether the fix is hydrating a proper loop rather than letting the model talk itself into looping remained a hypothesis rather than a conclusion.
+
+### Turn Semantics and Loop Termination
+
+The central debate of the meeting was whether sub-agent handoff and termination need explicit signals, or whether implicit turn-ending semantics suffice. Three positions emerged:
+
+1. **Explicit turn semantics** (Kryspin): tool results should carry standardized signals — XML or template tags, or JSON markers like tool-continue and tool-end — that tell the parent agent a handoff or termination has occurred. The motivating failure mode is silent failures: certain models, particularly local or quantized ones, will not continue unless an affirmative handoff has occurred, which is why [OMP](https://github.com/can1357/oh-my-pi) requires affirmative handoffs as a setting. Since harnesses already recognize XML-based skills, template tags in tool results could recursively call back with context — effectively enabling agent behavior without explicit protocol support.
+2. **Protocol opacity** (Madhavi): MCP should remain simple and opaque, leaving reasoning logic to the client rather than over-directing agents with server-side instructions. If a tool call fails or a question needs more reasoning, the client re-lists sub-agents and routes accordingly; LLMs are capable enough to handle delegation given proper input.
+3. **Implicit turn-end is sufficient in practice** (Luca): in many implementations the stop event is implicit in the turn-ending process — the sub-agent completes by ending its turn and its result is injected back into the main agent's context. A stop event may be logged, but nothing more explicit is required; harness-level mechanisms already make handoffs work for the delegating agent.
+
+Underneath the disagreement is a question about how far best-effort behavior can be trusted. Luca noted that a large share of harness work is best-effort in practice — the implicit model reflects how harnesses actually behave, not a formal guarantee. Kryspin agreed it is best-effort but argued the effort is redeemed by highly responsive iteration, citing OMP shipping 140 commits in twelve hours and two versions overnight; his doubt was specifically about sub-agents that play-act their role through self-talk, which he considered heavily dependent on model quality and unlikely to survive weaker models. Both framings converge on the same conclusion: the pattern needs empirical testing, which Kryspin took as a follow-up along with sharing a desanitized version of his implementation as a Pi extension.
+
+### Workflow Patterns in Agent Configuration
+
+As an extension of the explicit-control position, Kryspin proposed that MCP server agent configurations could express workflow patterns — a simple loop until proper handoff or a turn-count limit, or multi-step checkpointed processes — to guide non-state-of-the-art or quantized models when they get stuck. Such control mechanisms would help with the failure modes discussed earlier, where models cannot deterministically execute structured loops; the open question is whether MCP should standardize these patterns or leave them to client implementations.
+
+### Progressive Disclosure and Extensions Strategy
+
+The agents progressive disclosure work has an agreed approach, and the group aligned on submitting it as an extension rather than a core proposal to increase the likelihood of acceptance. Luca will share the SEP process documentation; Madhavi will review it and decide whether to raise the proposal herself or delegate to Luca.
+
+On the SDK implementation, the observability changes are being removed because the Langfuse integration would not function without a local language server; the remaining changes will go to an example directory or a fork of the Python SDK.
+
+### Tasks, Remote Sub-Agents, and Agency Hints
+
+Remote sub-agents were one of Luca's original use cases for tasks — a deep research MCP server running an LLM behind the scenes with long execution times — so tasks can serve as the implementation mechanism. But tasks should not be defined primarily as the sub-agent mechanism: some harnesses model sub-agents as task-shaped things (Claude Code among them), while many others treat sub-agents as a distinct concept, and the task semantics need to integrate with both.
+
+The previously rejected agency hints proposal came up in this context. It was rejected for two reasons: no consensus exists on what qualifies for the annotation, and annotations are meant to be hints rather than controlling how a tool is fundamentally represented. Anything the group introduces in that space will need to be a proper structured field rather than an annotation.
+
+### Roadmap and Timeline
+
+Against the October 1 specification lock-in, the practical guidance is that roadmap items get prioritized and will find a way to make the timeline work, while smaller items can still land without prioritization. Extensions are the viable release path for the group's current work — progressive disclosure is already taking that route, and publishing extensions out of cycle with the main spec is explicitly acceptable. The group should lean into the extension path going forward. Concerns that sub-agent work could face the same slow buy-in that tasks did are mitigated by both of these factors.
+
+## Follow-ups
+
+- **@kziemski**: Test recursive sub-agent loop processing using XML tags and tool back-calling, validating the approach over the weekend.
+- **@madhaviai**: Update the agent flow diagram to correctly represent the system architecture, clarifying the physical boundaries between client, service tier, and MCP server.
+- **@kziemski**: Share a sanitized document and example — with proprietary elements removed — demonstrating how sub-agent loop and turn semantics patterns can be implemented with existing client harnesses.
+- **@madhaviai**: Review the SEP guidelines documentation provided by Luca and determine whether to raise the progressive disclosure SEP or delegate the task to Luca, then message Luca on Discord with the decision.
+- **@madhaviai**: Remove observability changes from the SDK implementation and push updates to the example repository or create a fork of the Python SDK to store the necessary code modifications.
+- **@kziemski**: Build the agentic workflow as an extension for the Pi platform and deploy the work for team evaluation over the weekend.