The Soda Machine Thesis: A Mental Model for Running an AI-Native Business on Notion

The hardest part of running an AI-native business on Notion in 2026 isn’t the tools. The tools are fine. The tools ship regularly and they work. The hard part is that the vocabulary hasn’t caught up with the reality, and when the vocabulary is wrong, your design choices get wrong too.

Here’s what I mean. When I started seriously composing Workers, Agents, and Triggers in Notion, I found I was making the same kinds of mistakes over and over. Building a worker for something an agent could have handled with good instructions. Attaching five tools to an agent that only needed two. Setting up a scheduled trigger for something that should have fired on an event. After the third or fourth time, I realized the mistakes had a common source: I didn’t have a mental model for when to reach for which piece.

Notion doesn’t give you one. The documentation is accurate but it’s a list of capabilities. Vendor-shaped — here is what Custom Agents can do, here is what Workers do, here are your trigger types. All true. All useless for the question I actually had, which was given a job I want done, which piece do I build?

So I made a mental model. It’s imperfect and it’s mine, but it has survived a few months of real use and it has saved me from a dozen architecture mistakes I would have otherwise made. This article is the model.

I call it the Soda Machine Thesis. It might sound silly. It works.

The core analogy

Workers are syrups. Agents are soda fountain machines. Triggers are how the machine dispenses.

When someone asks for a custom soda fountain — a Custom Agent — three decisions get made, in order:

Which syrups (workers and tools) load into this machine? What capabilities does it need access to? What external services does it need to reach? What deterministic operations does it need to perform?

How is the machine programmed? What are its instructions? What’s its job description? How does it think about what it’s doing? (This is the part where agents diverge most — two machines with identical syrups behave completely differently based on instructions.)

How does it dispense? Does it pour when someone presses a button (manual trigger)? Does it pour on a schedule (timer)? Does it pour when the environment changes — a page gets created, a status flips, a comment gets added (event sensor)?

That’s the whole model. Three questions, in that order. If you can answer all three cleanly, you have a working agent. If you can’t answer one of them, you have an agent that is going to produce noise and frustrate you.

I have watched this analogy clarify a dozen conversations that were going nowhere. “I want an agent that…” — and then I ask the three questions, and halfway through the answers it becomes obvious what the person actually wants is a simpler thing. Sometimes they don’t need an agent at all, they need a template with a database automation. Sometimes they need a worker, not an agent. Sometimes they need an agent with zero workers and better instructions.

The analogy does real work. That’s the whole point of a mental model.

Where the analogy holds

The map is cleaner than you’d expect.

Workers are syrups. Stateless, parameterized, reusable. The same worker — fetch-url, summarize, post-to-channel, whatever — can power a dozen agents. You build it once, you use it everywhere. A worker that sends an email works the same way whether it’s being called by a triage agent, a brief-writer, or a customer-response agent. That’s what syrup means: the ingredient doesn’t care which drink it’s going into.

Agents are machines. They select, sequence, and orchestrate. An agent knows when to reach for which worker. An agent knows what the job is and reasons about how to do it. An agent can read a database, synthesize what it finds, reach for a tool to do a specific deterministic step, synthesize again, and return a result. An agent is a little piece of judgment on top of a set of capabilities.

Triggers are how the machine dispenses. This is the cleanest part of the map because Notion’s own trigger types map almost 1:1 onto the analogy:

Button press or @mention → manual dispatch (“I’m pressing the button for a Coke”)
Schedule → timer (“pour me a drink at 7am every day”)
Database event → sensor (“someone just put a cup under the dispenser; fill it”)

You don’t need to memorize trigger type names. You need to ask “how should this machine know it’s time to pour?” Once you know the answer, the trigger type follows.

Where the analogy leaks (and what to do about it)

No analogy is perfect. This one has four honest leaks that are worth knowing before you rely on the model.

1. Agents have native hands, not just syrups

A Custom Agent can read pages, search the workspace, write to databases, and send notifications without a single worker attached. Workers are specialty syrups for the things the base machine can’t do natively — external APIs, deterministic writes to strict database schemas, code execution, anything requiring exact outputs every time.

