Logged In Does Not Mean Someone Is Listening

I had a simple rule for who an urgent message should come from. It should go out under the name of the person or process actually built to act on it right away, not a shared, general line that could only pass the words along. The rule I used to decide that was straightforward: if their own login still works, send it under their name.

A login is just a set of working credentials. It works whether or not anything is actually on the other end, active and able to respond. I could send a message under a name with nothing there to respond, and the system would still report success. It would say the message went out correctly. Nobody would know that the one thing that actually mattered, something being there to respond, wasn’t true.

The source incident for this lesson involved an AI agent’s listening process, not a person who stepped away. The same test-for-a-pulse idea holds for human handoffs too, because both cases fail the same way in practice: the system reports success while nothing is actually able to act on what came through.

I only found out because I went looking

I hadn’t been burned by this yet. I went looking for it on purpose, before it had the chance to matter. I deliberately made the intended recipient unreachable, left their login completely untouched, and sent a test message.

It went out under their name, formatted correctly, delivered successfully, with no one there to see it.

A working login only tells you the system accepted the request. It says nothing about whether anything is actually happening on the other end. Those are two separate facts, and I’d built a check for exactly one of them.

What actually proves someone is there

The fix replaced the question entirely. Instead of asking “does this person’s login still work,” it asks “has this person or process checked in recently, on their own, on a regular schedule, somewhere I can see it independent of whether sending a message to them would succeed.” If that recent check-in is missing, stale, or can’t be read for any reason at all, the system treats it the same way every time: assume nobody is there and fall back to the next option.

It doesn’t try to guess whether the person is genuinely unavailable, unreachable, or whether the check itself just failed for some unrelated reason. Whoever is waiting on the other end experiences all three of those exactly the same way: they think someone is coming, and no one is. Treating them as different cases and quietly sending anyway is how a real gap goes unnoticed for months.

The backup has to say what it is

The other detail that mattered as much as the check itself: the backup path never pretends to be the original. When the intended recipient can’t prove they’re actually there, the message still goes out, under a clearly different, clearly labeled line, saying plainly that the usual recipient appears to be unavailable and this is a backup. If even that fails, it drops to the plainest possible fallback, also labeled. Every step announces itself. A backup that quietly stands in without saying so is the version of this that fails silently for months, right up until the day it actually matters and nobody notices until it’s too late.

Where AI fits

An assistant is useful here for exactly one thing: designing and describing the “are they actually there” check, and making sure every fallback step names itself honestly. It shouldn’t be trusted to decide on its own that a login working is good enough proof, and it shouldn’t quietly reroute an urgent message without flagging that it did.

The human decision

A person decides what counts as proof that someone is genuinely available, and what the acceptable backup looks like when they aren’t. That’s a judgment call about the actual cost of a missed message, and it belongs with whoever owns that risk.

The lesson

A working login proves the door opens. It doesn’t prove anyone is behind it. If something urgent depends on a real person or process being available, check for an actual, recent sign of life, not just that their credentials still work, and make sure the backup plan says out loud that it’s a backup.

The paired Build Log shows the exact test that exposed this, killing a live process on purpose while leaving its credentials untouched, and the heartbeat check that replaced a login test as the real proof of whether anyone was actually there.

dxdev LESSON · paste into your AI agent

LESSON: Test for a pulse, not just a password

WHAT TO SHARE:
A de-identified description of how an urgent message currently gets routed to a person or team, and what the system currently checks before deciding who it goes to.

ASK YOUR AGENT TO:
1. State plainly what the current check actually proves versus what it's being trusted to prove.
2. Propose a fresh, ongoing signal that the intended recipient is actually available right now, not just that their account or line still works.
3. Design a backup path that clearly labels itself as a backup and states why, rather than silently standing in.
4. List the different reasons the primary recipient might be unreachable, and confirm they'd all be treated the same way by whoever is waiting.

RETURN:
A description of the gap between the current check and what it should prove, a proposed "are they actually there" signal, and a labeled backup plan.

BOUNDARY: Do not change how urgent messages are routed or turn any alert on or off. A person reviews the design and decides what to put in place.