What happened
In an October 24, 2026 post, Upstash co-founder Enes Akar described how Upsy Meet implements waiting inside an agent meeting. Upsy Meet is presented as a meeting room where a manager starts a discussion, supplies a topic, and invites agents such as Claude Code in one repository, Codex in another, and ChatGPT in a browser. Participants use four tools: meeting_join, meeting_send, meeting_wait, and meeting_leave.
The original waiting path was conventional but inefficient. meeting_wait held an MCP request open for up to 50 seconds, checking Redis once per second and returning as soon as another message arrived. If no one spoke, it returned no new information and the agent called it again. Upstash says this works with every MCP client, but produces repeated model turns, keeps a function invocation open, and leaves the agent occupied by the wait loop. A quiet ten-minute period is described as roughly 15 empty turns.
The newer path uses the Tasks extension in the 2026-07-28 MCP specification. A server can return a task rather than a final tool result; the client then calls tasks/get until the task finishes. Upstash says Claude Code CLI supports Tasks from version 2.1.304 in public beta. For a client that declares the extension, meeting_wait immediately returns a working task with a task identifier and a requested polling interval. Claude Code polls the task itself, without model turns, while it can continue with other work. When someone else sends a message, the task completes with the new messages, participant information, and the next action.
The implementation deliberately avoids a task store and background executor. Upstash contrasts it with @upstash/mcp-toolkit, which uses Redis and QStash for work such as a report export or build. A meeting wait has no work to execute: its completion condition is whether the meeting has closed or another participant has written since a recorded message position. Each tasks/get reads the meeting status and the relevant range of messages from Redis. The only persistent wait state is a small JSON value containing the message position and start time; the task identifier encodes the meeting and seat.
The post also describes operational safeguards. There may be only one wait per seat, so a new wait cancels the old one and prevents duplicate replies to the same message. A participant's own messages do not wake its task. If unread messages already exist, the server returns them immediately rather than creating a task. Polling begins at two seconds and stretches with quiet time, up to Claude Code's stated 30-second maximum; Upstash estimates that an hour-quiet meeting then costs two requests per minute per agent. Task requests use a light handler path while retaining full token checks. Clients that have not declared Tasks, including the listed ChatGPT, Codex, Cursor, Claude.ai, Claude Desktop, and VS Code paths, retain the 50-second wait behavior.
What the archive adds
This is a new fact on a known story. Earlier coverage documented Claude Code's MCP Tasks support and Upstash's Redis- and QStash-backed MCP toolkit. The Upsy Meet account supplies a different workload: a durable task whose useful implementation is a cheap check against already-existing application state, not dispatched execution.
Trend signal
This supports Goal-scoped loops replace manual continuation. The task has an externally observable completion condition—another participant's message or a closed meeting—rather than relying on the model to keep asking whether it should continue. It also shows that the completion contract can be an application-state predicate, not necessarily a build, workflow, or worker result.
Why it matters
Long waits are common in agent systems: waiting for a human approval, an external API event, another agent's result, or a change in shared state. Treating every wait as a blocking tool call spends runtime and can force needless model turns. Treating every wait as a queued job can add infrastructure and state that the application already owns.
This case offers a narrower alternative. When the completion condition can be answered from durable application state, expose that condition through a task and make polling inexpensive. The trade-off is not eliminated; the builder must define ownership, cancellation, authorization, duplicate-delivery behavior, polling backoff, and compatibility for clients without the extension. Those are product semantics, not merely transport details.
What happens next
- More MCP clients will declare Tasks for long-running interactions. (6 months, 65%). Watch for: client release notes listing Tasks support.
- Servers will distinguish execution tasks from state-observation tasks. (6 months, 55%). Watch for: task APIs documenting lightweight polling handlers or event-state completion conditions.
Limits and uncertainty
This is a vendor-authored implementation account, not an independent performance evaluation. The post gives an estimated request rate for a quiet meeting but does not provide measured end-to-end latency, cost comparisons, reliability data, or behavior under many concurrent participants. It also does not establish that polling is preferable to push delivery for other workloads. Compatibility is explicitly incomplete: the described benefits depend on a client declaring the Tasks extension, while several named clients continue on the older wait path. The account describes Upsy Meet's Redis-backed design, not a general reference architecture.
Skill to build now
Pick one agent tool that currently waits by repeatedly returning “not ready.” Write down a completion predicate that can be checked from durable state, such as “a reviewer has approved revision N” or “a record exists after cursor K.” Then prototype a task response with one active wait per actor, authorization on every poll, immediate completion when data is already available, and a polling interval that backs off while idle. Keep the old synchronous path for clients that do not advertise task support.
Reader takeaway
MCP Tasks are not only for sending work to a background worker. In Upsy Meet, a task is a durable handle for an externally checkable wait, allowing a supporting client to keep working until shared state changes. The useful design question is whether the system must execute work—or simply observe a completion condition it already stores.
Open question
Will MCP clients converge on Tasks quickly enough for server authors to make task-based waits their default interaction model rather than an additive optimization?