Scaling AI Context Across Dev and Strategy Teams with Isolated Memory, Open Standards, and Migration Readiness

Most discussions about AI memory start from a narrow use case: one person, one chat interface, one context bucket.

That is not how real companies work.

Even a small company quickly ends up with different types of context that should not all live together:

• engineering decisions
• strategy notes
• operational procedures
• founder-only context
• project-specific memory
• future AI worker or automation context

That was the real problem I wanted to solve.

Not just:

how do I make an AI assistant remember more?

But:

how do I make company context reusable across tools and teams, while keeping boundaries clear, staying interoperable, and avoiding lock-in?

For me, this had to work first in a developer workflow — especially VS Code and Claude Code — but it also had to make sense for strategy, operations, and future internal AI workflows.

So I stopped thinking about memory as a convenience feature.

I started treating it as infrastructure.

The real problem is not memory. It is boundaries.

AI memory is useful when it removes repetition. But once more than one person, team, or workflow is involved, the problem changes.

The issue is no longer persistence alone.

The issue becomes:

• who should have access to which context
• what should stay private
• what should be shared across the company
• what should remain isolated per project
• what a future AI worker should be allowed to see
• how to stay ready to migrate later without losing structure

A single shared memory bucket breaks down quickly.

Once everything lives together, you get the usual problems:

Leakage

Private or sensitive context can surface in the wrong workflow.

Weak organizational boundaries

Teams start relying on discipline instead of structure.

Cross-project contamination

One project’s assumptions bleed into another.

Poor future readiness

When you later want to add automations, internal agents, or another AI provider, the memory model is too messy and vendor-shaped.

For me, the issue was not whether AI memory was useful.

It was whether it could be structured like the rest of a serious system.

What I wanted from the architecture

The target was not “smart memory.”

The target was memory that behaved like infrastructure.

That meant five requirements:

• usable inside VS Code / Claude Code
• useful across dev and strategy teams, not just engineering
• isolated by trust boundary, not only by topic
• based on open standards so it remains interoperable
• ready for backup, migration, and self-custody-oriented evolution

That last point matters a lot.

If AI memory becomes important to how a company works, then eventually people will ask the right question:

what happens if we want to migrate providers, move to more self-hosted tooling, or bring more of this under our own control?

I wanted the answer to be: we are already structurally prepared for that.

The model: separate memory spaces by organizational boundary

The cleanest pattern was to stop thinking in terms of one memory system and start thinking in terms of isolated memory spaces.

Each space corresponds to a real trust boundary inside the company.

In practice, the spaces I care about are these:

1. Personal / founder

Private context that should never be mixed with shared company memory.

Examples:

• personal preferences
• sensitive planning
• founder notes
• private operating context

This space is never shared.

2. Dev team

Shared engineering context that developers can safely read and update.

Examples:

• architectural decisions
• coding conventions
• repository assumptions
• environment patterns
• implementation history

This is the memory surface for the engineering side of the company.

3. Strategy / operations

Shared context for non-engineering but still critical business work.

Examples:

• company positioning
• internal process notes
• strategic decisions
• operations guidelines
• repeated business logic and vocabulary

This matters because company context is not only code context.

A useful AI memory model should reflect that.

4. Project-specific

One product, client, repo, or initiative may need its own clean boundary.

Examples:

• project-specific conventions
• roadmap history
• implementation notes
• terminology that should not leak elsewhere

5. Agent-specific

This is where the architecture becomes future-proof.

A future internal AI worker should not automatically inherit the same memory surface as a human collaborator.

For example, I may want a separate account/key/domain/Worker endpoint for an AI workflow handling a narrow class of trade-related or operational tasks.

That agent should have its own isolated context and its own boundary.

Not access to everything.

Why one big memory system was not enough

A single system with tags and filtering can look elegant.

But as more people and workflows touch it, the weaknesses become obvious:

• someone queries the wrong scope
• someone writes into the wrong memory bucket
• sensitive context becomes too broadly retrievable
• access becomes awkward to revoke cleanly
• migration later becomes harder because the structure lives only in conventions, not boundaries

That is why I preferred explicit isolation.

A system is easier to trust when its boundaries are structural, not merely behavioral.

The architecture

The pattern is simple:

• one memory backend account per isolated space
• one thin endpoint per space
• one connector per endpoint
• clients connect to the endpoint, not directly to the backend secret

Visually:

VS Code / Claude Code / Chat UI / Internal AI Workers
                           │
       ┌──────────────┬────┼────┬──────────────┬──────────────┐
       ▼              ▼         ▼              ▼              ▼
   Personal        Dev Team   Strategy      Project       Agent / Worker
   (private)       (shared)   (shared)      (isolated)     (isolated)
       │              │         │              │              │
       └──────────────┴─────────┴──────────────┴──────────────┘
                                   ▼
                            Memory backend(s)

In my implementation, the stack is:

• Supermemory as the memory backend
• Cloudflare Workers as the thin endpoint layer
• MCP as the open protocol between clients and endpoints

The vendor stack is not the main point.

The main point is that each trust boundary gets its own addressable endpoint.

