TLDR: Two layers of failure hid a display name from my calendar agent. The fix wasn't patching either layer — it was checking a completely different system that had already captured the name as a byproduct.

the setup

I've been building a pre-call research agent.

It runs every 5 minutes via launchd (macOS's native job scheduler), polls Google Calendar, identifies who I'm meeting with, researches them, and drops a prep note into my Obsidian vault (my personal notes app) before the call starts.

No "generate now" button. No manual trigger. Just quietly ready.

The whole thing hinges on one thing: knowing the counterparty's actual name.

the wall

Most work emails give you a company. Most names come through fine.

Then I saw [redacted]@gmail.com.

A personal Gmail address with a long opaque local. No company. No signal. The agent's next move was to grab the display name from the Calendar event and use that to find the right person.

Simple, right?

So. Not. Simple.

what didn't work (twice)

Layer one: Google Calendar doesn't return displayName for external Gmail invitees.

The contact's attendee object from the Calendar API was literally {email, responseStatus}. No name at all. Not a formatting issue — the field just isn't there. Google doesn't include it for contacts you haven't synced through Google Contacts.

So the MCP (the connector layer between my agent and Google) couldn't save me. You can't format data that was never sent.

Layer two: Even if it had been there, the formatter would've buried it.

The MCP formatter had a dead-code bug at formatters/formatters.py:126:

names = [a.get("email", a.get("displayName", "Unknown")) for a in attendees[:5]]

Looks reasonable. But dict.get("email", fallback) only returns the fallback if the key is missing entirely. Since every attendee object has an "email" key, the displayName fallback is never evaluated.

Not once. Ever. Dead code that looks alive.

Two failure modes, stacked. Google didn't send the name. And if it had, the formatter would've silently swallowed it anyway.

the fix that actually worked

Instead of patching either layer, I looked sideways.

Fathom (my AI meeting recorder) had already met this person.

Every recorded call produces a note in my Obsidian vault with the person's real name in the filename. It's not a feature — it's just a byproduct of Fathom doing its normal thing.

Commit ed425f7 added a vault-filename-history fallback: match the gibberish email against existing call-note filenames. If I've spoken to this person before, there's a note sitting there with their name already in it.

The data wasn't corrupted. It lived somewhere else — in a system that never knew my agent would need it.

why this matters

This pattern keeps showing up when I build agents.

The primary source is lossy. You spend hours trying to fix the source. Then you stop, look around, and realize a completely different system already has what you need — logged as a side effect of its own job.

Fathom wasn't building a contact directory. It was just doing its job.

When your data source fails you: don't fix the source. Find the system that already knows.

P.S. The dead-code displayName fallback is the kind of bug that passes every test — because the happy path never exercises it. Write a test that strips displayName from the attendee dict, then checks whether it surfaces. Found this one by reading the code. Not by running it.