Notion just became a control panel for the agents I already built
Notion shipped a developer platform last week with hosted code workers, an external agents API, and two-way webhooks. The question for solo operators is whether you should rent the runtime or keep owning it.

Notion shipped a developer platform last week.
Workers, which is hosted code that runs inside the workspace. An external agents API, so any agent can read and write Notion the same way the in-product agents do. Two-way webhooks. Database sync to Postgres, Zendesk, Salesforce. Claude and Codex shipped as launch partners.
For a solo operator who already runs their own agents on their own machine, talking to their own databases, the question this launch forces is whether the right move now is to keep owning the runtime or to fold it into a workspace someone else maintains.
The honest answer is not the one I expected.

What owning the runtime actually buys you
The reason I run my stack on my own machine is not technical purity. It is that I want the agent to read my email, watch my calendar, sit on my WhatsApp, talk to my CalDAV, and remember the shape of my week without any of that data leaving the box. The Notion launch does not change that calculation. Workers run inside Notion's infrastructure. The data they touch is the data already in Notion or in connected systems.
That is the right boundary for the work I would actually move to a Worker. Not the email agent. Not the calendar agent. The pieces that already live in Notion as databases.
What renting the runtime actually buys you
A Worker that runs inside the workspace is one that another operator on the team can see, edit, and trust. It is one that does not depend on my laptop being awake. It is one that survives me being offline for a week. It is one that any future hire can pick up without needing to learn the local toolchain.
For any operator running a one-person shop today and planning to bring on a second person later, the Worker pattern is the answer to the question they have not yet asked.
The cut
The split I am making is simple. Anything that touches the calendar, the inbox, or the chat thread stays on my machine. Anything that lives as structured data in a workspace database moves into a Worker.
The interesting part is what becomes possible at the boundary. A Worker that watches a database for a new lead, triggers a webhook back to my local agent, which then sends the WhatsApp message and writes the reply log back to the same database. The runtime split lets the right thing run in the right place.
This is the second time in three years a platform has moved its API ceiling high enough that an indie operator can build something that used to take a team. The operators who notice it first build the lead.

If you want me to look at where your tools could be split between hosted and self-run, book a 15-min call.