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.

The value is in the composition. MCP is an open protocol. Knowledge systems, source control, prompt libraries, memory stores, backlogs, and retrieval pipelines all existed before this project. What matters to me is using those pieces as a shared context plane that multiple AI systems can attach to without making any one model the center of gravity.

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 connectors to ChatGPT, Claude, and Grok. 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 three assistants by hand. I update one place, and every cloud AI pulls the same fresh context on its next turn.

The interesting part is not that one connector exists. It is that the same governed context can be made available to different assistants, different models, and different interfaces without copying the user's operating context into each one by hand. That is the shift I am trying to demonstrate.

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: prompts, memory, and a connector map

The newest piece of this is a separate Prompts MCP service. It does not write to anything. It exposes one private Git repository 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 approved modes from one source.

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. A second authorized user can connect their own accounts to the same endpoint without sharing logins, copying prompts, or maintaining a separate fork of the same behavior.

Then I added Memory MCP as a separate private service. This is not a prompt library and it is not a vendor memory dump. It is a Git-backed memory store where approved durable context lives as concise records and pointers. External memory exports and local notes can become inputs, but only after review, consolidation, deduplication, and approval.

That distinction matters. Prompt modes define how a model should respond. Memory defines what the ecosystem has learned. Skills define the detailed runbooks and frameworks. Backlog defines work to do. Source repositories define the actual projects. Mixing those together is how systems become stale and confusing. Separating them gives every cloud AI a map.

The last piece was the connector map itself: a single built-in memory entry in each cloud platform that tells the model where everything lives. Memory lives in Memory MCP. Modes live in Prompts MCP. Repositories and skills live in Forge MCP. Tasks live in Backlog MCP. If a connector is missing, the model is told to say that, not pretend it used a tool it could not see. If Memory MCP is unavailable, it fails closed instead of reconstructing private facts from stale platform memory.

Now the workflow is plain language. I can tell ChatGPT, Claude, or Grok to pull a private memory topic. The assistant checks Memory MCP first, finds the approved memory record, sees whether the deeper detail lives in a related private skill or repository, then pulls that source through Forge MCP for the full operating details. The memory record stays short and current. The skill or repo carries the depth. The model gets both, in the right order, from the right places.

The same pattern works for technical projects, operating procedures, professional context, and private reference material. The memory layer tells the assistant what matters and where the deeper source lives. The skill or repo provides the detail. The connector map tells the model how to route the request across the four MCP services without exposing private details in public.

The prompt library is read-only. The memory writer is staged and confirmation-based. The backlog writer is separate and bounded. The Forge connector is read-only. That separation matters. One layer distributes shared modes. One layer stores approved memory. One layer exposes source and skills. One layer captures work. The model can move across them, but the permissions do not blur together.

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.

The protocol and the category are bigger than any one project. The working experiment is treating context as infrastructure instead of chat history.