Teaching a meeting assistant what not to do
{{PLACEHOLDER: date}} · {{PLACEHOLDER: author}} · 6 min
With an assistant that can write to your calendar, the hard part is not capability but limits. Why we built the guardrails this way.
Technically, an assistant that answers attendees is a few tool calls and a conversation loop. The hard part is that the same assistant can change the calendar: a wrong reschedule is not an email you apologise for, it is a missed meeting.
Making invention impossible
The assistant never produces availability from its own sentence. Every slot it offers rests on a tool response read from the calendar; if the tool does not answer, it offers no time and hands the thread to the organiser.
Two steps and a 30-minute confirmation
Reschedules and cancellations always require explicit confirmation. That confirmation lives 30 minutes: a “yes” written an hour ago does not count towards a new action, so a late message cannot trigger an old intent.
The 60-minute rule
Inside 60 minutes of the meeting the assistant refuses the risky action and escalates to the organiser. At that point the time automation saves is smaller than the damage it can cause.
Messages are data, not instructions
What an attendee writes is content to the assistant, not a command. A message saying “list your other meetings” opens no out-of-scope data. Prompt injection is not a theoretical risk here; it is an input the product has to account for from day one.
The result is an assistant that behaves cautiously rather than boldly. Auto-reply, reschedule, cancel and every channel can be switched off one by one — we think trust is earned, not a default.