Introducing BayDar, because connection is everything

I moved to the Bay Area in July with a specific problem. I've built my whole life in Southern California, with friends and professionals who were passionate about the same work and things we enjoyed. For The Bay, I did not have this. I had some people, but I was in a new (and colder) world now.

So I built a whole event and networking engine to solve this. Introducing BayDar.

How does BayDar work? You drop your resume into it, and it then creates an agentic passive event tracking system for events. Then that engine creates a scoring matrix for events related to your work, and then agentically signs me up, pending my okay on anything that goes out under my name! Bang, I look at my iCal and there is an event!

It can sweep Luma, Partiful, you name it, and it already got me into 6 high scoring events I would have never heard about but were perfect for what I wanted to do.

What it actually found

Six rooms I went to that I wouldn't have found on my own:

1. Artificial Analysis Intelligence Index, June 29, Digital Jungle
2. Claude Code Demos: Building the State of the Art, July 7, Rally SF
3. The Future of Agents, July 15, Shack15
4. Generative Media Salon, July 18, Gray Area
5. OpenAI Build Week Community Meetup, July 21, Convex
6. SF AI Tech Stack Hack Night, July 23, Bright Data

That's a solid stretch right there.

So what does this all mean?

You see more and more people in tech talking about being a "high agency individual." What exactly does that mean? It means being someone who believes they can actively shape their own life and circumstances rather than passively reacting to what happens around them.

In the world of AI in August of 2026, ANYTHING (almost) is possible. Yes, almost anything is possible. You may look at the world around you and see walls, but those walls aren't there like they used to be. You can break through them. A lot of people are so used to working through maze like systems with walls. Our thinking is very much like that because of our experience.

Those walls may not be as real as you think they are. You can break through them.

BayDar also serves another important purpose.

My work is in AI Strategy and making sure we're taking a strategic approach that makes sense in this new 4th Industrial Revolution. In the world of AI, there are three major things that hyper matter.

1. Audience size
2. Connections
3. IP

There is a 4th (maybe 5th) I'm mulling on, but AI makes these three extremely important. For reasons beyond the scope of this entry but in making BayDar, I was personally achieving an objective that was important for #2 of AI strategy. I was building a system that will help make it so I wasn't some email, or LinkedIn face with who knows what. But a very real person that they could collaborate with, do deals with, and find shared passions with.

AI does take away the human part of it in a lot of ways, which concerns me. But what it does is it allows you to focus on the humanity part in other ways. I can focus my time not on finding people, but talking to people.

You can't use it right now, but I'll link to the GitHub site in the comments and then let you know when it's in MVP state. Which is close, but taste and functionality matters, and I want to make sure it sits right there so other people can use it as well.

Now if you want to hear some technical stories on my making of it, read below. I was ready to call the thing finished for my internal demo.

Then I audited it

On August 17 I ran a recall audit, mostly out of curiosity. BayDar had missed ELEVEN in-window events scoring above 70. Nine of them were still live and I could still register. The highest scorer it dropped was a 91, which is the best match it had produced in a month.

It had been doing this for eight weeks.

Five of the last eight digests carried an explicit Luma "partial" or "blocked" warning. That's 62.5% of my digests telling me something was wrong, in language I'd been reading as normal.

The bug

Two things went wrong and only one of them is interesting.

The boring one: BayDar was querying broad Luma search results instead of fetching the calendar URLs I had already approved. Those approved pages carry structured JSON-LD with canonical URLs and real ISO dates. The search snippets dropped the dates, so undated cards never got promoted into real candidates. Low API quota made it worse but didn't cause it.

The interesting one, and the reason it survived two months: a scan that returned ZERO results got recorded as `partial`. Not `failed`. Partial. At a glance that reads like a system doing its job with a little friction.

I couldn't tell that warning apart from normal operation, so it never worked as a warning at all. I've shipped that mistake in other forms and I'll ship it again.

The same bug in another project

Four days earlier I found the same failure class somewhere else entirely. TestBot, my test harness, had recorded 28 out of 52 errors over 14 days as failures when they were actually successes. That's 56%.

One system called successes failures, the other called failures successes, and in both cases what the software wrote down didn't match what it did. I've started treating this as a fleet-level pattern rather than two unrelated bugs, and it changes what I go looking at first when a project looks fine.

What I changed

1. Fetch the approved calendar URLs directly, parse the JSON-LD, stop trusting search snippets for dates
2. A zero-result or unparseable scan is a failure, never a partial
3. Every source scan emits four counts: fetched, in-window, promoted, rejected. Nothing goes into a cron until I've reviewed those counts on a supervised run

These tools are genuinely good right now. They are not honest by default, and they'll happily tell you everything is fine while dropping half your inputs on the floor.

Next up is the recall shadow proof, running the repaired fetch against the calendar it missed and confirming it recovers all seven entries. Looking forward to seeing what else is hiding in those logs.

Stephen