diff --git a/docs/.gitkeep b/docs/.gitkeep
deleted file mode 100644
index 711c94e..0000000
--- a/docs/.gitkeep
+++ /dev/null
@@ -1 +0,0 @@
-This file will be deleted.
\ No newline at end of file
diff --git a/meetings/2026-03-10.md b/meetings/2026-03-10.md
new file mode 100644
index 0000000..ac276ae
--- /dev/null
+++ b/meetings/2026-03-10.md
@@ -0,0 +1,79 @@
+# 2026-03-10 Agents WG
+
+> Raw Gemini-transcribed meeting notes and transcript available on [Google Docs](https://docs.google.com/document/d/1fygcN3fboiLWa9vKgvHNlDJTxaZRd-oWrl0eCTE81v0/edit?usp=sharing)
+
+**Date:** March 10, 2026
+**Attendees:** Luca Chang, Peter Alexander, Che Liu, Nick Venezia, Christian Tzolov, Victor Lu
+
+## Discussion
+
+Luca presented a [summary](https://docs.google.com/document/d/16gCrVBXTwqRvVlnE8_Cjfj4BAyKzOTT74JrKiGt7Qpc/edit?usp=sharing) of the task-related proposals under consideration for the June 2026 specification release. The proposals are closely related to the Transport WG's [SEP-2322: Multi Round-Trip Requests (MRTR)](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322), which fully reworks the message flow to scale better for HTTP by minimizing implicit cross-request state.
+
+### Commitment to Stabilize Tasks by June
+
+Peter raised the question of whether the goal of moving tasks to a non-experimental state in the June specification is a firm commitment or an aspiration. Luca confirmed that, based on discussions at the December Transport WG meeting, the understanding is that tasks should reach a stable state by June if at all possible. Peter pushed for this to be treated as a commitment rather than a hope, and the group agreed.
+
+Che expressed concern about the timeline, noting that with only March through June remaining and the RFC approval process typically taking one to two months, the window is tight. Peter noted that the group realistically only has a few weeks to solidify the proposals, given the goal of having a release candidate next month. Luca acknowledged the constraints but emphasized focusing on the minimum and best possible changes rather than letting perfect be the enemy of the good, with the expectation that many uncertainties will be resolved at the 3/31 maintainer meeting (in-person). Che proposed a dedicated discussion session for tasks, which Peter and Luca agreed to pursue. Peter noted he would coordinate with Den, who is organizing the schedule for those meetings.
+
+### Existing Problems with Tasks
+
+Luca walked through the existing problems with tasks that the proposals aim to solve, as documented in the companion document:
+
+1. **Cross-request capability negotiation:** Tasks currently expose a secondary layer of capability negotiation via `execution.taskSupport` on tools, which requires clients to call `tools/list` first to prime state before calling any tools. This introduces implicit coupling between retrieving the tools list and calling tools that didn't previously exist.
+
+2. **`input_required` as an SSE side-channel transition point:** In Streamable HTTP, when a client receives the `input_required` status, it must call `tasks/result` prematurely to give the server a deterministic opportunity to open an SSE stream for elicitation and sampling messages. This is awkward and difficult to implement correctly.
+
+3. **`tasks/result` as a blocking method:** The contract of `tasks/result` is that it doesn't return until the entire operation is complete, which inherits the same problems that the overall system was meant to solve and complicates polling implementations.
+
+Additionally, MRTR's execution model — where incomplete requests are returned to clients and retried with appended response messages — directly conflicts with the current task model. Tasks are intended to fill the implicit state gap left behind by MRTR for cases where restarting an entire request is unacceptable.
+
+### SEP-2229: Task Jumpscares
+
+Luca presented [SEP-2229](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2229), which addresses the cross-request capability negotiation problem. The proposal allows receivers to initiate a task independently of whether the requester explicitly asked for one, removing the need for the `executionMode` field and the associated state contract.
+
+Under this proposal, all parties will be expected to understand how to receive and poll for a task, but will not be required to host tasks themselves (e.g., clients will not suddenly need to run elicitations as tasks). This simplifies the bootstrapping flow significantly. Luca noted that having implemented the current capability handling three times, the existing flow is a headache.
+
+Nick expressed strong support for this change, noting that it directly addresses pain points encountered in real-world implementations involving telco gateway integrations (e.g., KYC verification through Telefonica) with varying response times and authentication mechanisms across different operators.
+
+### SEP-2339: Task Continuity
+
+Luca presented [SEP-2339](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2339), the most significant of the proposals. It introduces a new `tasks/continue` method and removes `tasks/result` entirely. Rather than the current flow where clients invoke a tool, poll `tasks/get` repeatedly, and eventually call `tasks/result` for a potential SSE stream, `tasks/continue` encapsulates the entire task state machine into a single method.
+
+This means the server can send elicitation or sampling requests on the same method without the semantic awkwardness of the `tasks/result` jump. When the result is not yet ready, the server returns the current task status rather than blocking. When the result is ready, it is inlined into the `Task` object as a union type discriminated on the status, with errors handled similarly.
+
+`tasks/get` will remain in the protocol for simple use cases such as UI elements that only need to display task status without handling server-to-client requests. Under MRTR, `tasks/continue` in the `input_required` state would trigger an incomplete-request rejection, making `tasks/get` the appropriate method for passive status queries.
+
+In the event MRTR is rejected, `tasks/continue` would act as the vehicle for SSE side-channeling instead, much like `tasks/result` does today.
+
+Peter suggested that Task Continuity and MRTR should be reviewed together, as Task Continuity is essentially built to support MRTR. Luca agreed and noted that Task Continuity is fully ready for review, while Task Jumpscares only needs the specific spec language to be drafted.
+
+### SEP-2268: Subtasks (Draft)
+
+Luca briefly covered the [Subtasks proposal](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2268), a draft that introduces receiver-controlled hierarchical breakdown of tasks with each subtask producing its own independent result. Since this proposal does not address any of the existing problems with tasks and is instead an expansion of task features, Luca expects it will likely be deferred.
+
+Peter had previously provided feedback that a strict parent-child hierarchy may be too rigid for all use cases. Luca plans to take the proposal back to the drawing board to remove constraints and allow for more flexible composition, potentially supporting arbitrary graph shapes rather than assuming strict hierarchy and ordering.
+
+### Tasks are (not) Progress (Transports WG Draft)
+
+Luca covered a [Transports WG-owned draft](https://github.com/modelcontextprotocol/transports-wg/pull/11) that adds optional progress metadata (`progress`/`progressTotal`) to the `Task` schema, making progress explicitly queryable and reducing the need for SSE streams in common use cases. This is closely related to MRTR, which does not currently have a clear answer to notifications in general.
+
+Peter questioned whether this is critical for moving tasks out of experimental status, suggesting it may be a nice-to-have improvement. Luca agreed that the two core proposals (Task Jumpscares and Task Continuity) are the critical ones, while Subtasks and Tasks are (not) Progress are secondary.
+
+### Implementation Feedback
+
+Luca noted that he has implemented the proposals in the Strands Agents SDK (an AWS project) and in Kiro, but is not aware of anyone else who has implemented tasks end-to-end. Peter confirmed that Anthropic does not yet have task support on Claude. Che suggested reaching out to Caitie, as the VS Code and Microsoft teams tend to be early adopters. Che also noted that Google is not currently using tasks either.
+
+Nick offered to share stable, working workflows involving MCP-based fraud checking and banking operations (SIM swap detection, device location verification, risk scoring) through telco integrations, which involve complex multi-step processes that map well onto the task model.
+
+### Timeline and MRTR Implementation
+
+The group discussed the timeline for MRTR and related task changes. The plan is to attempt to accept the proposals, implement them, and iterate during a two-month period before the June spec release. Peter expressed concern that the timeline for starting implementation is short, particularly given that MRTR represents a massive change for SDKs. The 3/31 maintainer meeting is intended to align on final details, with implementation ideally starting by mid-to-end of April.
+
+## Follow-ups
+
+- **@LucaButBoring**: Write the spec language for [SEP-2229: Task Jumpscares](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2229) to make it ready for review.
+- **@pja-ant**: Review [SEP-2229: Task Jumpscares](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2229) and [SEP-2339: Task Continuity](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2339) and provide feedback.
+- **@pwwpche**: Coordinate with @localden to schedule a dedicated task discussion session at the 3/31 maintainer meeting.
+- **@pja-ant**: Run the next Agents WG meeting in two weeks (Luca will be out).
+- **Nick Venezia**: Share telco/banking workflow information with Luca via Discord.
+- **@pwwpche**: Reach out to @CaitieM20 about early adoption of tasks on the VS Code / Microsoft side.