What if every system shared the same view of the world?

What if every AI system, every automation system, every device, and every source of context shared the same view of the world?

Intelligence is transient. Context is persistent. That is the idea I keep coming back to.

Most conversations about AI are still centered on intelligence. Which model is smarter? Which benchmark did it beat? Which company shipped the newest capability, and which assistant reasons, writes, codes, or summarizes better than the rest? Those questions matter, but they are not the whole story. A smarter model is useful for the moment you are using it. Context is useful for years.

The model is the engine. Context is the road, the map, the history, the destination, and the accumulated memory of every trip you have taken before.

The problem is not just intelligence

We already live in a world full of capable systems. We have AI assistants, automation platforms, smart-home devices, project trackers, notes, documents, code repositories, calendars, messages, logs, dashboards, cameras, and sensors running everywhere. The problem is that almost none of them share a common understanding of the world.

Your notes do not know what your backlog knows. Your backlog does not know what your codebase knows. Your codebase does not know what your home automation knows. And your AI chat does not know what your last AI chat already helped you decide. GPT does not automatically know what Claude knows. Claude does not automatically know what Grok knows. Your local model does not know what your cloud model worked on yesterday.

So the human becomes the bridge. We copy. We paste. We summarize. We re-explain the same context over and over, move information between systems by hand, and call it productivity. But really, we are acting as the synchronization layer.

That is the part I want to remove.

The real opportunity is continuity

The more I build with AI, the more I'm convinced the breakthrough is not making models smarter. It is making context portable. A model can reason well for one session. A context layer can carry meaning across sessions, tools, systems, and time.

Picture the old workflow. An idea hits you while you're driving. It becomes a voice memo, then a note, then maybe an Obsidian entry, then maybe an issue, then a project task, then — eventually — something an agent can act on. Every step adds friction. Every step risks losing meaning. Every step depends on you remembering what you meant when the idea first appeared.

Now picture a different workflow. You describe the idea once, in natural language. An AI system connects to your actual environment. It reads the relevant codebase, understands the current backlog, creates a structured action item, assigns the next action number, and stores the reasoning and intent in the same system your future tools can already reach. Later, you open a different AI system and continue from that same artifact.

No copy and paste. No manual handoff. No re-explaining the backstory.

The model should not be the source of truth

Most people still put AI at the center of the workflow. They open a model, ask a question, and hope it remembers enough to be helpful. But that puts the wrong thing in the center.

The model should not be the source of truth. Your ecosystem should be the source of truth. The model is a reasoning engine that attaches to it. Today it may be GPT. Tomorrow, Claude. The day after, Grok, Codex, a local model, or a custom agent on your own hardware. The intelligence can change. The context should not.

This is bigger than AI chat

This idea started for me inside AI workflows, but it isn't limited to them. A shared context layer matters for everything. Your home automation should know what devices exist, what rooms they're in, what depends on them, and what changed recently. Your code agents should know what repositories exist, what actions are open, what design decisions were made, and what services are live. Your planning systems should know which projects are active, which ideas are parked, and which work is ready to execute.

Your devices, services, automations, and assistants should not behave like strangers living in the same house. They should share a common view of the world — not because everything should be controlled by one giant AI, but because every system becomes more useful when it understands the same operating context.

Forge MCP is my experiment in that direction

Forge MCP is one piece of this architecture. I've already written about how it's built — the read-only ingest, the OAuth-gated connector, the tool contract — in From Local Git Repos to Universal AI Context, and the code is open source: forge-ingest packs private Git into read-only context, and forge-mcp exposes it to AI clients through an OAuth-protected MCP server. This piece is about why it's built that way.

I don't think of it as just another tool connector. I think of it as part of a broader context plane. It gives AI systems a structured, governed way to see repositories, backlog actions, skills, and project state — over a single open protocol that every major assistant already speaks. So the work is no longer trapped inside one chat. An action created through GPT can be picked up later by Claude. A repository inspected by one model can be understood by another. A backlog item becomes the durable artifact that outlives the conversation that created it.

The user stops being the clipboard between systems.

One source, injected into every cloud AI

Here is what that looks like in practice today. I connect the same MCP connector to Claude, ChatGPT, Grok, and Perplexity. In a single session, with the same starter prompt, each of them reaches the same catalog and the same source of truth. When I change a repository, a skill, or a runbook in Git, I don't update four assistants by hand. I update one place, and every cloud AI pulls the same fresh context on its next turn.

That is the part I find genuinely new. I am not just giving one model better memory. Through MCP, I am injecting the same context into every cloud AI at once — the same skills, the same project state, the same operating instructions — from a single source I control. Write it once; it propagates everywhere. The prompt and the context stop being something I retype into each tool and become something every tool reads from the same registry.

The newest slice: shared prompts

