AI
Why Tasks Need a Protocol Primitive
Adam Azzam framed tasks as an orchestration problem. MCP’s original promise was separating the control plane from risky tool execution. Co-locating an agent with fragile work creates a single point of failure. No amount of retries fixes an out-of-memory error that kills the runtime. Network calls add timeouts and disconnections. SEP-1686 standardizes task IDs, state machines, and result retrieval across servers so every server speaks the same language.
The Client Adoption Stalemate
Azzam showed a slide listing no major client implemented SEP-1686. “That question mark changed to a colon,” he said, pointing to the empty list. He described MCP as a marketplace between client and server capabilities. Portability requires simultaneous demand from both sides. Without client support, servers won’t build for tasks. The ecosystem stalls on handshake-only tools.
Apps as a Bootstrap Mechanism
Azzam proposed using MCP Apps as a backdoor for tasks. The host client calls a server tool; the server returns an app with a task ID. The app embeds an iframe with a polling loop that checks the server for completion. It reveals custom tools for state and results without bloating the context window. This works on Codex, Cursor, Goose, and Claude—clients that adopted the Apps extension.
Demo: Resilient Long-Running Queries in Claude
Azzam demoed a sales query on a local DuckDB that takes 8 seconds. The tool returned control to the user immediately via an iframe. He started a new chat, then returned to see the result still displayed. The iframe polling loop persisted across chat sessions. He refreshed the page and the widget reappeared. This resilience works because the background task is server-side and the iframe is stateless, re-polling on load.
Q&A
How do you handle backpressure when jobs are backed up? Azzam said prescribing backpressure server-side would be ignored by infrastructure teams; SEP authors deliberately left it unopinionated. ▶ Watch (21:27)
Will you open-source the app code? Yes, Prefect provides a Python DSL at prefab.prefect.io that compiles MCP apps from tool return annotations, making the task backdoor simple to use. ▶ Watch (22:31)
Is the iframe approach fragile across different clients? Some clients unmount off-screen iframes, but the biggest ones (ChatGPT, Claude) continue rendering and executing the polling loop, covering an estimated 85% of MCP interactions. ▶ Watch (24:14)
Notable Quotes
“No amount of retries, no amount of resume-ability or whatever is going to solve a problem of an under-provisioned agent trying to download more things into memory than it can” Adam Azzam · ▶ Watch (3:43)
“That question mark changed to a colon, and then that’s more or less the full list” Adam Azzam · ▶ Watch (9:55)
“It’s a marketplace between client and server capabilities, truly.” Adam Azzam · ▶ Watch (10:48)
“It’s embarrassing that I have to build this, right? To get access to tasks, right?” Adam Azzam · ▶ Watch (24:14)
“I would very much like to fire the apps part of this permanently and I would like to bitterly request that clients catch up.” Adam Azzam · ▶ Watch (25:33)
Key Takeaways
- SEP-1686 standardizes task execution but stalled due to zero client adoption.
- MCP Apps offer a backdoor for tasks via iframe polling loops.
- The hack works across Codex, Cursor, Goose, and Claude today.
About the Speaker(s)
Adam Azzam, Ph.D., is VP of Product at Prefect, where he leads product development for their open source automation and context platform. He is a maintainer of FastMCP. Before joining Prefect, Adam co-founded Openrole AI, where he served as CTO building an AI career co-pilot. He was previously Director of Product at Insight Data Science (YC S11). He holds a PhD in Mathematics from UCLA.