We didn’t set out to build a product. We set out to fix our own problem.

The problem we lived

Every AI session started from scratch

I’m a product manager at a company full of software developers. When we brought AI into how we worked, we kept hitting the same wall: everyone rebuilt the same context by hand, every session, in their own silo — copying files, sharing them, tweaking them.

When one person made an improvement that would have helped everyone, it stayed on their machine. There was never a single source. We tried hosting our context in GitHub and GitLab, but the moment someone edited a file locally and forgot to push, everything drifted out of sync. There was no real solution.

It wasn’t just us

So I asked someone who’d know

I reached out to my cousin, who works at another software development company and runs engineering teams of his own, and asked how they dealt with the AI context problem. Same story. Same wasted hours, at a completely different company. That’s when I knew it wasn’t just our problem. It was everyone’s.

The first version

A crude fix that actually worked

I started with something rough: a simple way to share context across the team. Then I wrapped it in an MCP so any AI could pull that context remotely — no more dragging huge file structures around on every laptop.

Why keep files locally at all, when they can be read straight into an AI’s memory the moment it needs them, and updated only when they actually change?

The realisation

Nobody reads the manual anyway

Then I looked at where our real knowledge lived: Confluence. SOPs, onboarding, all of it — sitting in rich text that nobody ever read. Onboarding a developer took six weeks, and at the end they still weren’t building to our design and code standards. They learned by getting it wrong and having seniors correct them.

So I asked a different question. If AI is where everything is heading, why does anyone need to read documentation at all? What if everything is context, committed to memory the moment an AI needs it? Writing code — your standards and architecture are just there. Doing marketing — your brand is just there. The AI works in-context, automatically.

How it grew

One realisation led to the next

1. 1

   File versioning

   So context could change safely — every update tracked and owned, the way Git tracks code.

2. 2

   Shared skills

   We were already sharing skills. Now they live in one place and pull on demand.

3. 3

   Shared agents

   Customise one agent to make it better, or duplicate it into your own — from a single source.

4. 4

   Governance built in

   Every change timestamped in the event log, so a workspace owner can see and manage everything.

Underneath all of it, one principle: everything is pulled through an API and delivered over MCP — so it works with any AI model, any IDE, any browser. Everyone runs the same context.

Where this is going

The second layer

Picture a spaceship crew far from home, cut off from every server they’d normally rely on — and still able to ask their ship anything. How the engines keep the ship running. What a part does. What to do next. The answers are right there, because everything the spaceship knows lives in one queryable layer they carry with them, and an AI reads exactly the piece that’s needed.

That’s the direction we’re building toward. AI models are the first layer — the ability to reason and create. Contextium is the second — the layer that holds your context and the parameters of that context for your AI to be able to support you perfectly, with the right permissions, the moment it’s asked.

It starts small: a team sharing context today. But the same idea scales — to a company, a site, eventually a self-contained operation that can answer any question about itself, connection or not.