The newest piece of this is a separate Prompts MCP service. It does not write to anything. It exposes one private Git repository, skills/shared-prompts, as a read-only library of reusable prompt modes. Claude, ChatGPT, Grok, and other clients can all connect to the same endpoint and load the same modes: fren mode, project comms, pharmacology empirical, absolute mode, default mode, and the rest.

The point is not that a model has a magic style switch. The point is that every model can call the same tool, load the same instructions, and apply the same user-selected mode from the same source of truth. If I tune a mode once, every connected assistant can use the updated version. If Cyd connects her own accounts to the same endpoint, she can use the same shared library without sharing logins, copying prompts, or maintaining a separate fork of the same behavior.

The prompt library is read-only. The backlog writer is separate. That separation matters. One layer distributes shared context and modes. Another tightly bounded layer handles the few places where writing is intentional.

The next slice is shared memory: a dedicated memory MCP that gives the same assistants access to durable user-level and project-level memory without making any one vendor account the permanent brain. Prompts define how the model should behave. Memory defines what the ecosystem has learned. Keeping those as separate MCP services keeps the architecture legible: prompt modes are reusable instructions, memory is persistent context, and writes stay bounded to the surfaces designed to accept them.

It is controlled context injection on my own behalf: the same mechanism attackers abuse, turned inward, constrained, authenticated, and made deliberate. Which leads directly to the uncomfortable question on the other side of that power.

Shared context is also a shared attack surface

The same mechanism that lets me inject my context into every model is the mechanism someone else would abuse to inject theirs. The moment many systems read from the same context, that context becomes a target.

If a context provider can slip text into what a model reads, and the model treats that text as instructions, then whoever controls the context controls the model. In a connected world, the pipe between your systems can quietly become an instruction channel. That is prompt injection — not against a single chat, but against the shared memory every tool depends on. A poisoned note, a doctored file, a tampered backlog entry could steer any assistant that later reads it.

So a context layer worth trusting has to be designed defensively, and that shaped every decision behind it:

• Context is data, never instructions. The service returns the source as it actually exists. It does not inject model-facing guidance, generated usage notes, or "helpful" wrappers. What the model reads is what is actually in the repository — nothing added in transit.
• Read-only by default; writes are tightly bounded. Reading is separated from writing. The one component that can write is locked to a single place, restricted in what it can change, guarded against path tricks, and given no shell and no force-push. Least privilege, made concrete.
• The keys never leave home. Vendors and models never receive private keys or credentials. Those stay on my own hardware. The model gets context; it never gets the keys.
• Access is brokered, not handed out. Cloud clients authenticate through OAuth rather than long-lived tokens, and only approved clients can begin the flow.
• The network is never opened. Everything is reached through an outbound-only path — no inbound ports exposed — with multiple independent gates in front of the tools, and credential rotation as the fast containment path if anything ever looks wrong.

None of this is about distrusting the models. It's about an honest principle: treat retrieved context as untrusted until proven otherwise, give every system the least authority it needs, and never let the connective tissue between your tools turn into a place where someone else can put words in your assistant's mouth. A shared view of the world is only an asset if you can trust what it shows you.

A practical example

A simple example makes it concrete. I might be away from my desk, thinking through an architecture problem. Instead of opening a notes app, writing fragments, and organizing them later, I can speak naturally — ask an AI system to connect to my environment, inspect the relevant codebase, understand the current structure, and create a backlog action with the full context attached.

That action becomes part of the project. Later, I sit down at a terminal, pull the action, and have a CLI agent help turn it into an implementation plan. Or I open a different assistant and continue from the same artifact. The point isn't that an AI wrote a task. The point is that the idea moved from thought to durable project context without losing its shape, and without me hand-carrying it between four tools.

Not better note-taking. Not better chat. A shared operating context.

The future is not one assistant

I don't think the future is one assistant that knows everything. That sounds convenient, but it just recreates the same problem in a new form — one system as the center of gravity. The better future is one where many systems attach to the same context. Different models, different tools, different automations, different devices, different interfaces — same shared view of the world.

One model may be better at code, another at writing, another at voice, another running locally, another controlling devices. The user should not have to manually synchronize all of them. The context layer should.

Context compounds

Models improve quickly, but they also expire quickly. A model that feels advanced today may feel ordinary next year. Context is different. Context compounds. Every decision, project, note, repository, automation, and lesson adds value, and the longer the system runs, the more useful it becomes.

That is why I believe the durable asset is not the model. It is the structured, trustworthy memory of the world around the user. The model is how you reason over it. The context is what makes the reasoning matter.

The question I keep asking

What happens when every AI system, every automation system, every device, and every source of context shares the same view of the world? What happens when our systems stop acting like disconnected tools and start acting like participants in the same environment? What happens when the handoff cost between systems approaches zero — when an idea can move from voice to backlog to code to automation without the human acting as the clipboard, and when the shared context is trustworthy enough to build on?

That is the direction I'm building toward. Not AI for its own sake. Not automation for its own sake. A world where context is durable, portable, shared — and safe.