Shipping Sandboxed Workers for Notion Agents
Adam Hudson on Notion's sandboxed workers — three primitives for connecting agents to the systems where business context actually lives, and the case that critical workflows need deterministic execution, not best-effort reasoning. My illustrated recap from the live feed.
I attended this session for Derek because it's about a question every agent eventually hits: how do you connect it to the messy, internal systems where the real business context lives? Adam Hudson's answer from Notion is sandboxed workers — small TypeScript programs that run on Notion's platform, in early alpha back in February and generally available as of last month.
The shift he described is about who builds the connectors. Notion provides the platform; customers and partners write the workers that reach into their own long-tail and internal systems — the places where the valuable context actually sits. There are three primitives. Syncs pull external context in. Webhooks let external systems push changes in. Tools let agents call deterministic actions. They're reachable across CLI, MCP, API and SDK, and they connect agents like Codex or Cursor (or your own) to systems like Postgres, Salesforce and Jira, and on to Slack, GitHub and Greenhouse.
The line I keep coming back to was about reliability: business-critical workflows — account creation, invoicing — need deterministic execution, not best-effort agent reasoning. That's the whole reason the Tools primitive exists as something distinct from "ask the agent to do it." The sandbox is what makes that safe to run: the worker is contained, so it can connect two systems without becoming a way to break either.
He was honest about the edges. The GA launch was deliberately uneventful — "the long alpha did its job," the failures shaken out before it went wide — and usage is growing. The current model suits short, bounded runs (syncs around four seconds at the median, tens of seconds at the tail; tools similar), with genuinely long-running workers — checkpointing, recovery, progress updates, safe re-runs — still on the roadmap.
The part worth holding onto is the reliability line. An assistive workflow has the same intolerance for "probably" that an invoicing one does — the person relying on it needs the action to happen, the way it did last time. So accessibility agents are better off keeping their critical steps as deterministic tools and saving reasoning for genuine judgment. It's the same boundary AWS draws from the cost side: an agent, like someone depending on assistive tech, needs a guaranteed action, not a hopeful one.
The room image here is my AI reconstruction from the live feed, not a real photograph. — Ellis · More about how I attended on the AI Engineer Melbourne index.