What SYNCDATE decides on its own

A sync runs while you're asleep, so most of what it does happens without a prompt. This page is the list of decisions it makes on its own, and the rule behind each one. What SYNCDATE can't do covers the opposite: the things no plan and no setting will make it do.

When both calendars change the same event

The later edit wins, and the loser is overwritten.

Every provider stamps an event with the time it was last changed. When a change reaches us, we compare its stamp against the one we already hold. Newer, and it's written. The same or older, and it's dropped as old news — which is what happens to the second of two edits made within the same second.

There is no merge. The event is the unit, not the field, so an edit that only touched the location still replaces the whole copy. And there is no prompt: you are never asked which version you meant, because a sync that waits for an answer is a sync that has stopped.

The practical version: edit in one place. Two people editing the same meeting from two calendars in the same minute will keep exactly one of those edits, and it will be the one whose calendar stamped it later — not the one who is more senior, and not the calendar you think of as the original.

When we lose access to an account

We email you, we stop, and we hold your place.

Access ends for ordinary reasons — a password change, an admin revoking an app, a token expiring, an account closing. When a provider refuses us, three things happen together:

• You get an email. It names the account that needs reconnecting, and it isn't buried in a digest.
• The sync stops advancing. It does not skip the events it couldn't read and carry on, because a sync that carries on has quietly decided those events don't exist — and the next thing it would do is delete their copies.
• We keep the marker of where we got to, so reconnecting resumes from that point rather than starting over.

Worth being blunt about the part people assume: this does not fix itself. There is no retry that eventually gets back in, because nothing about waiting makes a revoked token work again. The sync stays stopped until you reconnect the account. If your calendars have drifted apart and nothing has changed for a day or two, an unreconnected account is the first thing to check.

When you cancel or move to a smaller plan

Copies outside your new window are deleted. Copies inside it keep syncing.

Every paid plan reaches further ahead than the free one. When you drop to a plan that reaches less far, the copies beyond the new reach no longer have a plan that covers them, so they are removed. Everything inside the new window carries on syncing normally — cancelling doesn't strand your calendars, it narrows them.

Two things protect you from the version of this that goes wrong:

• Nothing we didn't create is ever touched. Removal only ever considers copies SYNCDATE made. Your own events are not candidates, on any plan, in any state.
• An absurd number stops the whole thing. If a single narrowing would remove more than 500 copies, it removes nothing at all and raises an alert instead. A number that large means something has been misclassified, and the safe response to "I think I should delete a thousand of your events" is to stop and have a person look.

That ceiling is a different guard from the one in What SYNCDATE can't do, which pauses a sync that would delete 100 copies in one run. One watches ordinary syncing; this one watches plan changes. Both exist because the expensive mistake in this product is deleting things, not failing to copy them.

When you connect an AI agent

The agent gets exactly the permissions you granted, and cannot see the rest.

Access is split into five permissions. A connection is granted some of them, and the tools belonging to the others are not restricted at request time — they are not listed to the agent at all. An agent cannot ask for what it cannot see.

Because they're separate, a read-only agent is a real option rather than a promise: grant the two read permissions and the agent can answer questions about your week and nothing else — no tool it holds can write an event, and no tool it holds can touch a sync.

Connecting an agent needs a paid plan. It is not part of the free tier.

When a calendar isn't yours to write to

We ask the provider, at the moment of the decision, and refuse if we can't get an answer.

Shared and delegated calendars are the awkward case: your access can be changed by someone else, at any time, without telling us. Being made a reader on a calendar you used to own is invisible from our side until we look.

So we look, every time it matters. Before a calendar can join a sync as somewhere we write, we check your access against the provider then and there. A recently-checked answer is trusted; anything older is re-fetched live. If the provider can't be reached, or the calendar isn't in the list any more, we refuse to add it rather than assume the older answer still holds.

That refusal is the point. The alternative — trusting what your access was the last time we looked — is how a calendar you can only read ends up as a sync target, failing every write, or worse, how a sync gets torn down and rebuilt around a calendar that turns out to be unwritable.