That is what makes the system understandable, shareable, and replaceable later.

Why this starts with developers but not only developers

I care a lot about VS Code and Claude Code compatibility because technical work lives there.

If the memory model works only in chat, it is not enough.

But the bigger point is that the same architecture can serve different parts of the company.

That matters because the most useful AI context in a business is rarely confined to one team.

Engineering, strategy, and operations all carry recurring context that benefits from persistence.

The memory model should reflect the company, not only the editor.

Why open standards matter

I wanted the system to remain interoperable.

That is why I built around MCP instead of treating the whole thing as a one-off UI-specific trick.

Using an open standard makes the architecture easier to reuse across:

• editor-based workflows
• chat interfaces
• coding assistants
• internal company tooling
• future AI workers
• future provider changes

This matters because the real risk is not only leakage.

It is also lock-in.

If company memory becomes useful but cannot move, then the company ends up shaping itself around a vendor limitation.

I wanted the opposite.

I wanted a memory layer that was already more portable than the interface using it.

Why I used a thin Worker layer

Each isolated space sits behind a small endpoint.

In my case, that endpoint is a Cloudflare Worker.

Its role is simple:

• receive MCP requests
• talk to the correct backend account
• inject the correct secret internally
• return the result to the client

This gives me several practical benefits:

• clients never see the upstream API key
• collaborators can be given only the endpoint relevant to their role
• each space can live on its own domain or subdomain
• access rotation becomes easier
• future AI worker endpoints can have separate credentials and separate boundaries

That last part matters a lot.

A future machine actor should be treated like a first-class system actor with a narrowly defined surface, not like “basically another user.”

This pattern supports that naturally.

A more self-custodial mindset

This setup is not fully self-hosted today.

But the architecture is designed with a self-custodial and interoperable mindset.

What I mean by that is:

• memory is separated into explicit boundaries
• access happens through endpoints I control
• the client-facing protocol is open
• the overall structure does not depend on one provider’s idea of “memory”
• future migration does not require redesigning the whole model

That is important.

Even when the storage backend is still external, a system can already be moving in the right direction if it is:

• structurally portable
• operationally understandable
• easy to replace component by component

In that sense, the design is closer to a self-custodial philosophy than to a fully managed black box.

Backup and migration readiness

One question that comes up naturally is whether company memory can be backed up — for example in a Git-oriented workflow.

The short answer is:

yes, conceptually that should be part of the design direction

The important thing is not pretending the current backend is magically version-controlled by itself.

The important thing is building the architecture so that backups and migration are natural next steps.

A practical migration-ready model would look like this:

• each memory space has a stable identifier and endpoint
• important memory content can be exported on a schedule
• exports can be normalized into plain files such as Markdown or JSON
• those exports can then be committed into Git or another long-term archive
• future self-hosted or alternative AI systems can re-ingest that material later

That gives the company two things:

Backup

Important organizational memory is not trapped in one external service.

Migration readiness

If the team later moves to another provider, a self-hosted setup, or a different AI orchestration layer, the structure already exists.

So even if full “Git as memory backend” is not implemented yet, the architecture can still honestly say:

we are already prepared to back up, export, and migrate this memory layer later

That is enough to keep the system strategically sane.

What this means for future AI workers

The same design also prepares the company for future internal AI actors.

A future worker that performs a narrow class of tasks — for example a trade-related AI routine, a research worker, or a project-specific assistant — should not receive the same memory surface as a human team member.

Instead, it can get:

• its own account
• its own key
• its own domain or subdomain
• its own Worker endpoint
• its own isolated memory space

That lets the company treat machine actors the same way it treats serious internal systems: with constrained permissions and clear scope.

In other words, this architecture is not just for people.

It is also for future automation.

Why this is better than copy-pasting context

Copy-pasting context works for a while.

Then it becomes organizational debt.

Across multiple teams and workflows, it creates:

• duplicated context
• stale instructions
• inconsistent shared understanding
• accidental oversharing
• no serious migration path
• no good separation between human and machine-facing memory

Persistent isolated endpoints solve that by making the boundaries durable.

The AI still gets the context it needs.

But that context is aligned with real company structure.

That is the difference between “memory as convenience” and “memory as infrastructure.”

The broader lesson

The most reusable lesson here has little to do with one assistant or one backend.

It is this:

if AI context matters to the company, treat it like a system, not a chat feature

That means:

• define boundaries early
• separate organizational domains clearly
• use open standards where possible
• keep clients away from upstream secrets
• prepare for backup and migration before you desperately need them
• design future AI workers as separate actors, not extensions of one human memory pool

That is the real reason I like this architecture.

It remains useful even if the underlying tools change.

This is the same kind of systems thinking I apply in Blockchange and in the open-source project p2pay: design the structure so it can scale before the complexity arrives.

Final thought

The real challenge is not making AI remember more.

It is making sure company context is:

• reusable across dev and strategy teams
• isolated where it needs to be
• interoperable across tools
• ready for future AI workers
• prepared for backup and migration
• less dependent on one vendor than it first appears

That is why I stopped thinking about AI memory as one bucket.

And started treating it as a set of isolated, portable boundaries.