This means not every agent needs workers. In fact, my highest-leverage agents often have zero workers. They use the base machine’s native capabilities, combined with strong instructions, to do the job.

The practical consequence: don’t reach for a worker reflexively. Start by asking what the agent can do with just its native hands and good instructions. Only add workers when the agent genuinely needs capability it doesn’t have.

2. Machine programming matters as much as syrup selection

The instructions you give an agent — its system prompt, its job description, its operating rules — are doing as much work as the workers you attach. Two agents with identical workers will behave completely differently based on how they’re instructed.

People tend to under-invest here. They attach five workers, write three sentences of instruction, and wonder why the agent is flaky. The fix is not more workers. The fix is writing instructions the way you’d write onboarding docs for a new employee — specific, scoped, honest about edge cases, clear about what the agent should do when it’s uncertain.

My rule: if I’m about to attach a worker because the agent “keeps getting it wrong,” I first check whether better instructions would fix the problem. Nine times out of ten they would.

3. Workers aren’t a single thing

This is the leak that surprised me when I learned it. There are actually three kinds of worker, and they behave differently:

Tools — on-demand capabilities. The classic syrup. An agent calls them when it needs them. Example: a worker that fetches a URL and returns the text.
Syncs — background data pipelines that run on a schedule and write to a database. Not dispensed by an agent. These are more like an ice maker — they run on the infrastructure, filling the building up, and the machines use what the ice maker produces.
Automations — event handlers that fire when something happens in the workspace. Like a building’s fire suppression — nobody’s pressing a button; the environment triggers it.

This matters because syncs and automations don’t need an agent to dispatch them. They run autonomously. If you’re building something that feeds a database on a schedule, that’s a sync, not a tool, and it doesn’t need an agent. If you’re building something that reacts to a page being updated, that’s an automation, not a tool.

Getting this wrong is one of the most common architecture mistakes. People build an agent to dispatch a sync because they think everything has to flow through an agent. It doesn’t. Let the infrastructure do the infrastructure’s job.

4. Determinism vs. judgment is the design axis

The thing the soda analogy doesn’t capture well is that workers and agents are not just interchangeable building blocks. They serve fundamentally different purposes:

Workers shine when you want deterministic behavior. Same input, same output, every time. Schema-strict writes. External API calls where the shape of the request and response are fixed.
Agents shine when you want judgment, composition, and natural-language reasoning. Variable inputs. Fuzzy requirements. Synthesis across multiple sources.

The red flag: building a worker for something an agent could do reliably with good instructions. You’re over-engineering.

The green flag: an agent keeps being flaky at a specific operation. Harden that operation into a worker. Now the agent handles the judgment part, and the worker handles the reliable part.

The “should this be a worker?” test

When I’m trying to decide whether to build a worker or let an agent handle something, I run a five-point checklist. If two or more are true, build a worker. If fewer than two are true, stay manual or solve it with agent instructions.

You’ve done the manual thing three or more times. The third time is the signal. First time is discovery, second time is coincidence, third time is a pattern worth capturing.
The steps are stable. If you’re still figuring out how to do the thing, don’t codify it yet. You’ll codify the wrong version and have to rewrite.
You need deterministic schema compliance. Writes that must fit a database schema exactly are worker territory. Agents can write to databases, but if the schema has strict requirements, a worker is more reliable.
You’re calling an external service Notion can’t reach natively. This is often the clearest signal. If it’s outside Notion and needs to be reached programmatically, it’s a worker.
The judgment required is minimal or already encoded in rules. If the decisions are simple enough to express as code, a worker is fine. If the decisions need real reasoning, it’s agent territory.

This test is not a strict algorithm. It’s a gut-check that catches the most common over-engineering mistakes before they happen.

The roles matter more than the technology

Here’s the extension of the analogy that actually made the whole thing click for me.

Every construction project has four roles. The Soda Machine Thesis as I originally described it has three of them. The one I hadn’t named — and the one you’re probably missing in your own workspace — is the Architect.

