Coding agents don’t need more context. They need continuity.

Santi Santamaría Medel — Sat, 09 May 2026 10:03:45 +0000

I’ve been working with coding agents for quite a while now.
I’ve been a software engineer for more than 15 years, and at first it was hard for me to accept that the rules of the game had changed forever.

I’ve stopped thinking of coding agents as autocomplete. In many tasks, they can reason through codebases and produce solid implementations. But one thing still feels missing.

I haven’t managed to feel that I’m working side by side with an engineer who knows the repository. Someone familiar with the project’s codebase, its strategies, its typical errors, the commands that should be run and the ones that shouldn’t.
A veteran teammate, not a rookie who has to review the whole repo, starting from the README and the Makefile, before writing a single line of code.

At first I thought it was all about refining prompts.

Then I focused on operational memory, skills, MCPs, rules, global instructions, AGENTS.md, CLAUDE.md, and everything I kept reading over and over again in articles and posts.

I also had a “context” phase. I became obsessed with improving the context my agent was working with.

And yet I still had the same feeling.

The more I obsessed over prompts, memory, skills, and context, the more I started to feel that what the agent was missing was continuity.
Something more human. Something closer to what a teammate would ask on their first day at work:

Where were we?
What did we do yesterday?
What hypotheses did we discard?
Which file mattered?
Which test was the right one?
What should I not touch?
Where do I start?

Since I work intensively in large repositories, I saw a major limitation in Codex (the agent I use mainly) starting every session again from the README. It frustrated me to watch it rediscover the repo, try overly broad commands, or attempt to run huge test suites that had nothing to do with the task at hand.

So I started building a tool focused on operational continuity.

I called it AICTX.

In one sentence: aictx is a repo-local continuity runtime for coding agents.

The idea is that each new session behaves less like an isolated prompt and more like the same repo-native engineer continuing previous work.

After many iterations, the workflow has consolidated into something like this:

user prompt
→ agent extracts a narrow task goal
→ aictx resume gives repo-local continuity
→ agent receives an execution contract
→ agent works
→ aictx finalize stores what happened
→ next session starts from continuity, not from zero
→ the user receives feedback about continuity

AICTX stores and reuses things like work state, handoffs, decisions, failure memory, strategy memory, execution summaries, RepoMap hints, execution contracts, and contract compliance signals.

All of them are auditable artifacts that are easy to inspect at repo level.

On the other hand, one of the things I like most about the tool is that I can enable portability and keep the most important continuity artifacts versioned, so I can continue the task on my personal laptop, my work laptop, or anywhere else.

The execution contract part feels especially interesting to me. Instead of giving the agent a vague block of context, AICTX tries to give it an operational route:

first_action
edit_scope
test_command
finalize_command
contract_strength

I wanted to check whether this actually worked, not just rely on my own impressions while watching the agent work with AICTX. So I created a small Python demo repo and ran the same two-session task twice:

Before talking about the test itself, it’s worth stressing that I mainly work with Codex, so the test has the most validity and accuracy with Codex.

The task was intentionally simple: add support for a new BLOCKED status, and then continue in a second session to validate parser edge cases.

This is important: the demo is not designed under conditions where AICTX has the maximum possible advantage. The repository is small, the task is simple, and the continuation prompt without AICTX includes enough manual context.

Even so, in the second session a clear difference appeared.

(Note: all demo metrics are available here)

Session 2

Metric	with_aictx	without_aictx	Difference
Files explored	5	10	-50.0%
Files edited	1	3	-66.7%
Commands run	8	15	-46.7%
Tests run	1	4	-75.0%
Exploration steps before first edit	6	15	-60.0%
Time to complete	72s	119s	-39.5%
Total tokens	208,470	296,157	-29.6%
API reference cost	$0.5983	$0.8789	-31.9%

The most interesting difference for me was not the tokens. It was where the agent started.

With AICTX:

first_relevant_file = tests/test_parser.py first_edit_file = tests/test_parser.py

Without AICTX:

first_relevant_file = README.md first_edit_file = src/taskflow/parser.py

With AICTX, the second session behaved more like an operational continuation.
Without AICTX, it behaved more like a new agent reconstructing the state of the project.

Across both sessions, the savings were more moderate:

