My agents know everything about me. Why didn't one of them say happy birthday?

My friend Ben asked me a question a while back that I haven't been able to shake:

"My AI agents know everything about me. My calendar, my email, my files, what I ate last Tuesday. Not one of them ever wished me a happy birthday."

Ha! Fair. WTF, right?

The more I thought about it, the less this looked like a bug in any one agent. The data, the permissions and the plumbing just aren't there. So I built the missing piece. It's called birthdaycalendar.si, and this post covers why agents miss birthdays, what's missing, and how people, businesses and agents all hook into it without it turning into a spam cannon.

Why agents miss birthdays#

You'd think a birthday is the easiest fact in the world. It's one date. It repeats every year. But look at where that date actually lives today:

• Facebook, but only if you never turned it off, and good luck getting it out with an API.
• Your contacts app, filled in for maybe 10% of people, half of them wrong (hello, 01/01 placeholder dates).
• A Google Calendar event someone made in 2014 that says "Mom bday??".
• A loyalty app at the taco place, which wants your full birth date, email and phone number in exchange for free chips.

So when your agent goes looking, it finds a mess. There's no source of truth, no consent attached, and no way to tell whether a date is yours to share or just scraped from somewhere.

Then there's the bigger issue. Agents are (rightly) careful about acting on your behalf. Sending a "happy birthday!" to the wrong person, on the wrong day, or to someone who never wanted you to know their birthday is creepy. An agent that guesses is worse than one that does nothing.

So the agent does nothing. And Ben gets nothing.

What's missing: a consented, structured birthday layer#

What I wanted was boring in the best way. It's one place where:

1. You store your own birthday. Nobody else types it in for you.
2. You decide who gets to see it, one approved connection at a time.
3. It's structured: date, wishlist, things you love, things you don't ("no thanks" to scented candles, please).
4. Agents can read it and act on it through a standard interface, with your permission.

That's it. That's the layer. Everything else gets built on top of it.

How it works for people#

You sign up with your email, which is the only identity we use. We never match people by name, because there are about a million John Smiths. You add your birthday, a photo and your city. Done. It takes about a minute.

Then you get:

• A public page at /yourname with your name, mm/dd only (never the year), and your about list. There's no email or other PII on it, so there's nothing worth scraping.
• A wishlist and Loves / No thanks lists, so your friends stop guessing.
• Email reminders for your friends' birthdays, sent at 8am in your time zone. You don't configure anything.
• Connections that are always approved. Someone can hit Connect on your page, open your private ask link (/a/{token}), or scan your QR code. Nothing is shared until you say yes.
• Greetings, either as public wall posts or private messages, from connected friends (and brands, more on that below). Every greeting waits for your approval before anyone else sees it.

It's supposed to feel like a celebration, not a CRM. So there's no "missing data" nagging and no 40-field forms. Ask for what you need and nothing more.

How businesses hook in (safely)#

This is the part that gets me excited, and also the part I was most paranoid about.

Every business loves birthdays. Bill's Tacos wants to give you a free taco on your birthday. Sam's pet store wants to send your dog a treat. Today they do that by asking for your full birth date, email and phone at the register and dropping it into some loyalty app you'll never think about again.

Here's how it works on birthdaycalendar.si instead:

• You opt in. You scan Bill's QR code at the counter or hit Connect on his page. That's the only way a brand gets connected.
• The "Birthday treats" toggle is OFF by default. Connecting to a brand doesn't mean you get treats. You have to flip it on.
• Brands never get your email or your birth date. Bill gets a heads-up that a customer's birthday is coming up, plus whatever likes you chose to share. That's enough to send a great treat.
• Treats are matched by city/state, so a taco place in Pittsburgh isn't pinging someone in Phoenix.
• You pick the delivery. Treats can go to your birthday inbox, and/or to the brand's own channel if you give consent.
• It's still owner-approved. A brand greeting goes through the same approval as a friend's.

For the business, it stores the customer record and preferences and has birthday campaigns built in. It's not a full CRM, and that's on purpose. It does one job: making birthdays work for people who actually asked. There's also a team version for companies, with Slack/Teams alerts and a team board, so nobody misses a coworker's birthday or work anniversary.

How agents use it: MCP#

Back to Ben. This is the part that actually answers his question.

Agents connect through MCP (Model Context Protocol), which Claude, ChatGPT, Cursor and friends already speak. You create a scoped token in the app (or sign in with OAuth from a connector), and your agent can:

• read your upcoming birthdays and what each person loves (and doesn't),
• check a wishlist before suggesting a gift,
• draft a greeting or a reminder.

Here's the important bit: in v0 agents draft, you tap Send. Every call shows up in an activity log, and writes can be undone. Just let the bot do it... after you approve it 😉

Brand agents use MCP too. Bill's agent can see "3 opted-in customers have birthdays this week" and queue treats, without ever touching anyone's email or birth date.

So the next time Ben's agent checks his morning, it can say, "Hey, it's Amy's birthday Friday. She loves hot sauce and said no thanks to candles. Want me to draft something?" And on his birthday, his friends' agents get the same heads-up, because he chose to share it with them.

Privacy and anti-spam (the edge cases)#

I love edge cases, and a birthday network has a LOT of them. A few of the guardrails:

• Verified email is the only identifier. No matching by name, ever.
• No year on public pages. mm/dd is enough to celebrate and useless for identity theft.
• Sender limits. New accounts can send only a handful of connect requests a day, and the limit grows as you build real connections. Getting requests is unlimited, because the limits only apply to whoever is sending.
• No probing. A profile that doesn't exist and a private one return the identical response, so you can't check whether /john or /adam exists. Fan-out and dictionary-style patterns get flagged.
• No guessable add links. Ask links are random tokens, not /username/add.
• Owner approval on everything. Connections, greetings and brand treats all need it.
• No ads, no selling data. Ever.

Take it with a grain of salt. No system is perfect, but the defaults are set so the lazy path is the private path.

Open source vs hosted#

The whole personal product is open source and self-hostable: your page, wishlist, reminders, MCP and import/export, with no limits. If you're a homelab nerd (respect), run it on your own box.

Self-hosted servers talk to each other and to birthdaycalendar.si through federation. Your cousin on family.example signs in with their handle, their server proves who they are with a signed key, and you connect like anyone else.

Hosted at birthdaycalendar.si is for everyone who just wants reminders that show up on the right day, every year, without messing with DNS and email deliverability. The brand and business features live on hosted.

So, Ben...#

Your agents didn't forget your birthday. Nobody ever gave them permission to know it. Now they can ask.

Go grab your page, add your wishlist, and share your link with a few people you actually like. Then hook up your agent and see what it does with it.

What would you want your agent to do on a friend's birthday? I'm genuinely curious. More to come.

Voice-check note: I leaned on the coffee-chat opener, lists with bold lead-ins, edge-case focus, "take it with a grain of salt", "just let the bot do it" and an open question to close. Worth punching up: the real Ben story (placeholder above) and a Pittsburgh business example in place of Bill's Tacos if you have one.