Every workflow I've shipped

Meridian Advisory processes vendor invoices by hand: someone opens each emailed PDF, retypes the totals into a spreadsheet, and eyeballs the numbers. Two failure modes recur and both cost real money when missed, line items that don't add up to the stated total, and the same invoice getting paid twice because it was re-sent.

• Watches a Gmail inbox for PDF invoices, no manual upload step
• Gemini extracts invoice number, vendor, totals, and dates as structured fields
• Recalculates the line item sum independently and flags any mismatch down to the exact dollar difference
• Duplicate invoice numbers are caught and filed to a separate audit tab, never double logged
• Only a genuine anomaly triggers a Slack alert, valid invoices log silently so the channel stays useful
• Every invoice lands in one sortable Google Sheet with status and a processed timestamp

This replaced a manual review step that depended on someone catching a bad total by eye. Every invoice now gets checked the same way, every time, and the only thing that reaches a human is something that actually needs a decision.

An LLM agent is good at understanding what a customer wants. It's a bad place to put the actual source of truth for anything transactional, since a model can misremember, get talked into contradicting itself, or simply be wrong with total confidence. Scheduling needs something underneath it that can't be talked out of enforcing a rule.

• Books, reschedules, cancels, and lists consultations through natural conversation on Telegram
• Google Calendar creates the customer-facing event and sends real calendar invites
• Supabase Postgres is the final authority, with database-level constraints that make double booking structurally impossible, not just unlikely
• A customer's own retried request is recognized and confirmed silently instead of being rejected as a false conflict
• Duplicated Telegram message deliveries are dropped before they ever reach the agent
• If the database rejects a booking after the calendar event already exists, the calendar event is automatically deleted so the two systems never drift out of sync

The result is a receptionist that never double-books, never leaves the calendar and the database disagreeing about what happened, and treats its own model's confidence as advisory, not authoritative. That's the pattern I use across client scheduling work, this is the clearest, smallest version of it I could build end to end.