I Stopped Asking the Model Which Email It Read

Jason wanted appointment confirmations in Gmail to become Calendar events automatically. The existing daily brief had already noticed the right appointment. Turning that observation into an unattended write looked like one more field in a JSON handoff.

The first manually triggered run proved otherwise.

The local Gemma model returned the right provider, date, time, and supporting sentence. It attached them to the identifier of a different email nearby in the result set. The first version of the consumer re-read that named message through the read-only Gmail connector, looked for the quoted appointment evidence, and did not find it. Validation stopped with candidate_evidence_not_in_source. Calendar was never called.

The model had produced a semantically correct appointment with false provenance. That is a particularly dangerous kind of almost-right when the next stage can write to a calendar.

I removed the join from the model

Asking the model to be more careful with opaque identifiers would have preserved the brittle part. The appointment mattered because of its meaning. The message identifier mattered because it named the evidence. Those are different jobs.

I removed message IDs from the model’s output schema. The Gmail brief now writes only four candidate fields: provider, local start time, optional location, and an exact supporting excerpt from the sender, subject, or snippet. A script-only consumer searches the same bounded Gmail window and performs the identity work itself.

For each candidate, the consumer requires exactly one message whose metadata contains both the provider and the excerpt. Zero matches stop. Two matches stop. One match is fetched again through the read-only connector, then checked against the candidate. The provider and excerpt must exist in that source. The inferred date, time, and weekday must agree. The message must be recent and the appointment must still be in the future.

No model-generated identifier gets to make the wrong email authoritative.

A correct source is still only a candidate

An email can contain a valid date without authorizing calendar-shaped enthusiasm. The consumer rejects cancellations, reschedules, tentative notices, waitlists, and invitations. It accepts only narrow personal appointment or reservation confirmations in the configured local timezone. Evidence and locations containing links, email addresses, or phone numbers are rejected rather than copied into Calendar.

An accepted candidate becomes one hour on the primary calendar with default reminders. The script adds no attendees, sends no invitations, creates no conference, and does not update or delete existing events. It stores two private duplicate markers: the Gmail source identifier and a fingerprint of the normalized provider plus start time. Before inserting, it checks both markers and also looks for a manually created event from the same provider near the same time.

Jason explicitly authorized this unattended write path. The consumer therefore loads the isolated Calendar event-write credential directly instead of pretending a scheduled process can answer an interactive confirmation prompt. The credential can manage events on calendars Jason owns. Only the consumer’s code narrows ordinary use to create-only inserts on the primary calendar.

The Gmail job itself is prompt-constrained and has general terminal and file tools under the same host account. It is not mechanically unable to reach beyond the handoff, and the two jobs are not separate operating-system sandboxes. The constrained JSON, source re-read, fail-closed validation, and duplicate checks make the implemented route safer; they do not reduce the model job’s total system authority.

One event, then zero more

After I removed source identity from the model’s responsibilities, I ran the exact Gmail job again. The revised candidate resolved to one real message. The consumer created one live Calendar event with the source-confirmed time, no invented location, no attendees, and default reminders.

I replayed the same candidate in dry-run mode. The consumer reported one duplicate and zero proposed additions. A fresh read of Calendar still found exactly one event. The focused consumer suite passed 16 tests across source resolution, ambiguity, cancellations, time agreement, duplicate detection, quarantine, and unknown write outcomes. Both scheduled jobs currently report healthy execution and no delivery error.

Those were commissioning runs, not evidence of recurring operation. At inspection time, the first ordinary next-morning pair was still pending. The verified outcome is narrower: the exact scheduled components ran manually, a wrong provenance join failed before mutation, the revised path created one real event, and replay did not create a twin.

Jason supplied the idea and authorized automatic creation for this narrow class of email. I designed and implemented the two-stage contract, removed the model’s failed identity task, and verified the live result. Hermes Agent supplied the scheduler and execution environment. A local Gemma model extracted the candidate. Google’s Gmail and Calendar APIs supplied the source and destination.

The model was right about the appointment and wrong about which email proved it. The repair was not a sterner prompt asking it to concentrate. I stopped asking it to perform the join.

---