From Project Memory to Project Intelligence

AI coding agents are becoming increasingly capable.

But there is an architectural problem that becomes more obvious as projects get longer-lived:

Where does the project’s evolving state actually live?

Today, we have many ways to provide agents with context:

• AGENTS.md
• CLAUDE.md
• IDE rules
• MCP servers
• vector databases
• RAG
• session memory
• repository indexing

These approaches are useful, but they mostly answer different versions of the same question:

How can I give the agent enough context to complete the current task?

I’m interested in a slightly different question:

How can the project maintain its own evolving intelligence across agents, sessions, and tools?

Static context isn’t enough

A file like AGENTS.md is excellent for relatively stable information:

Use TypeScript.
Run tests before committing.
Don't modify the generated directory.
Use PostgreSQL for persistence.

But real projects continuously change.

A decision made yesterday can be invalid tomorrow.

A failed implementation can be extremely important even though it doesn’t exist in the final codebase.

A workaround can remain in the repository long after the reason for it has been forgotten.

This creates a gap between:

what exists in the repository

and

why the repository looks this way.

That gap becomes increasingly important when multiple AI agents participate in development.

The project needs a state layer

This is the idea I’m exploring with Contorium.

Instead of treating context as something that belongs to a particular AI tool, I’m experimenting with treating project knowledge as a separate layer.

Conceptually:

         AI Agents
  ┌────────┬────────┬────────┐

Cursor Claude Codex Other
│ │ │
└────────┼─────────┘
│
Project Intelligence
│
┌────────┼─────────┐
Decisions History Constraints
│ │ │
Reasoning Outcomes Evolution
│
Project State

The important part is the middle layer.

The coding agent should be replaceable.

The project’s accumulated intelligence shouldn’t be.

Memory is not the same as intelligence

A memory system might tell an agent:

“We tried implementation A last week.”

Project Intelligence should eventually be able to represent something closer to:

“Implementation A was rejected because of constraint B.
Constraint B is still active.
Therefore, don’t reintroduce A unless B has changed.”

That requires more than retrieval.

It requires tracking relationships between:

decisions → reasons → outcomes → current validity

This is one of the areas I’m currently exploring with Contorium.

Why I’m building this

The more I use AI coding tools, the more I notice that switching models isn’t really the problem.

The deeper problem is switching understanding.

I might use one model for architecture, another for implementation, another for debugging, and another for review.

I don’t want each one to reconstruct the project from scratch.

The project should carry its own history.

That’s the basic idea behind Contorium:

A Project Intelligence Layer for AI-assisted development.

It’s still being built, and I’m intentionally developing it in public.

I’m less interested in claiming that this is already solved than in figuring out what the correct abstraction actually is.

If AI agents are becoming increasingly autonomous, perhaps the next important infrastructure isn’t another smarter agent.

Maybe it’s the layer that allows all of those agents to understand the same project.

https://www.contorium.dev/

https://github.com/ContoriumLabs/contorium