From Context in Apps to Apps in Context

Rethinking Computing Around Living Context

For most of computing history, applications have been the containers and users have been the connectors.

An application knows something about us. Another application knows something else. Each maintains its own state, exposes some capabilities, and responds when asked.

When something changes, it is usually we who notice the change, understand what it means, decide what should happen next, and orchestrate the applications required to make it happen.

AI agents promise to make that orchestration dramatically easier.

But perhaps we are stopping one architectural layer too early.

What if, instead of putting more context into applications and agents, applications and agents operated inside a continuously evolving context?

That is the inversion I want to explore.

A Very Ordinary Journey to the Airport

Imagine I have a 9:30 PM flight.

My computing environment knows the flight, expected airport congestion and the evening traffic pattern. It works backwards and determines that leaving at 5:30 PM gives me an appropriate safety margin.

So I leave.

There is another piece of context that has seemingly nothing to do with navigation: I am awfully hungry.

And given a choice, I would love seafood.

As I approach Manyata, something unexpected happens. Traffic eases significantly. What looked like a tightly budgeted journey now has perhaps thirty minutes of additional slack.

What happens today?

My navigation application recalculates the route and tells me that I will reach the airport earlier.

And then its job is largely done.

My job begins.

I notice that I am early.

I realize that perhaps I now have time to eat.

I search for seafood restaurants around my route. I compare locations and ratings. I estimate the detour. I check whether eating there still leaves sufficient airport buffer.

Then I return to Maps or my ride-hailing application, add a stop and once again check my revised arrival time.

Every application may have worked perfectly.

Yet something is odd.

I was the integration layer.

I carried context from one application to another. I recognized the opportunity. I reconciled competing goals. I performed the orchestration.

We have become so accustomed to this that we barely notice ourselves doing it.

Now Imagine a Living Context

Suppose instead that my computing environment maintains a continuously evolving representation of what matters to me at that moment.

Let’s provisionally call it Living Context.

It knows my persistent intent:

Catch the 9:30 PM flight comfortably.

It knows my constraints:

Traffic. Airport congestion. Required safety margin.

It knows my current situation:

Travelling toward the airport. Hungry.

It knows relevant preferences:

I enjoy seafood.

And it knows the capabilities currently available to me:

Routing, ride modification, restaurants, reservations and payments.

Crucially, this context isn’t reconstructed only when I open an application or ask an AI a question.

It lives and changes as my world changes.

So when traffic unexpectedly clears near Manyata, the system doesn’t merely update my ETA.

It understands that the changed traffic condition has altered what is possible.

A constraint has relaxed.

An opportunity has appeared.

The system might tell me:

Traffic has cleared considerably. You can stop for seafood near Manyata for 25 minutes and still reach the airport with your original safety buffer. There is a place you are likely to enjoy four minutes off your route. Shall I add the stop?

Notice what I didn’t do.

I didn’t ask whether I was early.

I didn’t search for restaurants.

I didn’t ask whether a restaurant would fit into the journey.

I didn’t reconcile the restaurant detour with my flight.

I didn’t move information between applications.

The underlying information may be almost identical in both scenarios.

What changed was where the intelligence and orchestration lived.

From Context in Apps to Apps in Context

Most software today effectively follows:

Request → Retrieve → Compute → Respond

Applications own their state and their slice of context. The user moves between those applications, carrying intent along the way.

Even the emerging generation of AI agents largely starts from this architecture.

The agent receives a request, assembles context and calls APIs on our behalf.

That is already a major improvement.

But what if agents themselves are an intermediate step?

What if we invert the architecture?

Instead of:

Applications containing context

we move toward:

Applications participating in context.

Or more simply:

Context inside applications → Applications inside context

The application is no longer necessarily the primary container of the experience.

Maps provides a routing capability.

A ride-hailing service provides mobility.

A restaurant platform provides discovery and reservations.

A calendar provides commitments.

Devices provide observations.

Payment systems provide settlement.

Agents provide reasoning and action.

And Living Context connects those capabilities around the user’s continuously evolving state and intent.

Context Becomes Computational

We usually think about context as an input to computation.

This is particularly visible in today’s AI systems. We assemble the right context so that a model can answer a question or perform a task more intelligently.

I want to explore the inverse proposition:

What if maintaining, interpreting and evolving context itself becomes a primary computational activity?

Context then isn’t simply a collection of data.

It contains observed state, inferred state, persistent intent, constraints, preferences, relationships, history and available capabilities.

And changes to that context can themselves trigger computation.

The operating loop begins to look less like:

Ask → Answer

and more like:

Observe → Update Context → Interpret Change → Reconcile Goals → Determine Next-Best Action → Act → Observe

This is what I mean by Context-Centric Computing.

The User Shouldn’t Have to Be the API

There is a slightly uncomfortable realization underneath all this.

Despite decades of application integration, APIs and cloud computing, humans remain extraordinarily important middleware.

We copy information between systems.

We remember why something matters.

We notice when circumstances have changed.

We combine information from unrelated domains.

We decide which application to invoke next.

We repeatedly translate our intentions into requests that individual applications understand.

In other words:

Today’s applications may be digitally connected while their contexts remain cognitively connected by the user.

An agent can reduce that burden.

A Living Context architecture asks whether we can remove some of it structurally.

There Are Plenty of Ancestors

I don’t assume this idea appeared from nowhere.

There are obvious intellectual relatives: context-aware and ubiquitous computing, blackboard architectures, event-driven systems, complex-event processing, digital twins, autonomous vehicles and robotics, personal knowledge systems, agent memory and the emerging field of context engineering.

Autonomous vehicles provide an especially interesting analogy.

A vehicle continuously maintains a representation of its environment. It doesn’t wait for the passenger to say:

“A pedestrian has entered the road. Please reconsider our current trajectory.”

The changing world updates its model, and the changed model affects what happens next.

The question that interests me is:

Can some of that architectural thinking escape the bounded world of the autonomous vehicle and become a more general computing primitive?

And Then Things Get Difficult

A Living Context sounds attractive until we ask how it would actually work.

What constitutes context?

Who decides what is relevant?

How do we distinguish a meaningful context change from noise?

How do conflicting goals get reconciled?

How do applications expose capabilities rather than merely APIs?

How does context move safely between a phone, car, laptop, home and cloud?

How is uncertainty represented?

How much autonomy should the system have?

And perhaps most importantly, how do we build continuously aware systems without building continuously surveilling systems?

There is another question hiding behind all of this that I deliberately want to treat separately:

Whose context is it anyway?

If context eventually influences what we do next, then whoever controls that context can potentially control the objective being optimized.

Is the system optimizing my wellbeing?

Or engagement, conversion, commissions and somebody else’s economic objective?

That deserves a conversation of its own.

For now, I want to stay with the architectural question.

An Invitation to Challenge This

This is an exploration, not a declaration of having invented a new branch of computer science.

Quite possibly, I am rediscovering ideas that researchers in distributed systems, operating systems, ubiquitous computing, HCI, autonomous systems or AI explored years ago under better terminology.

I would genuinely like to find those ideas.

Where has this architecture already been attempted?

What am I overlooking?

Where does the analogy break?

What are the hardest technical problems?

And is Context-Centric Computing, with a Living Context spanning applications and capabilities, actually a useful abstraction?

Most importantly:

Is there something here worth building?

If you work on systems, agents, context-aware computing, HCI, personal AI, distributed architectures or adjacent areas—and this makes you either curious or uncomfortable—I would love to compare notes.

Perhaps the future isn’t about putting ever more context inside increasingly intelligent applications.

Perhaps it starts by turning the architecture inside out.

From context in apps to apps in context.