Commit past meeting notes

meetings/.gitkeep

@@ -1 +0,0 @@
-This file will be deleted.

meetings/2025-10-28.md

@@ -0,0 +1,75 @@
+# 2025-10-28 Agents WG
+
+> Originally published as https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1726
+
+**Date:** October 28, 2025
+
+## Attendees
+
+- Luca Chang
+- Che Liu
+- John Harris
+- Jonathan Hefner
+- Peder Holdgaard Pedersen
+- Peter Alexander
+- Shaun Smith
+
+## Discussion
+
+The working group reviewed [SEP-1686: Tasks](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1686), which supersedes the earlier [SEP-1391: Long-Running Operations](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1391) proposal. The new approach focuses on data-layer concerns and avoids changing tool call semantics, instead relying on notification-based patterns for progress updates.
+
+### Server-to-Client Task State Management
+
+The proposal allows servers to request task augmentation from clients, raising questions about distributed state management. While clients are typically not distributed, some implementations may be. This creates implementation complexity around whether the host application or the MCP client should own the task store.
+
+In the reference implementation, the client needs to expose an extension point for task storage, but only the host application can actually fulfill that requirement, separating their responsibilities.
+
+### Task-Augmentation Opt-In Mechanism
+
+A key concern is whether clients should expect any operation (like `tasks/list`) to potentially take minutes or hours when task-augmented. MCP requests can already be slow, and the SEP does not change this. However, the SEP clarifies that receivers choose whether to accept task augmentation for specific requests, allowing servers to refuse task augmentation on requests that it expects will be quick.
+
+However, this design raises a discoverability problem: clients need a way to know which requests support task augmentation, or else the expectation must be that they attempt to augment every request with a task. The group discussed using either capabilities or tool annotations to signal this support, and left it up to the SEP to clarify.
+
+### ListTasks Security and Consistency
+
+The `tasks/list` operation needs filtering capabilities for security reasons, as clients should not see tasks from other contexts. The group agreed on a consistency requirement: if a client can call `tasks/get` to retrieve a specific task, that task must appear in `tasks/list` results for that client.
+
+There was also discussion about bidirectional symmetry—whether it makes sense for servers to call `tasks/list` on a client. This would only be relevant if the client supports server-to-client task augmentation and would require explicit configuration, but it should be allowed under those circumstances.
+
+### Relationship to TrackElicitation
+
+The group noted potential overlap with [SEP-1036: URL Mode Elicitation](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1036), which introduces an `elicitation/track` method carrying a progress token. While `elicitation/track` and Tasks serve different purposes, they may be redundant in some scenarios. The group recommended coordinating with the proposers of #1036 to clarify the relationship.
+
+### Implementation Patterns and SDK Concerns
+
+The proposed `beginX` pattern (e.g., `beginCallTool` returning a `PendingRequest`) needs validation with SDK maintainers across different languages. In C#, "Task" already has a well-established meaning in the standard library, which will require awkward naming like `McpTask` to avoid confusion.
+
+### Idempotency and Client-Generated IDs
+
+The group debated whether idempotency should be tightly coupled to tasks. The original rationale was twofold:
+
+1. Tasks are generally long-running and expensive, making idempotency important for retry scenarios
+2. Client-provided task IDs enable future subtask association features, allowing servers to pre-allocate IDs for follow-up operations
+
+Client-generated IDs provide valuable message association benefits, particularly for future subtask extensions. However, this comes at a complexity cost for servers that simply want to expose existing workflow APIs.
+
+More broadly, the group observed that request association and idempotency are useful features independent of the full task lifecycle. Requiring implementers to adopt the complete task model to get these benefits may be unnecessarily restrictive.
+
+### Reference Implementation Evolution
+
+The [Python reference implementation](https://github.com/modelcontextprotocol/python-sdk/pull/1398) from #1391 became complex after incorporating feedback, particularly around the task broker API. For a v0 implementation, a simpler approach seemed more appropriate, leading to the current [TypeScript reference implementation](https://github.com/modelcontextprotocol/typescript-sdk/pull/1041).
+
+The core client changes (excluding server-to-client task augmentation) primarily involve splitting RPC methods into `beginX` variants that return `PendingRequest` objects. This simplified scope makes it feasible to create a streamlined Python implementation for real-world testing with the HuggingFace Jobs API (see **Follow-ups**).
+
+## Follow-ups
+
+**Integration and Testing:**
+- @LucaButBoring will collaborate with @evalstate on integrating with the HuggingFace Jobs API to validate the design's usability in practice
+- @pwwpche will reach out to @ihrpr about engaging other SDK and client developers on the `beginX` method splitting pattern
+
+**Specification Updates:**
+- **DONE** Add a consistency requirement that any task retrievable via `tasks/get` must appear in `tasks/list` for that client
+- **DONE** Define a mechanism (capabilities or annotations) to signal which operations support task augmentation, avoiding unnecessary augmentation attempts
+  - **DONE** Using *both* capabilities and tool annotations to signpost this
+- **PENDING** Reconsider the coupling between idempotency and tasks—at minimum, make idempotency a **MAY** requirement rather than a **MUST**. Ideally, extract generally useful concepts (idempotency, message association) into separate features that don't require full task support
+  - **DONE** Task idempotency is no longer required

meetings/2025-11-04.md

@@ -0,0 +1,53 @@
+# 2025-11-04 Agents WG
+
+> Originally published as https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1764
+
+**Date:** November 4, 2025
+**Attendees:** Luca Chang, Che Liu, Peter Alexander, Shaun Smith, Mike Kistler, Kryspin Ziemski
+
+## Discussion
+
+This week's Agents WG meeting continued work on #1686, focusing on feedback integration and emerging implementation challenges as the proposal moves toward the 11/25 spec release.
+
+### Task Message Association and Scope Questions
+
+The group discussed whether task message association via `relatedTask` metadata should remain in scope for the initial release. While there was some agreement that message association could be treated as a separate concern, removing this metadata has broader implications for real-world usage patterns. The most significant concern centered on the `input_required` status: without message association, there's no clear mechanism to signal which requests are blocking a task from advancing. The group will need to come to a decision on this scoping question before the next meeting.
+
+Related to this discussion, the group noted that `input_required` is mentioned throughout the proposal but hasn't been formally added to the list of statuses in the data model, which needs to be corrected.
+
+### Task Acceptance: Notifications vs. Responses
+
+The question of whether task acceptance should use notifications or responses surfaced again, tying back to the broader concerns around message association and task lifetime management which are documented as a design decision in the SEP. This will be discussed further following this meeting.
+
+### SDK Implementation Philosophy and Automatic Opt-in
+
+Following the Core Maintainers meeting from the previous Wednesday, the group discussed approaches to task augmentation in the reference SDKs. The TypeScript and Python implementations will automatically opt in to task augmentation when available, treating this as an opportunity to bolster adoption by making the feature accessible by default.
+
+However, it was noted that the C# SDK takes a different philosophical stance, avoiding automatic behavior in favor of explicit developer control. The group agreed this is an acceptable divergence, and other SDKs will likely establish their own positions on this question. The Java SDK, for instance, follows a similar philosophy to C#.
+
+### Connection Management and Server-Side Termination
+
+The group discussed practical challenges around connection management in sHTTP, as it relates to tasks. In most cases, implementations will want to avoid keeping a connection open while polling for task completion, but current SDKs don't provide support for proactively terminating a connection from the server side after e.g. a configurable timeout. An early-termination response pattern would be ideal for this use case, but the group agreed this is better suited for a future SEP rather than expanding the current scope.
+
+Related to this, several features being cut from SEP-1686 will be reintroduced as separate SEPs following the 11/25 release, as there isn't sufficient time to develop them in parallel with the core tasks proposal.
+
+Technically, the current MCP specification [does allow](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#listening-for-messages-from-the-server) for resumable server-side termination of SSE streams, but no SDK currently implements this capability. Attempting to use MCP in this way often results in errors when trying to write messages to the broken response stream.
+
+### Session Binding and Identity Challenges
+
+A significant implementation challenge surfaced around session binding for tasks. The current reference implementation only supports task identification via task ID, with no mechanism to bind tasks to sessions or restrict users to viewing only their own tasks. While this was initially an implementation oversight, it also reflects ongoing friction around how MCP handles sessions and identity.
+
+The planned implementation adjustment involves passing the transport session ID into task store methods as an optional parameter. Once #1442 lands, this approach will support both sHTTP and STDIO transports, though the initial implementation will only support session binding for sHTTP.
+
+The group also discussed why session binding needs to be optional. Session binding has to be optional because sessions themselves are optional in MCP (STDIO also does not support them). However, this creates confusion because sessions and identity are poorly defined at the application level. The transport notion of a session is separate from the application notion of a session, and this ambiguity creates challenges for implementers.
+
+The group suggested working with the Transports WG on this, if we can benefit from application-level session semantics for tasks. In the meantime, the proposal should include a clear statement about what session binding means for tasks, providing implementation guidance even in the absence of formal application-level session definitions in MCP.
+
+## Follow-ups
+
+- **DONE** **@LucaButBoring**: Include `input_required` status in data models
+- **DONE** **@LucaButBoring**: Come to a decision on if task association metadata should be in scope
+- **DONE** **@LucaButBoring**: Clarify explicitly what session-binding looks like for tasks
+- **DONE** **@LucaButBoring**: Clarify explicitly what it means for a request to be "associated with a task"
+- **DONE** **@LucaButBoring**: Update reference implementations for latest SEP revisions
+- **DONE** **@pwwpche / @LucaButBoring**: Meet to discuss notifications vs. responses in more detail

meetings/2025-11-11.md

@@ -0,0 +1,69 @@
+# 2025-11-11 Agents WG
+
+> Originally published as https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1797
+
+**Date:** November 11, 2025
+**Attendees:** Luca Chang, Che Liu, Shaun Smith, Peter Alexander, Peder Holdgaard Pedersen, Casey Boyle
+
+## Discussion
+
+### SEP-1686: Tasks - Major Architecture Changes
+
+The Agents Working Group reviewed revisions to SEP-1686 based on Core Maintainer feedback from last week. The proposal has been accepted with changes and will be marked as "experimental" in the upcoming release to signal that further refinements may be introduced in future releases.
+
+#### Core Changes: Server-Side Task IDs and Request/Response Model
+
+The most fundamental change is moving task ID generation from clients to servers. This shift enables a more robust architecture where task lifetimes are decoupled from individual requests.
+
+In the previous SEP revision, when a client called a tool, it still had to effectively wait for a `CallToolResult` before proceeding, forcing servers to block the entire request until completion. Now, the server immediately returns a `CreateTaskResult` with a server-generated task ID, allowing the actual work to continue asynchronously. A `TaskCreatedNotification` is still sent for convenience, but the result is the canonical source of truth.
+
+Tool implementors no longer need to implement their own polling mechanisms when integrating with external workflow APIs - the server can accept the request, return immediately, and update the task status as work progresses.
+
+However, this means requests are now polymorphic. A task-augmented `CallToolRequest` returns a `CreateTaskResult` instead of a `CallToolResult`. This means SDK maintainers need to expose new methods to handle these different response types, should they wish to expose this to developers. To minimize the new API surface being introduced, task support is initially restricted to just three request types:
+- `tools/call`
+- `elicitation/create`
+- `sampling/createMessage`
+
+#### Streaming Challenges for sHTTP
+
+The architecture change also creates a challenge for sHTTP: how do you stream messages back to the client when the initial request stream ends immediately? #1699 isn't applicable here, as the point of ambiguity is which stream to send data back on to begin with, as the initial stream would end with the `CreateTaskResult` being sent. This is an implementation decision for SDK maintainers, but the group discussed two approaches:
+
+**Option 1:** Each `tasks/get` call returns pending messages on a short-lived SSE stream. This is more complex to implement but avoids long-running connections.
+
+**Option 2:** `tasks/get` returns JSON, while `tasks/result` opens a long-lived SSE stream for all messages. Simpler architecture but requires maintaining connections for the task duration. To support Option 2, the proposal also modifies the `input_required` status behavior: when clients encounter this status, they should call `tasks/result` immediately, allowing a stream to open before work continues.
+
+The group agreed that Option 1 makes sense and aligns with the approach proposed by #1700. Option 2 was not as heavily discussed, as the group had trouble reasoning through its implications.
+
+To reiterate, however: The approach used will be an implementation decision that SDKs may diverge on. As long as the approach used is compliant with existing sHTTP semantics, this will not be a problem, and the Transports WG can come to an evolved specification in the future.
+
+#### Merging Task Cancellation and Deletion
+
+The latest SEP revision merges cancellation and deletion into a single `tasks/cancel` method, as their purposes were overlapping. This avoids the need to modify existing cancellation notification semantics.
+
+The group agreed that deletion of the underlying task should be optional and implementation-defined. While `tasks/delete` was originally proposed to prevent unbounded growth of `tasks/list`, servers that don't implement TTLs would face this issue regardless (and were allowed to ignore deletion requests anyway).
+
+#### Keepalives vs. TTLs
+
+On TTL design, the group favored setting TTL at task creation rather than using keepalive on terminal states. This lets clients declare upfront how long they're willing to wait and simplifies server implementation for databases with built-in TTL support.
+
+#### Implementation Status and SDK Impact
+
+@evalstate shared updates on using the reference implementations with the HF Jobs API MCP server. The current reference implementation changes do not include all of the upcoming changes and are server-side only in the TypeScript SDK, allowing implementors to update their code without protocol breaking changes. The next wave of updates (which will be synchronized across TypeScript and Python SDKs) will complete the migration by moving task ID generation to servers and introducing `CreateTaskResult`, in addition to improving on the `PendingRequest` API. The Python SDK still requires client-side task IDs temporarily during this transition.
+
+Feedback on the new server interface was positive overall.
+
+#### Host Application Integration
+
+The group discussed how host applications inform LLMs when a result has been deferred to a task:
+
+- MCP servers should have some control over the immediate response, not just hosts
+- Should there be an optional immediate response to the model/user?
+  - Not all task-augmented requests are model-visible, like non-tool calls
+  - The `_meta` field could potentially be used for this, but official guidance would be needed
+- Given the proximity to spec freeze, this will require developer guidance and experimentation in the short term
+
+The group acknowledged that host integration pattern guidance is overdue and will be prioritized.
+
+## Follow-ups
+
+- @LucaButBoring: Final revisions to the SEP verbiage

meetings/2025-11-18.md

@@ -0,0 +1,42 @@
+# 2025-11-18 Agents WG
+
+> Originally published as https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1836
+
+**Date:** November 18, 2025
+**Attendees:** Luca Chang, Che Liu, Felix Weinberger, Mike Kistler, Max Isbey, Peter Alexander, Rajesh Kamisetty
+
+## Discussion
+
+### SEP-1686: Tasks
+
+The Agents Working Group discussed the last-minute revisions to SEP-1686 from the previous week. The proposal has been merged, with only minor corrections as follow-ups.
+
+#### On `taskHint`
+
+It was noted that the name "taskHint" is misleading, as tool annotations traditionally only represent non-functional aspects of a tool, whereas `taskHint` actually implies guarantees about the tool behavior that affect how the client has to handle it. The group discussed renaming it to something like `executionMode`, and potentially moving it out of `ToolAnnotations` in the future.
+
+It was also noted that `taskHint: "optional"` is ambiguous from a client perspective, as it doesn't imply deterministic behavior for e.g. client SDKs. It is intended to mean that a client SDK that is aware of tasks should always use them unless it has a reason not to, but it also allows non-task-aware clients to continue to call these tools.
+
+The group recommended clarifying this in the specification.
+
+#### On the `input_required` status
+
+Concerns were raised about the stipulation that clients call `tasks/result` for a long-running SSE stream after encountering the `input_required` status, and that the `tasks/result` stream pattern seems to always be undesirable compared to the `tasks/get` stream pattern. Instead of having this requirement, `tasks/get` could simply only return an `application/json` response if there are no pending messages.
+
+The reason for this specification requirement was to encourage implementations using Streamable HTTP to avoid SSE streams where possible, particular to avoid cases where servers always open an SSE stream on `tasks/get`, even if there are no pending messages. This is a cross-cutting concern for all request types, but is of particular interest in tasks, where a common motivation for using them is to avoid the need for streams (it is worth noting this was not an explicit goal of the proposal, even if it is a practical consideration by developers building MCP servers).
+
+However, it was also noted that this may create a race condition if a `tasks/result` stream is terminated by either the client or the server. If the task re-transitions back to `input_required`,  the client has no way of seeing this without additional polling or resuming the result stream.
+
+@LucaButBoring will discuss this with @000-000-000-000-000.
+
+#### Planned follow-up SEPs
+
+- **Subtasks:** Enables task nesting and provenance chains, which can also form a basis for multi-turn interactions. Noted as a future direction in #1686.
+- **Extension to webhooks:** This was a common ask from stakeholders for being able to wake an agent when the task status changes. Likely ties into #992.
+- **Idempotency tokens:** Task IDs were originally intended to be client-generated and idempotent, but both of these properties were eventually dropped. Idempotency should be reintroduced as a general-purpose property across all requests. This is the domain of the Transports WG.
+- **Message association:** Task IDs are attached to all messages originating from a task for association purposes, but it has also been noted that this would be a useful feature to have across all requests. The task implementation and a future general-purpose implementation will be orthogonal and complementary. This is likely the domain of the Transports WG.
+- ~~**SSE early-termination:**~~ In a previous iteration of the proposal, it was noted that SSE stream behavior is ambiguous after the server terminates an SSE stream. This was planned as a follow-up SEP at the time, but is now resolved by #1699, which has been accepted for the upcoming specification release.
+
+### SEP-1792: Add `agencyHint` tool annotation
+
+Due to time constraints, this was not yet formally introduced to the group (this will happen at the beginning of the next meeting in two weeks), but it was clarified that `agencyHint` is not intrinsically tied to tasks, as tasks will also be commonly used for tools that are not themselves backed by an agent.

meetings/2025-12-02.md

@@ -0,0 +1,60 @@
+# 2025-12-02 Agents WG
+
+> Originally published as https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1927
+
+**Date:** December 2, 2025
+**Attendees:** Luca Chang, Peter Alexander, Victor Lu, John Baldo, Mike Kistler
+
+## Discussion
+
+### Tasks Update
+
+The group briefly discussed the now-accepted Tasks proposal (#1686) from the 11/25 specification release. The current proposal doesn't currently appear likely to change in a significant breaking way when promoted from its experimental state. Minor breaking changes such as adding new Task statuses remain possible. Partial results could be a significant breaking change depending on how exactly they're proposed, which will need to be handled carefully.
+
+### SEP-1792: Add `agencyHint` Tool Annotation
+
+The proposal (#1792) was introduced to the group, with discussion focusing on how `agencyHint` differs from existing annotations like `openWorldHint` and `idempotentHint`.
+
+It was noted that this addresses a common concern: developers want to know if a tool will be "agentic" in order to apply governance policies and additional UX controls.
+
+However, the use case still felt somewhat vague to some participants. The underlying need for a more complex set of indicators about the behaviors of tools may suggest that we need a more generalizable system for tool governance. Since hints cannot be easily consolidated if we end up with redundant ones, careful consideration is warranted before adding new ones.
+
+For the time being, @LucaButBoring will work with the SEP author to finalize the proposal and raise it to the Core Maintainers for further discussion.
+
+### Issue #1917: Add Pending or Submitted Status to TaskStatus
+
+This issue was raised for initial thoughts from the group. The group discussed a specific example of a task dispatched to a worker pool as a practical scenario where there could be a meaningful difference between "submitted" and "working" statuses.
+
+A "submitted" status would be useful in that it would enable a more transactional execution model, where a task is only marked as "working" once a worker picks it up from a queue. However, it is still unclear how other systems would benefit from seeing this additional status. A "submitted" status was originally included in #1686, but was ultimately dropped as no client implementations were able to meaningfully benefit from it.
+
+@LucaButBoring will follow up with the issue author to determine if there is a concrete use case that the new status would enable.
+
+### SEP-1904: Add Filtering Support for `tasks/list`
+
+This proposal (#1904) was introduced with a note that it may fit better under the Primitive Grouping WG, as they're already planning to build filtering uniformly across the protocol on top of Groups.
+
+Concerns were raised that this may be nontrivial for servers to support, considering both the range of filter operators and how filtering interacts with pagination, whereas it is very easy for clients to do this filtering themselves. This mirrors the same reasons tool filtering gets pushback.
+
+Several members of the discussion wanted to see concrete evidence that the lack of filtering is a significant pain point for servers before supporting the proposal, as Tasks are still new and the full range of potential scaling challenges remains hypothetical.
+
+### SEP-1905: Task Result Streaming and Immediate Result Acceptance
+
+This proposal (#1905) was introduced with a note that @LucaButBoring made a recommendation to split it into two separate SEPs: one for partial result streaming and one for polymorphic immediate results.
+
+An alternative approach was suggested during the discussion to solve partial results at a general request level, and then to allow Tasks to simply inherit the same mechanism. The challenges associated with creating a schema for partial results are inherent to JSON-RPC.
+
+It was also noted that A2A solves this for its Task primitive in its JSON-RPC protocol binding in a way that MCP could follow.
+
+The idea of breaking out of the JSON-RPC envelope altogether was also raised, which would extend to binary streaming very well in the future, though that would be a much more radical change to the protocol and would likely face much more resistance.
+
+### Schedule Note
+
+The next two meetings may be canceled due to holiday travel being expected to reduce attendance. A decision will be made on this within the next week.
+
+## Follow-ups
+
+- **SEP-1792**: @LucaButBoring to summarize the feedback and relay it to the SEP author. Once other minor issues (such as the reference to the now-removed `taskHint`) are addressed and a PR is raised following the new SEP format, @LucaButBoring will raise this to the Core Maintainers for further review.
+- **Issue #1917**: @LucaButBoring to relay feedback to the issue author.
+- **SEP-1904**: @LucaButBoring to relay feedback to the SEP author.
+- **SEP-1905**: @LucaButBoring to relay feedback to the SEP author.
+- @LucaButBoring to decide whether or not to cancel the next two meeting occurrences.

meetings/2026-01-13.md

@@ -0,0 +1,32 @@
+# 2026-01-13 Agents WG
+
+> Originally published as https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/2081
+
+**Date:** January 13, 2026
+**Attendees:** Luca Chang, Peter Alexander, Shaun Smith, Jamu Kakars, Michael Milstead, Vinay Ramesh, Lachlan Heywood, @thoorp
+
+## Discussion
+
+### Immediate Plans
+
+**SEP-1938** has been raised to the Core Maintainers for review but has not yet been discussed by them.
+
+**Tasks stabilization** remains the primary focus. Stabilization requires usage data to inform further decisions, which in turn requires unblocking developers from building on the experimental Tasks primitive. The current goal is expanding support in client applications. The Everything MCP server and MCP Inspector are have in-progress integrations, and Luca is working on integration in several AWS projects. Once developers build on Tasks, their feedback will inform how the WG addresses follow-up proposals and stabilizes the specification.
+
+The working group remains open to new priorities as well.
+
+### Implicit/Explicit Session Creation and Session Tokens
+
+Shaun introduced the [brief](https://docs.google.com/document/d/1W0pJMbZUCVwo7SLpxgujrr-3yHvOzfLgaZqRsh7Z-CA/edit?usp=sharing) for the Transports WG's Sessions track, which is of particular interest to the Agents WG as it affects how state is owned by different parties in multi-agent interactions over MCP. The Transports WG's next objective is to divide-and-conquer the many planned HTTP transport and protocol revisions for the June specification release. Shaun is leading the Sessions sub-group, which aims to decouple sessions from connection state. The first major TWG meeting for the year will be on January 14, 2026 (tomorrow).
+
+The Sessions sub-group is looking at a cookie-style mechanism for connection-level statelessness, but hasn't yet decided on if session creation should be implicit when the client executes an operation against a server, or if it should be explicit via introducing new RPC methods. This concern also affects client applications more broadly - there are UX questions around whether a session should be scoped to a single chat (in applications with chats) or scoped to an entire application.
+
+Peter noted that this is also of interest to the TypeScript and Python SDK maintainers, as it will potentially affect the design of the v2 SDKs in each language.
+
+The Agents WG will continue to be involved in this initiative.
+
+### Agent Discovery and Interop Surfaces
+
+Vinay raised the topic of how MCP, A2A, and similar protocols should enable agent-to-agent interaction. The idea he introduced is that these protocols should be able to support something that looks like a chat completions call for interacting with remote agents, which may or may not be stateful and/or have an internal tool loop. Sampling isn't sufficient for this use case as it's server-to-client rather than client-to-server. @thoorp highlighted similar work in IDEs to be able to represent calls to an agent as a sort of tool over MCP. @thoorp also noted that `agencyHint` (#1938) is along these lines and is, in addition to being a governance tool, an explicit codification that agent-driven tools exist from the perspective of the protocol.
+
+The group will return to this in the next meeting after discussing these ideas in more detail.