EvoContext — governance and continuity for autonomous agents

Autonomy needs governance and continuity. EvoContext gives the project its own memory. Agent work becomes part of the project, so every new session, agent, and model starts with the same knowledge.

Comment

Inspiration

I didn’t start by trying to build a memory system. Actually, I wasn’t thinking about memory at all. I was interested in a different question.

How can I give autonomy to my coding agents and make my life easier? The first goal was simple: give them enough autonomy to build demos for my customers. I’m not a developer. I’m a sales/pre-sales senior manager. Building a customer demo is usually a long-running cycle in our daily work. And it’s not only about the technical implementation. It’s about mapping technical capabilities to a customer's business context and needs.

I tried different coding agents from Anthropic, OpenAI, and even local small LLMs. Like most people, I started by giving them more capabilities. More tools. More access. More responsibility.

That helped. But after a while I noticed something that kept repeating. Every new session spent time trying to understand the project before it could do any useful work. Frontier agents have best-in-class memory systems, but that memory belongs to the agent—not to the project.

Agent can say:

"I remember you."

But they still may not answer most project-specific questions:

  • What has this project already learned?
  • Which solution was verified?
  • Why was this architecture chosen?
  • Which experiments failed?
  • What assumptions are still valid?
  • What should every future agent know?

The agent wasn't writing code. It was reconstructing context. Reading files. Looking through previous chats. Checking commits. Trying to understand why something had been done. Sometimes it rediscovered the same issue. Sometimes it suggested something we'd already decided against.

The strange part was that nothing had actually been lost. The information existed. It just didn't belong to the project. I noticed this most clearly while building EvoContext itself.

I had several agent sessions working in parallel. Each model has its own strengths. One was helping with packaging and wording. Another with testing. Another with implementation and building the story. ChatGPT models are brilliant at storytelling. All of them produced useful work, but every new session still had to answer the same questions:

  • What do we already know?
  • What has already been verified?
  • What is still open?

After seeing this happen enough times, I realized I wasn't looking at a memory problem.

You might ask:

Why not use one of the many popular memory engines already available?

They retrieve useful facts from previous conversations. That wasn't my main problem.

I was looking at a continuity problem when agent uses the memory itself, like children do. The agent needed to use knowledge the same way children learn about the world, by connecting the past with the present.

That completely changed how I thought about autonomy. Models matter. Tools matter. Prompts matter.

But if every session has to rediscover the project... If every session loses the connection between "past" and "now"... ...the agent never really moves forward.

It's very similar to the dominoes story I often use and tell about. That's where EvoContext came from.

The idea is simple. The project should own what it has learned. Not the chat. Not the model. Not the vendor.

The project.

What it does

EvoContext gives a project a way to retain verified knowledge across sessions. When a new agent starts working, it doesn't begin with an empty conversation. It begins with the project's current understanding.

During the session, the agent can review previous work and record new verified updates. Those become part of the project's intelligence instead of going away when the conversation ends.

A few principles guided almost every design decision:

  1. The context belongs to the repository.
  2. Every event is attributable.
  3. History isn't rewritten when something changes.
  4. Corrections become new events.
  5. Multiple agents should be able to work on the same project without silently overwriting one another.
  6. The current view should always be reproducible from recorded history.

The goal isn't to replace reasoning. It's to let agents use knowledge natively (the way children learn about the world) by understanding the relationship between cause and effect.

How we built it

The draft foundation of the event engine already existed before Build Week. During Build Week I focused on turning it into something people could actually install and use inside Codex, Claude Code, or any other agent supporting AGENTS.md or CLAUDE.md.

Most of the work wasn't about algorithms. It was about everything around them:

  • Description
  • Packaging
  • Installation
  • Onboarding
  • Testing
  • Performance improvements
  • Safety
  • Developer experience

Codex was part of the process from the very beginning. I almost always use at least two different models to increase confidence in decisions and improve accuracy. Sometimes Codex suggested implementations. Sometimes it challenged assumptions. Sometimes it found edge cases I hadn't considered.

I treated it as another engineer on the project. The architecture, product decisions, safety guarantees, documentation, and final acceptance stayed with me.

Challenges we ran into

The biggest challenge was realizing that memory is easy. Good memory is hard. Keeping more text isn't enough. The difficult part is deciding what deserves to become part of the project's long-term knowledge. And how to make agent identify it on its own without me, how to make agent to use it.

Another challenge was portability. Why do I need portability? First, I want to handover core product expertise to any agent in my ecosystem. Second, if you're working in a team or selling consulting products, portability allows you to build highly specialized product expertise for end users.

A great example, I used portability for BI tool. Instead of having a night batches to pre-build dashboards, we can easily import agent inteligence and give end-user a very flexible and smart exprtise to build anything they want in complience with company rules. You remember that we have Terms of Services component for autonomy.

Every coding agent has different startup behavior, different permissions, and different ways of extending itself. I didn’t want correctness to depend on a prompt.

I wanted it to come from the engine. Packaging also turned out to be much more important than I expected. The source repository can be correct while the release artifact isn’t.

A source repository can be correct while the release artifact isn't.

That's why the installer, package contents, checksums, and validation became part of the product instead of an afterthought.

Accomplishments that I'm proud of

What I'm most happy about is that EvoContext isn't just an idea. It's something people can actually inspect, install, and test.

During Build Week I built a complete Codex experience around the existing engine, including:

  • Plugin
  • Installer
  • Packaging
  • SessionStart integration
  • Deterministic replay
  • Concurrent writes
  • Comprehensive testing

One thing that mattered to me from the beginning was keeping the project understandable. I wanted something small enough that another engineer could read it, but complete enough that they could trust it.

What we learned

The biggest lesson for me is that autonomy isn't only about intelligence. It's also about continuity. An agent with more tools isn't necessarily more useful. An agent that understands the project usually is.

I also learned that access isn't the same as understanding. Giving an agent filesystem access, shell access, or more permissions doesn't mean it understands what's happening. The project still needs to explain itself.

The critical part came last. Autonomy or freedom means we must have not to do rules. Agents must need as well. It levels up the inteligence maturity immediatly.

Finally, I learned that agent works best when it becomes part of the engineering process instead of replacing it. The best results came from discussion, iteration, and testing, not from accepting the first answer. More discussions - more intelligence - more value.

What's next for EvoContext — continuity for autonomous agents

I don't see EvoContext as another agent framework. I see it as one missing piece.

If autonomous agents are going to become part of everyday software development, projects need a way to preserve what they've already learned. That's where I want to keep going.

The next steps are:

  • Measuring how much continuity reduces rediscovery
  • Improving multi-agent collaboration
  • Making project knowledge portable across different clients
  • Understanding which kinds of knowledge are worth keeping over time

Models will continue to improve.

Agents will continue to improve.

I think projects should improve too.

Built With

Share this project:

Updates