Repo-local continuity runtime for AI coding agents. Inspectable, visual, portable, cross-agent.

The problem is well known by every coder: every new Codex / Claude / Copilot and other coding agent session kept rediscovering the same repo structure, files, decisions, failed commands, current task state, and validation steps, wasting context and tokens. On the other hand if you change from an agent to another they have to start from the scratch without reusing what the previous one already learnt.

First shots

I have been trying to work around that problem with different approaches: small handoffs, heavy memory systems, context engines...

Continuity

I finally found it: Operational continuity for AI coding agents. I built an open-source continuity runtime so agents don’t restart from zero every session, and it already made my own AI coding workflow feel much less like restarting from scratch every time.

The continuity idea is not to add more hidden memory or dump more context into the prompt. AICTX keeps operational continuity inside the repo:

• active Work State and next action;

• execution summaries and handoffs;

• explicit decisions;

• known failures and resolved failure patterns;

• strategy hints from successful prior work;

• execution contracts and contract-compliance signals;

• optional RepoMap structural entry points;

• continuity quality signals for stale, missing, demoted, obsolete, or unverified context;

• read-only Task Context Packs for focused task-specific context;

• lifecycle diagnostics for incomplete or unfinalized sessions;

• optional Git-portable continuity for small teams.

The next agent should resume from what actually happened, not infer everything again from README + chat history.

Cross-Agent continuity

I’ve been switching between Codex, Claude Code and Copilot depending on the task and, honestly, sometimes depending on which one still has credits left.

Every time I switch from one agent to another, or even start a new session with the same agent, I don’t just lose chat history.

It feels like each agent/session starts from a different version of the project reality.

And again and again I find myself repeating context.

The principle I follow is:

different agents, different sessions, same repo continuity.

One agent leaves Work State, failures, decisions, handoffs and validation evidence in the project. Another agent (or a new session of the same one ) can pick it up later through MCP tools, with CLI fallback when needed.

Execution Contracts

Each resume can include a compact contract for the next agent: first action, edit scope, canonical validation command, expected evidence, and finalize instruction. The goal is not only “remember context”, but guide the next execution safely.

Continuity quality

Scores repo-local continuity freshness and flags stale, missing, demoted, obsolete, or unverified context so that agents can avoid trusting old memory blindly and treat weak continuity as background evidence.

Continuity View

I’m experimenting with a deterministic Mermaid continuity view generated from repo-local AICTX artifacts. It shows the current operational state of the repo visually: Work State, open handoffs, relevant failures, execution contracts, summaries, RepoMap hints, and portable continuity status.

Here you can see what it looks like.

The link to this view can be returned after each task, so the next session has an inspectable continuity map. I’m still working on making it easier to read.

Portability

The continuity lives with the repository. The idea is that useful operational state should not be locked inside one chat, one vendor, one local machine, or one agent tool. If the repo moves, the continuity can move with it ... if you want it to!

Easy to use

pip install aictx

aictx install

aictx init

# Then keep using your coding agent normally

MCP support

It also provides MCP support so compatible agents can access AICTX continuity directly as tools, resources and prompts instead of only relying on repo instructions and CLI commands.

The MCP server is local-first. It is not a cloud memory service, not a daemon you have to manage manually, and not a generic shell/filesystem server. Compatible agents launch it locally through stdio.

I’m also packaging Claude Code and Codex plugin artifacts around the same model: MCP-first when available, CLI fallback when not. Copilot support remains best-effort through repo instructions and VS Code MCP config where supported.

The medium-term benefit

Agent-based development starts to feel less like a sequence of isolated chats and more like an ongoing engineering process:

• less rediscovery;

• better context management

• fewer repeated failed commands;

• clearer handoffs;

• better validation discipline;

• less instruction boilerplate once agents can call AICTX through MCP;

• a cleaner path for Claude, Codex and Copilot integrations;

• easier switching between Codex, Claude, Copilot or other agents;

• and a repo that can explain its current state to the next session.

Stop onboarding your coding agents like rookies every session