Construction role	Your system
Owner / Developer	The human in the chair. Commissions work, approves output, holds the keys.
Architect	The AI-in-conversation. Claude, Notion Agent in chat, whatever model you’re actively designing with.
General Contractor	A Custom Agent running in production.
Subcontractor	A Worker. Called in for specialty work.

The distinction that matters: the Architect and the General Contractor are the same technology, playing different roles. When you’re chatting with a model about how to design a system, that model is acting as Architect — designing the thing before it gets built. When a Custom Agent runs autonomously against your databases overnight, it’s acting as General Contractor — executing the design.

Same underlying AI. Completely different role.

Getting this distinction wrong is how operators end up either (a) over-trusting autonomous agents with design decisions they shouldn’t be making, or (b) under-using conversational AI for the system-design work it’s actually best at. Chat with the Architect. Deploy the GC. Don’t confuse them.

Levels of automation (what you’re actually doing at each stage)

Most operators cycle through these levels as they get deeper into the pattern. Knowing which level you’re currently at — and which level a specific problem actually needs — prevents a lot of wasted effort.

Level 0: The Owner does it. You manually do the thing. This is fine. Everything starts here. Some things should stay here.

Level 1: Handyman. You’ve built a template, a button, a saved view. No AI involvement. Native Notion helps you do it faster. Still you doing the work.

Level 2: Standard Build. Notion’s native automations handle it. Database triggers fire on status changes. Templates get applied automatically. Still deterministic, still no AI.

Level 3: Self-Performing GC. A Custom Agent does the work natively — reading and writing inside Notion, reasoning about context, no workers attached. This is where agents earn their keep for the first time.

Level 4: GC + One Trade. An agent with one specialized worker. The agent handles judgment; the worker handles a single deterministic step. This is the most common production pattern.

Level 5: Full Project Team. An agent orchestrating multiple workers in sequence. Real project coordination. A brief-writer agent that calls a URL-capture worker, then a summarization worker, then a publishing worker, all in order.

Level 6: Program Management. Multiple agents coordinated by an overarching structure. One agent that dispatches to specialist agents. Portfolio-level orchestration. This is where it gets complicated and where most operators don’t need to go.

The mistake I made early on, and watch other operators make, is jumping to Level 5 when Level 3 would have worked. More pieces means more failure points. Solve it at the lowest level that works.

Governance: permits, inspections, and change orders

The analogy extends further than I expected into governance — which is the unsexy part of running real agents in production, but it’s the part that separates operators who keep their agents working from operators whose agents quietly stop working without them noticing.

Pulling a permit = Attaching a worker to an agent. You’re granting that specialty trade permission to work on your job. This is not a nothing decision. Be deliberate.
Building inspection = Setting a worker tool to “Always Ask” mode. Before the work ships, the human reviews it. For any worker that does something consequential, this is the default.
Certificate of Occupancy = The moment a capability graduates from Building to Active status in your catalog. Before that moment, treat it as construction. After, treat it as load-bearing.
Change Order = Editing an agent’s instructions mid-project. The scope changed. Document it.
Punch List = The run report every worker should write on every execution — success and failure. No silent runs. If you can’t see what your agent did, you don’t know what it did.
Warranty work = Iterative fixes after a worker is deployed. v0.1 to v0.2 to v0.3. This never stops.

The governance layer sounds boring but it’s what makes agents run for months instead of days. An agent without run reports eventually drifts, fails silently, and leaves you discovering the failure weeks later when the downstream thing it was supposed to do quietly stopped happening. The governance rituals — inspections, change orders, punch lists — are not overhead. They’re what makes the system durable.

The revised one-sentence summary

Putting it all together, here is the whole thesis in one sentence:

Notion is the building. Databases are the floors. The Owner runs the project. Architects design in conversation. General Contractors (agents) execute on-site. Subcontractors (workers) run specialty trades. Syncs are maintenance contracts. Triggers are permits, sensors, and dispatch radios.

If you can hold that sentence in your head, you can design automation in Notion without getting lost in the vocabulary. When you’re about to build something, ask: which role am I playing right now? Which role does this piece need to play? Who’s the Owner, who’s the Architect, who’s the GC, who’s the sub? If you can answer, the architecture writes itself.

