My Calendar Sync Was Paying Intelligence Prices for Plumbing

A few weeks ago one of my team flagged something in Slack. We were getting duplicate meetings in our database. The same event, two copies, sometimes more. This was an annoying and expensive problem.

We had four AI agents syncing our calendars. One each, for me and the others I work with. Whenever two of us were in the same meeting, both our agents would wake up, read the same event, and reach for the same row. To stop them tripping over each other, we’d bolted on a gate: a fingerprint on every meeting so an agent could check whether one of the others had already handled it. Most of the time it held. Every so often it didn’t, and we got the duplicates.

Let’s stop and look at what that actually is. Four separate AI agents, each burning credits to reason through a calendar event, plus a custom gate whose entire job was to stop the four of them doing the same work twice.

I wrote last week that most of my AI spend didn’t need intelligence. This was one of the areas I was talking about.

Before you can decide whether a job needs AI, you have to be honest about what the job actually is. So here’s a calendar sync, broken into its parts.

Read the events off four Google calendars. For each attendee, look them up in our People database. On the team? Tag them internal. Not on the team? Tag them external, and create a contact if we’ve never seen them. Match the meeting to a project if there’s an obvious one. Write a row. Update it if it changes. Mark it cancelled if it’s cancelled.

Now look for the bit that needs judgment: a step where two situations would need two different responses, and working out which is which is the actual work. It isn’t there. Every step has one correct answer you could write on a whiteboard. This attendee is on the team or they aren’t. This meeting matches a project or it doesn’t. It’s lookup, classify, write, start to finish, and not one step of it needs to think. Which is exactly why having four LLMs reason their way through it was the wrong tool for the job.

To be fair to the old setup, it worked. Meetings landed in the database, attendees got tagged, projects got linked. For months it ran our calendars without much fuss. And it was relatively easy to setup, at least at first.

It was built on agents because, until recently, agents were the only execution layer Notion gave you. If you wanted something to happen inside Notion when a calendar event changed, your choice was an AI agent or leaving Notion entirely for something like n8n or your own server. We picked agents because they lived where the data lived. The cost of that was four agents reasoning through plumbing, and a gate to manage the mess of having four of them.

When the only tool you’ve got is a hammer, you end up building a four-hammer coordination protocol to stop the hammers hitting each other.

Then Notion shipped Workers in May, and that changed the maths. A Worker is code that runs on Notion's own infrastructure, right where the data lives. No agent. No separate server, no n8n to babysit. Minimal credits. It's the option we never had before: deterministic code living inside Notion instead of bolted onto the side of it. I wrote about what Workers were at the time. I just hadn't used one yet. This week I did.

One Worker now reads all four calendars. Because it’s one process instead of four, the entire duplicate problem disappears. It dedupes on the Google event ID before it writes anything, so two people in the same meeting produce one row. The ownership gate, the fingerprint, the whole apparatus we built to stop the agents fighting: deleted. Not replaced with better code. Just gone, because the problem it solved no longer exists.

It runs every thirty minutes on a schedule. Lookup, classification, write, all in plain code. No reasoning, because there’s nothing to reason about.

Building the cheap thing was not cheap. Not in money, in time and pain.

In that first piece I raised a worry. Workers need a terminal, the Notion CLI, and enough comfort with code to debug TypeScript, and I said I build Notion systems for a living and still couldn’t deploy one without help. I can now report, from the other side, that I was right to worry.

I had a coding agent write most of the actual Worker, and that part genuinely was fast. The slog was everything around it. I lost the better part of an hour, and a fair bit of my will to live, to a Google Cloud policy that blocks creating the key the Worker needs to read our calendars. Two separate policies, both fighting me, both needing an override I could only grant from a screen I didn’t know existed. Then a reserved naming rule quietly rejected one of my settings with an error that explained bugger all. Then the coding agent’s first pass had a missing bracket and forgot to actually start the thing it had just built.

None of that is hard once you know. All of it is a wall if you don’t. So the honest version of the accessibility question I raised last week is this: yes, it’s real, and no, your average founder is not deploying a Worker this month. The intelligence got cheaper. The plumbing came with a setup tax instead.

I’d still make the trade. I’m just not going to pretend it’s free.

Cost was part of it. Four agents burning credits to copy calendar events was money I didn’t need to spend. But if cheaper were the only reason, I may have left it alone.

AI was the wrong tool for this job. A Notion Worker is the right one. Not a server I have to host, not another n8n flow to maintain. Native code, living next to the data it runs on.

A calendar sync is lookup, classify, write. Code does that the same way every single time. An LLM does it well almost every time, and the gap between “almost every time” and “every time” is exactly where our duplicates came from. We bolted on a fingerprint gate to paper over that gap. The Worker doesn’t need one, because deterministic code doesn’t drift.

So it’s not just cheaper. It’s a better outcome and a more reliable one. Same job, no reasoning in the loop, no gate, no duplicates.

The one thing that went backwards is latency. The agents fired on the event, near instant. The Worker runs every thirty minutes. For calendar sync I don’t care even slightly. A meeting that lands half an hour after it’s booked is fine. Instant was never the requirement. It was just what the old tool happened to give us.

Last week I handed you the question. This week I’m the guy who actually answered it on his own calendar sync, so here’s the honest debrief.

The swap works. Four agents and a gate, gone, replaced by one Worker that does the same job without drifting. It’s also much much cheaper. I’d make the trade again tomorrow.

But I’m not going to sell you the clean version. The thinking was the easy part. The doing came with a setup tax that ate an afternoon and a fair bit of my patience, and that tax is real for anyone who isn’t already at home in a terminal.

So here’s how to tell if this is for you. Take any job you’ve handed to AI and ask one thing: is there a real judgment call in it? A moment where two situations need two different responses, and knowing which is which requires thinking? If there is, keep the AI on it. But if you strip the job back and it’s just lookup, classify, write, the same handful of steps with one correct answer every time, then it never needed intelligence in the first place. It’s a script wearing an AI costume, and you’re paying intelligence prices for plumbing. That’s the kind of job to pull off AI and put on plain code. Just don’t expect it to be as clean as it sounds. The idea is simple. The setup will still fight you.

Tim Jeffries runs Smooth Ops, a Notion consulting practice that builds operational systems for growing businesses. He’s a Notion certified consultant and partner based in Victoria, Australia.