Metric	with_aictx	without_aictx	Difference
Files explored	13	19	-31.6%
Commands run	19	26	-26.9%
Tests run	3	6	-50.0%
Time to complete	166s	222s	-25.2%
Total tokens	455,965	492,800	-7.5%
API reference cost	$1.3129	$1.4591	-10.0%

Honest result: AICTX did not magically win at everything.

In the first session, it had overhead. There wasn’t much accumulated continuity to reuse yet, so it doesn’t make sense to sell it as a universal token saver.

There is also another important nuance: the execution without AICTX found and fixed an additional edge case related to UTF-8 BOM input. So I also wouldn’t say that AICTX produced “better code.”

The honest conclusion would be this:

AICTX produced a correct, more focused continuation with less repo rediscovery.

The execution without AICTX produced a broader solution, but it needed more exploration, more commands, more tests, and more time.

For me, this fits the initial hypothesis quite well:

AICTX is not a magical token saver.
It has overhead in the first session.
Its value appears when work continues across sessions.
The real problem is not just “giving the model more context.”
The problem is making each agent session feel less like starting from zero.

And I suspect this demo actually reduces the real size of the problem. In a large repo, where the previous session left decisions, failed attempts, scope boundaries, correct test commands, and known risks, continuity should matter more.

I still don’t fully get the feeling of continuity I’m looking for, but I’m starting to get closer. To push that feeling a bit further, AICTX makes the agent give operational-continuity feedback to the user through a startup banner at the beginning of each session and a summary output at the end of each execution.

The tool is still alive, and I’m still scaling it while trying to solve my own pains. I’d love to receive feedback: positive things, possible improvements, issues people notice, or even PRs if anyone feels like contributing.

If anyone wants to try it:

    pipx install aictx
    aictx install
    cd repo_path
    aictx init
    # then just work with your coding agent as usual

With AICTX, I’m not trying to replace good prompts, skills, or already established memory/context-management tools. I’m simply trying to make operational continuity easier in large code repositories that I iterate on once and again.

I’d be really happy if it ends up being useful to someone along the way.

If you try it, I’d love to know whether it improves your workflow, or whether it gets in the way.

I tried writing an interactive novel. I accidentally ended up building a platform.

Santi Santamaría Medel — Fri, 06 Mar 2026 13:45:26 +0000

A few months ago I tried to write an interactive fiction novel. I accidentally ended up building a platform instead.

I started writing but as the story grew, I quickly realised two things:

First, I’m not a great writer — and even less so when it comes to an interactive novel with all its complexity.
Second, the further I got, the harder it became to manage the structure: branches, conditions, narrative state… everything started getting messy pretty quickly.

The tools I tried didn’t really fit what I had in mind, so at some point I opened Visual Studio and tried to solve the problem myself.

The idea was simple: I wanted to find a way to separate the prose from the logic that drives the story.

That’s when the real experiment started.

Since frontend isn’t really my main area, instead of trying to do everything myself I decided to try something different: building the project with AI agents (Codex) as development partners.

What started as a small experiment quickly got out of hand. I got carried away and ended up building a small platform.

Working with Codex, as an not so small dev team

Working with Codex — and the workflow I gradually developed around it — turned out to be surprisingly effective. Instead of just asking for snippets, I started treating the AI more like a small development team: iterating on architecture, building components, debugging problems together and refining ideas step by step.

This AI-assisted workflow made it possible to move surprisingly fast across several areas at once: coding, UI design and architectural decisions.
It also became a really interesting learning experience about how to work with AI agents: improving context management, performance and model behaviour.

The IEPUB project

The result of that whole process is a small ecosystem called iepub:

a structured format for interactive books
a reader runtime that interprets that format
and a visual editor designed for writing interactive fiction

It had gone completely out of control…

The editor tries to feel like a normal writing tool — something closer to Google Docs — but designed for interactive storytelling. It allows things like:

defining narrative condition
attaching variables to sections of the story
configuring dice rolls or probabilistic events
creating narrative variants, based on both, declarative conditions and user behaviour while reading conditions (really cool!)
visualising the structure of the story as a graph
importing and transforming content from the most extended formats

If anyone is curious about the experiment — both the project itself and the AI-assisted development workflow — you can take a look at the article I published on Medium:

https://medium.com/@santi.santamaria.medel/interactive-fiction-platform-codex-ai-093358665827

And if you just want to explore the project itself, you can do that here:

https://iepub.io

I’d also love to hear how others are using AI in their development workflows, and learn!