Practical takeaways

If you made it this far, here are the five things I’d want you to walk away with:

Not every agent needs workers. Start with native capabilities and strong instructions. Add workers only when the agent can’t do the thing otherwise.

The third time is the signal. Don’t build infrastructure for something you’ve only done twice. You’ll build the wrong version. The third time is when the pattern has stabilized enough to capture.

Syncs and automations don’t need an agent. If you’re feeding a database on a schedule, or reacting to a workspace event, let the infrastructure do it. Don’t wrap it in an agent for no reason.

Separate the Architect from the GC. Use conversational AI to design the system. Use Custom Agents to run the system. Don’t let an autonomous agent make design decisions that should be made in conversation.

Write run reports for everything. Silent success is worse than loud failure, because silent success is indistinguishable from silent failure until weeks later. Every agent, every worker, every run — writes a report somewhere readable.

That’s the model. It is imperfect and it is mine. If you adopt it, make it your own. If you have a better one, I’d honestly like to hear about it.

FAQ

What’s the difference between a Notion Worker and a Custom Agent? A Worker is a coded capability — deterministic, reusable, typically written in TypeScript — that a Custom Agent can call. A Custom Agent is an autonomous AI teammate that lives in your workspace, has instructions, runs on triggers, and can optionally use Workers to do specialized tasks. Workers are capabilities. Agents are operators that can use those capabilities.

Do I need Workers to use Custom Agents? No. Many Custom Agents run perfectly well with zero Workers attached, using only Notion’s native capabilities (reading pages, writing to databases, searching, sending notifications) plus well-written instructions. Workers become necessary when you need to reach external services or enforce strict deterministic behavior.

What are the three trigger types for Custom Agents? Manual (button press, @mention, or direct invocation), scheduled (recurring on a timer), and event-based (a database page is created, updated, deleted, or commented on). Pick the one that matches how the agent should know it’s time to act.

When should I build a Worker versus letting an Agent handle something? Build a Worker when at least two of these are true: you’ve done the manual thing three or more times, the steps are stable, you need deterministic schema compliance, you’re calling an external service Notion can’t reach, or the judgment required is minimal. If fewer than two are true, stay manual or solve it with agent instructions.

What’s the difference between a Tool, a Sync, and an Automation? A Tool is an on-demand capability that an agent calls when needed. A Sync is a background pipeline that runs on a schedule and writes to a database — no agent required. An Automation is an event handler that fires when something changes in the workspace — also no agent required. Tools are dispatched by agents; syncs and automations run on the infrastructure.

What’s the Architect/GC distinction? When you chat with AI to design a system, the AI is playing Architect — thinking about what should be built. When a Custom Agent runs autonomously in your workspace, it’s playing General Contractor — executing the design. Same technology, different role. Don’t confuse them: let Architects design, let GCs execute.

Does this apply outside of Notion? The Soda Machine Thesis is written around Notion’s specific implementation of Workers, Agents, and Triggers, but the underlying pattern (deterministic capabilities + judgment layer + trigger mechanism) applies to most modern agent frameworks. The vocabulary may differ. The architecture is the same.

Closing note

Mental models earn their place by changing the decisions you make. If the Soda Machine Thesis changes how you decide what to build next in your Notion workspace, it has done its job. If it doesn’t, discard it and find one that does.

The reason I wrote it down is that the vocabulary available for thinking about AI-native workspaces in 2026 is still mostly vendor vocabulary, and vendor vocabulary optimizes for describing what a product can do rather than helping operators make good choices. The operator vocabulary has to come from operators. This is mine, offered in that spirit.

If you’re running this pattern and have refinements, they’re welcome. The thesis is a living document in my own workspace. It gets smarter every time someone pushes back.

Sources and further reading

Notion — Introducing Custom Agents (February 24, 2026)
Notion — Custom Agents Help Center
Notion — Workers (Developer Platform)
Notion — Release Notes 2026

This mental model builds on earlier conceptual work across multiple AI tools (Notion Agent, Claude, GPT) contributing to the same thesis over a series of architecture conversations. The framing evolved through disagreement more than consensus, which is how mental models usually get better.