Add 8/21 meeting notes

meetings/2026-08-21.md

@@ -0,0 +1,48 @@
+# 2026-08-21 Agents WG
+
+> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/1qmMfB62msXPusdnMf8WhFNs-OEnZjbPh8CTqMthXB8A/edit)
+
+**Date:** August 21, 2026
+**Attendees:** Luca Chang, Kryspin Ziemski, Veerendra Kumar
+
+## Discussion
+
+The meeting centered on Kryspin's proposal to extend MCP resources with CRUD and Query operations — treating resources as first-class protocol primitives with delegated URI resolution — as a foundation for agent state management and sub-agent workflows. Supporting threads covered why agents fail to traverse resources today, how skills and front-loaded context relate to determinism, a server prefix-awareness gap both participants consider significant, and how resource namespaces could give tasks intermediate outputs.
+
+### Resources 2.0: CRUD, Query, and Delegated URI Resolution
+
+Kryspin proposed implementing Create, Read, Update, Delete, and Query (CRUDQ) operations for MCP resources. If resources were first-class objects with standard CRUD capabilities, they would form a natural backbone for agent state — a pattern he compared to agent file systems like AgentFS — and solve resource-graph traversal without special logic. The core mechanism is delegated URI resolution: the harness recognizes resource URIs in tool results and automatically dereferences them into context for the next agent turn, making protocol resolution a guaranteed harness behavior rather than something the agent handles through explicit tool calls.
+
+The motivating problem is that agents fail to traverse resources today: many harnesses do not reliably pull down embedded resources, and where traversal exists it is a function call rather than a protocol feature — raising the question of why one would write resources instead of tools. Progressive discovery degrades with depth; Kryspin cannot run a multi-tier documentation library beyond a three-level hierarchy without placing indexes at every level. Two explanations surfaced: agents default to familiar patterns like bash rather than discovering resources, and models simply have not been reinforced to follow resource links — a benchmarking gap rather than inherent non-determinism. Luca questioned whether unified resolution is uniquely useful given that missed embedded resources are harness implementation gaps; Kryspin's response was that first-class treatment is precisely what creates the standard expectation client implementers build against, as skills-over-MCP demonstrated.
+
+Query would act as a polymorphic semantic operator over resource namespaces — mapping to grep against a file namespace, a SELECT against a database namespace — following the recently standardized HTTP verb. For any of this to shape agent behavior, the harness must block the corresponding native operations (file access, bash) so the resource-backed path is the only one available; both agreed the pattern fails without that, since agents otherwise default to bash. Harness override mechanisms like Claude Code's hooks already show this kind of behavior replacement is practical. On storage, the required operation verbs map naturally onto S3-like systems, though S3-backed file systems misbehave in edge cases around metadata and symlink semantics; Kryspin considered such gaps mostly workable through HTTP options and head requests.
+
+### Skills, Front-Loaded Context, and Model Awareness
+
+A recurring theme was why skills work and what that implies for resources. Kryspin's account is that models have begun recognizing skills as a trained structure, and front-loading context simulates determinism — error accumulates the deeper into a conversation the model goes, so context injected early outperforms context discovered mid-loop. Resources handled the same way (gathered by the harness and injected up front) should see the same benefit. The open disagreement was narrower than it first appeared: servers can already ship skills-like blocks in server instructions or tool descriptions, and both approaches benefit from models recognizing the structure, so the delta from first-class client support is mainly avoiding the confusion of duplicated or misplaced skills blocks — though Kryspin held that only client-side adoption (enumerating server skills into the front-loaded block) delivers the full benefit.
+
+This led into model awareness as a protocol question: anything model-aware presupposes knowing what a model ID actually is, and servers currently have no way to learn the model or its context budget so they can tailor responses. Kryspin agreed model variance is worth pushing for as a protocol feature rather than backdooring it through URI resolution.
+
+### Server Prefix Awareness
+
+A practical gap both participants flagged as significant: harnesses reverse-map resource URIs to their originating servers by inserting a prefix after the URI scheme, but servers are never told what prefix they were assigned. A server that references its own resources outside a dedicated resource block — a resource URI in a tool description, for instance — produces URIs that do not match the harness's prefixed representation and cannot adjust its responses to compensate. They arrived at the same conclusion from opposite directions: servers should know their prefix, and the onboarding process currently has no way to tell them.
+
+### Agent State as Namespace URIs
+
+Building on delegated resolution, Kryspin proposed representing agent session state as URI namespaces (e.g., `agent://session/next`). Because the harness guarantees namespace resolution, a sub-agent could operate entirely on server-side artifacts through CRUDQ — its workflow steered by URIs embedded in tool results that the harness dereferences each turn, its intermediate state living in a task or session namespace — without creating side effects in the client environment. Even a harness with no client-side file access could run a fully functional agent this way. The same caveat applied: the harness must block native behaviors like file writes for the resource-backed path to be authoritative.
+
+### Tasks and Intermediate Outputs
+
+Kryspin asked whether tasks are roadmapped as a first-class concept with steering and intermediate outputs. Luca confirmed tasks are on the roadmap but not with side-effect results — in the current framing there are no intermediate outputs, only the final result, which is a significant distinction from A2A's artifact model. Kryspin connected this to the resources proposal: if task artifacts were resources, a task ID would map to a namespace where the agent reads and writes intermediate state, notifications would fire on updates, and steering would amount to patching parts of the namespace. This would make tasks more useful but requires extending the current task framework; CRUDQ on resources would provide the capability without importing A2A's artifact structure.
+
+### Agent Definitions, Discovery, and Next Iterations
+
+The agent definitions and discovery proposal is in a discovery phase focused on definitions, with discovery mechanisms also in scope. Whatever state the proposal starts in will not be its final state — the group needs a starting point to iterate from — and Kryspin's intended contribution to that iteration is the reference example, which he wants to complete before weighing in on discovery specifics.
+
+For the Resources 2.0 work, Kryspin committed to a TypeScript reference implementation integrated into the Pi agent plugin — CRUDQ operations, URI delegation, and task management through resource namespaces — on the view that a working implementation is what moves the discussion beyond theory and influences client implementer standards. Luca advised presenting it from the grounded use case — what problem it solves and for whom — rather than leading with the architectural abstraction.
+
+## Follow-ups
+
+- **@kziemski**: Build a TypeScript implementation of Resources 2.0 with CRUDQ operations and integrate it into the Pi agent plugin, demonstrating URI delegation and task management through resource namespaces.
+- **@kziemski**: Share the protocol design and reference implementation with Felix for review.
+- **@LucaButBoring**: Review the reference implementation shared by Kryspin and provide feedback on the proposed resource architecture and agent state management approach.