diff --git a/meetings/2026-05-05.md b/meetings/2026-05-05.md
new file mode 100644
index 0000000..d65c807
--- /dev/null
+++ b/meetings/2026-05-05.md
@@ -0,0 +1,60 @@
+# 2026-05-05 Agents WG
+
+> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/1_lDI3VNnFavAn8VtYYPbxVXJKUDYX4unLdKNc_whqIw/edit)
+
+**Date:** May 5, 2026
+**Attendees:** Luca Chang, Vinay Ramesh, Madhavi PDB
+
+## Discussion
+
+Attendance was low, with most of the participants from the previous meeting absent. The group focused on reviewing the [approaches document](https://github.com/modelcontextprotocol/agents-wg/pull/5) for how MCP could support a concept of agents, with discussion centering on interoperability challenges, multi-turn interaction primitives, and the distinction between agent definition and agent orchestration. The group concluded that organizing specific, real use cases was the next step to deciding on a path forward.
+
+### Agent Platforms and Interoperability
+
+Luca outlined the current state of agent platforms: AWS has Bedrock AgentCore and Microsoft has Microsoft Foundry, both of which offer agent orchestration within constrained, predefined workflows. These work well in closed environments where the full implementation details of every agent are known, but interoperability with peer agents outside the closed system remains a challenge that neither has fully solved.
+
+Vinay noted that A2A's lack of adoption is primarily a discovery problem rather than a primitives problem — A2A has the orchestration and task-level primitives that are needed, but is underspecified compared to MCP. Where MCP is prescriptive about what is exposed to the LLM versus the host client, A2A makes no such distinction. Vinay proposed that MCP's role should be to provide a prescriptive pattern for how to use MCP plus an AI catalog to perform agent-level operations, focusing on discovery, definition, and tool accessibility.
+
+### Single-Turn Limitations and the Multi-Turn Gap
+
+Luca described a practical example where AWS has an MCP server that exposes an agent as a tool for interacting with documentation. The interaction is currently single-turn: the calling agent asks a question, gets an answer, and any follow-up requires starting a clean instance of the remote agent. Luca suggested the lack of multi-turn interaction capabilities is a core missing feature from MCP for agent use cases.
+
+Vinay added that an additional missing piece is a server-side definition of how tools can be used together, including when to request user input versus sampling an LLM on the host side. Currently, something like LangChain or LangGraph exposed as a tool is almost required to handle this on the server side.
+
+### Agent Definition vs. Remote Agent
+
+Luca noted that the approaches document covers two distinct strategies:
+
+1. **Remote agent (agent-as-tool):** The straightforward approach where a remotely running agent is exposed as a tool that handles orchestration internally and returns a result.
+2. **Agent definition:** An alternative where the server exposes a definition and establishes a convention for how a host application constructs its own agent from that definition.
+
+### Multi-Turn Primitives and State Management
+
+Madhavi raised the question of how state is maintained during multi-turn interactions. Luca explained that implementation details are abstracted away, but a practical approach would be persisting the conversation to a data store keyed on a conversation ID, allowing subsequent turns to reconstruct the conversation.
+
+Vinay distinguished between two models for multi-turn behavior:
+
+1. **Client-side model:** Operations are stateless, but history of previous operations is provided to the server.
+2. **Server-side model:** Metadata on every invocation enables the server to fetch additional data, abstracting multi-turn behavior away from the client.
+
+Vinay argued that the LLM should not be responsible for generating or managing conversation IDs for multi-turn interactions — this should be a protocol-level concern handled by the harness. The task lifecycle is governed by the server, and the interop challenge arises when servers and clients may or may not support tasks.
+
+Luca questioned why conversation state could not simply be a tool parameter. Vinay responded that while technically possible, the protocol should enable abstract hosts to interact with abstract clients in a prescriptive way without requiring LLM involvement in state management.
+
+### Model Selection
+
+Madhavi raised the need for users to select different models across different tools or agents within a system (e.g., one model for reasoning, another for code generation). Vinay noted that sampling with a model family hint is currently supported, and within an agent definition, different LLM calls can be assigned hints prescribing which models perform better with specific tools. Luca suggested that in the agent-as-tool approach, the model selection override could be represented as a tool parameter.
+
+### Workstream Separation
+
+The group agreed to divide the agent work into two distinct workstreams:
+
+1. **Agent definition:** What level of customization needs to be available to the host and to the server.
+2. **Multi-turn primitives:** What primitives are needed to enable agent-to-agent multi-turn behavior, and whether the task primitive is sufficient or if additional protocol-level support is required.
+
+A comprehensive list of real-world use cases will inform the design requirements for both workstreams, organized across coding agents, enterprise use cases, and consumer applications.
+
+## Follow-ups
+
+- **@vinoo999**: Share internal use cases organized by multi-turn vs. agent definition across coding, enterprise, and consumer categories.
+- **@LucaButBoring**: Reach out to @SamMorrowDrums to discuss the GitHub MCP server as a reference point for a canonical host application and publicly exposed MCP server.