Fake proactivity vs. real lived proactivity in AI

There is a phrase Nate Jones used in a recent video that has stuck with us: real lived proactivity. It is the bar most products claim to clear and very few actually do.

The pattern goes like this. A product launches. The pitch is "proactive AI." The first few times you use it, you get pinged about a meeting you do not have, a follow-up to an email you already sent, a task you completed last week. Within a few days you have stopped paying attention. Within a few weeks you have uninstalled.

This is fake proactivity. It is what happens when an AI agent reads a single source, takes the data at face value, and starts firing notifications. It is the wrong bar.

The right bar is real lived proactivity — surfacing the right thing at the right time, based on enough context to know what actually matters, and staying out of the way otherwise.

What fake proactivity actually looks like

A few patterns we see repeatedly:

Calendar timestamps as truth. The agent sees an event in your calendar at 3pm and starts pinging you about prep. It does not know you have declined the last four occurrences, or that the meeting was rescheduled three times, or that you only put it on the calendar to remember it existed and have no actual intention of attending.

Email matter detection without thread context. The agent flags every email with a question mark as "needs reply." It does not know you already replied to the thread on a different device. Or that the question is rhetorical. Or that the sender is a vendor you stopped working with.

Task list pings. The agent sees a task with a due date and reminds you about it daily. It does not know you have done the task and just forgot to mark it complete. Or that the deadline shifted in a meeting last week and the task list never got updated.

One-shot recommendations. "I noticed you have a flight at 9am, want me to check in?" — but the flight was already cancelled, you rebooked yesterday, and the system never updated.

Proactive volume that scales with data, not value. The more accounts you connect, the more nudges you get. Every email becomes a potential ping. Every calendar entry becomes a potential prep flow. Volume signals desperation, not intelligence.

In each case the underlying mistake is the same: the agent is acting as if the data is reality, when in fact the data is just a noisy signal of reality.

Why this happens (and why it keeps happening)

Three reasons.

Single-source detectors are easy to ship. A "calendar prep" detector that pings you about every event with attendees is a few hundred lines of code. It produces nudges. It feels proactive. It ships in a sprint.

The user's life is messier than any product team's mental model. Your calendar has entries you did not make. Your inbox has emails you have already mentally resolved. Your task list has items that are no longer relevant. The product cannot tell which is which without significant inference work.

The negative signal of bad nudges is invisible at first. A user receives ten bad nudges. They click through none of them. The product team sees "low engagement" and tries to fix it with more nudges, more sources, louder copy. The actual fix is fewer nudges, but better.

The pattern compounds. By the time the team notices the channel is dead — when even good nudges are getting ignored — the user is already gone.

What real lived proactivity requires

Three things, in roughly this order.

Context that goes beyond the immediate signal. When the agent sees a calendar event, it should also see your declined-vs-accepted history with that recurring meeting. When it sees an email, it should see whether you have already replied somewhere else, what your relationship with the sender looks like, whether the thread is settled. We have written about multi-source fusion which is the architectural move that makes this possible.

Calibration that learns from the user's actual behaviour. If the user dismisses every networking-stale nudge, the system should make networking-stale nudges quieter — automatically, without configuration. We have written about outcome learning which is the mechanism. The result is that noisy detectors get auto-quiet over time, and the channel stays usable.

A confidence ladder that picks the right surface. Not every signal deserves a push notification. Some belong as a quiet line in tomorrow's briefing. Some deserve a real-time alert. Some — very few — deserve to actually ring the user's phone. We use four levels — whisper, briefing, push, ring — and never escalate without a confidence check.

Each one of these is non-trivial to build. None of them is glamorous. Together they are the difference between an agent that is proactive on paper and one that is proactive in lived experience.

The diagnostic test

There is a simple test. Pick three days in your calendar with anything weird going on — a meeting that got rescheduled, an event you declined, a task that became irrelevant, an email you already handled. See what the AI agent does. Does it correctly understand the actual state, or does it fire off nudges based on the stale data?

A real proactive AI gracefully handles "this calendar entry exists but you have not engaged with it in three weeks." A fake one treats it as a fresh prep opportunity.

A real proactive AI notices "this email looks important but you replied to it from your phone yesterday." A fake one keeps reminding you to respond.

A real proactive AI handles "you keep dismissing networking nudges, so the system has dialed them down." A fake one keeps sending them at the same volume forever.

If the product passes this test, it is doing the harder work. If it fails, it is firing off pattern-match nudges without context — fake proactivity in a nice UI.

What makes this hard, but not impossible

The reason most products fail at real lived proactivity is that the supporting infrastructure is large and not visible to the user.

You need:

• A unified context graph across email, calendar, tasks, contacts, threads
• A per-user-per-detector calibration system that learns acceptance vs dismissal over time
• A snooze mechanism that captures "useful but not now" without polluting the calibration data
• A look-ahead scanner that sees 1 to 30 days out, not just the current moment
• An action history table so the system knows what was done last time
• A confidence ladder that picks the right channel for each priority level
• A trust contract that lets users grant and revoke autonomy explicitly

Most products have one or two of these. Almost none have all of them. The product that does is what real lived proactivity actually requires.

The takeaway

Fake proactivity is loud, generic, and ages badly. It feels proactive in the demo and noisy in week three. The user stops engaging.

Real lived proactivity is quiet, specific, and gets quieter over time as the system learns where it is wanted and where it is not. It feels generic in week one and like a chief of staff in month six.

If you are building an AI agent, the question to ask is: do we have the infrastructure to be quiet where the user wants quiet, and loud where the user wants loud? If the answer is "we have a single LLM that decides," that is not enough. The right answer is a system of detectors with per-user calibration on top.

If you are evaluating an AI agent, the diagnostic is: does it know my data well enough to know what is actually real, and does it stay out of the way when nothing matters? If the answer is yes, the product has done the work. If the answer is no, you are looking at fake proactivity.

We have written separately about the anticipation gap, the trust ladder for AI agents, year-over-year memory, outcome learning, multi-source fusion, and proactive AI for founders. Together they describe what real lived proactivity actually requires. The pieces are not glamorous. The result is.