The Missing Layer between AI and Day-to-Day
This blog post marks my thinking of this product I've been building. This is the vision I identify that is missing among various AI tools and "the AI bubble", while keeps me as a creator of AI, rather than just an operator of AI. This article is not written by AI.
Days are flows, not lists
People don’t live their day as a checklist. They live it as a flow of transitions: waking up into work mode, shifting into a meeting mindset, moving from planning into execution, and repeatedly context-switching as new information arrives. Tasks and thoughts are real, but they’re scattered across tools - calendar, email, documents, messages - so the brain becomes the router that stitches everything into something actionable.
That works until uncertainty enters: a delay, a change, an ambiguous update. Then the plan branches, dependencies surface, and cognitive load spikes because you’re no longer “doing tasks,” you’re continuously rebuilding the next few hours in your head. A good system shouldn’t just store information; it should preserve flow and control: help you understand what’s happening, what matters, and what to do next - so you feel prepared for what’s coming, not just aware of it.
The volcano notice
Last August, I had a flight from Shanghai to Detroit, and it turned into a small lesson in how unpredictable travel (and day-to-day planning) can be. Delta sent out a notice: a volcano in Russia had been erupting, ash clouds were causing reroutes, and cancellations were possible. A clear answer was not given about how long the impact would last, and what the realistic failure modes were (delay, missed connection, overnight reroute).
Arrival time, pickup, work the next day - starts depending on a forecast you don’t have.
Here’s what I asked ChatGPT over the 3 days before the travel day:
How long will this kind of volcanic eruption affect flights?
Search and analyze online reports about this eruption, and make a forecast.
Analyze the situation and provide action recommendations for DL388 on 8/18.
There’s no connection. In the worst case, what’s the latest time I could arrive in DTW?
A day has passed - can you check the latest situation now?
Let’s break this down and see what are we facing here -
As such, "looking up info" isn’t enough: you needed an operational plan rather than facts to put everything back in control.
Complicated Plans & Ripple Effects
A trip looks like one event on a calendar. In reality, it’s a web of dependencies.
There’s the flight, but also the connection window, the baggage rules, the ground transportation on both ends, the time zone shift, the “latest acceptable arrival,” and the commitments waiting on the other side. Some dependencies are hard (a boarding time). Others are soft (how much buffer you personally need to feel safe). None of them are visible in one place.
That’s what makes plans feel complicated: not the number of items, but the relationships between them.
Then comes the ripple effect. One disruption doesn’t just change one event; it propagates. A reroute changes arrival time. Arrival time changes sleep. Sleep changes performance. A missed connection changes whether you need a hotel, whether you need to notify someone, whether you need documents accessible offline, whether you should pack differently, whether you should move or cancel something tomorrow.
This is why uncertainty is so expensive. You’re not solving one problem. You’re maintaining a moving graph.
And when tools only show isolated pieces - an itinerary here, an email there—the user is forced to do the graph management manually: identify what’s connected, imagine what breaks, and decide when to intervene.
That is the gap I’m trying to close: turning a context-heavy situation into a small, stable plan you can see and control.
Why today’s tools fail at preparation
Travel apps store itineraries, but they won’t help you decide. Calendars show blocks of time, but they won’t understand the relationship among blocks. Email contains the latest truth, but it arrives as unstructured fragments that you have to stitch together.
ChatGPT is the mostly reactive one in this workflow. It answers each question, but doesn’t carry your constraints by default, monitor changes over time, or assemble a plan without you repeatedly rebuilding context.
What I actually wanted wasn’t an answer. It was a system.
What a contextual assistant would do differently
If the problem is that the user becomes the router, the solution is not “more information.” The solution is a layer that can hold context, understand dependencies, and surface only what matters next—at the right time, in a form that preserves control.
A contextual assistant would treat your calendar, travel details, and constraints as one living plan. Not a static itinerary, not a chat thread, but a system that continuously answers three questions:
What’s happening? (the current state, and what changed)
What does it mean for me? (impact on your specific plan and dependencies)
What should I do next? (a small set of actionable options, with tradeoffs)
It would make the plan visible. Not as an overwhelming dashboard, but as a calm “next steps” surface you can trust. It would use progressive disclosure: show the essentials first, then let you expand into details only when you need them. It would be proactive without being pushy—suggesting, not acting; explaining, not demanding. The point is not to replace judgment, but to reduce the cost of exercising it.
And in the ideal, ultimate version, the assistant wouldn’t stop at guidance. When changes happen, it could coordinate the problem-solving on your behalf: holding a backup flight, initiating a rebooking flow, drafting and sending the “running late” messages, calling a hotel to shift a check-in, or notifying the right people with the right context, with explicit user approval. The interface stays calm, but the system behind it becomes an agent: not just helping you understand the situation, but carrying the operational load when the plan breaks.
Start small: the first wedge
If this idea is “a contextual assistant for life,” the failure mode is obvious: trying to boil the ocean. Context is infinite. Integrations are endless. If I chase the full vision too early, I’ll build a brittle dashboard instead of a system that actually changes how a day feels.
So the right move is to start with one wedge: a scenario where (1) the stakes are real, (2) the context is rich but bounded, and (3) the value of “a plan, not an answer” is immediately legible.
We will start with travel preparation - flight, drive, public transit, errand run from CVS to Trader Joe's.
Travel is a perfect stress test for contextual assistance because it compresses complexity into a short window. It has hard constraints (departure times, connections, documents) and clear ripple effects (arrival time affects everything downstream). It also produces a common pattern of questions that are really decision problems: what’s likely to happen, what are the failure modes, and what should I do now versus later.
Most importantly, it’s a place where I can start without overreaching on data access. I don’t need to read a user’s entire inbox to be useful. A first version can work with minimal inputs: a flight confirmation (pasted or forwarded), a calendar event, and one user-defined constraint like “latest acceptable arrival.” From there, the system can generate a single artifact that matters: a calm plan card that turns uncertainty into options, timing, and check-ins.
That’s the build philosophy: earn trust by being useful with less. Start with one “magic moment” that feels like control returning, then expand outward only when the interaction quality and the user value are undeniable.