Why I Built Chronicles Without an LLM
There is a very tempting pattern when building anything around AI.
You find a problem, add an LLM, give it some context, and suddenly it feels like the problem is solved.
I almost did exactly that with Chronicles.
But the more I thought about the problem I was actually trying to solve, the more I realized that I didn't need an LLM for the first version.
I needed something much simpler.
A memory layer.
The Problem
AI coding agents can do a lot.
They can read files, call tools, write code, run commands, inspect errors, and reason about what to do next.
But there is one thing they don't naturally have:
A reliable memory of the work that happened before.
An agent can understand the current state of a repository, but that doesn't necessarily mean it understands how the repository got there.
It might know that a function exists.
It might not know why it was added.
It might see a configuration file.
It might not know what problem that configuration was meant to solve.
It might inspect the current branch.
It might not remember what happened on another branch last week.
That distinction started bothering me.
Because context and memory are not the same thing.
The Easy Answer Was an LLM
The obvious solution was to use another LLM.
Take the project's history.
Feed it into a model.
Let the model summarize it.
Generate embeddings.
Store everything in a vector database.
Then retrieve the relevant memories when an agent needs them.
That sounds reasonable.
And eventually, something like that may be useful.
But I realized I was trying to solve two different problems at once.
First:
How should an AI software engineering system remember things?
Second:
How should that memory be made intelligent?
I didn't think I needed to solve the second problem before understanding the first.
So I went back to the primitive.
Start With the Primitive
The first version of Chronicles is deliberately boring.
It is built with Python, SQLAlchemy, and SQLite.
There is no LLM managing the memory.
There is no RAG pipeline.
There is no embedding model deciding what is important.
Instead, Chronicles focuses on structured information.
Things like:
- observations
- relationships
- snapshots
- confidence
- branches
- verification
- memory decay
The goal is to make memory something that can actually be inspected.
If the system remembers something, I should be able to see what it remembers.
If something is wrong, I should be able to trace where it came from.
If confidence changes, I should be able to understand why.
That felt much more useful for a first version than hiding everything behind another model.
Boring Is Useful
There is a certain appeal to making everything intelligent.
But sometimes intelligence makes systems harder to understand.
Imagine asking an LLM:
Why does the system believe this?
You might get an explanation.
But the explanation itself is another generated output.
With structured memory, I can inspect the actual data.
There is something satisfying about that.
Not because structured data is exciting.
It isn't.
But because predictable systems are easier to build on.
I wanted Chronicles to establish the foundation before adding anything that could make that foundation harder to reason about.
Verification Matters
Memory is only useful if you can trust it.
That means Chronicles treats verification as a separate concern.
The idea is simple:
Reading memory should not silently change memory.
Verification should be read-only.
That makes it easier to inspect what the system knows without accidentally modifying the state while checking it.
This might sound like a small design decision.
For a memory system, I don't think it is.
If the thing responsible for remembering can casually rewrite what it remembers while you are trying to inspect it, debugging becomes a strange game of chasing your own footprints.
Local First
Another deliberate choice was keeping Chronicles local-first.
The first version uses SQLite.
That gives me a small, inspectable system that can run without depending on a remote service.
It also fits the problem.
A memory layer for AI software engineering shouldn't necessarily require sending a project's history somewhere else just to remember what happened.
Local storage makes experimentation easier too.
I can inspect the database.
I can test the behavior.
I can break things.
I can rebuild them.
There is no external infrastructure standing between me and the thing I'm trying to understand.
This Doesn't Mean LLMs Don't Belong Here
I don't think the conclusion is that Chronicles should never use an LLM.
Quite the opposite.
There are plenty of places where an LLM could eventually be useful.
It could help identify important observations.
It could summarize related memories.
It could help decide which pieces of historical context are relevant to a task.
It could make retrieval more semantic.
Those are interesting problems.
But they are problems I want to approach after the underlying memory model makes sense.
Otherwise, I would be asking a model to hide complexity that I haven't understood yet.
Build the Foundation First
This is probably the biggest lesson I got from building Chronicles so far.
When building AI systems, it is very easy to jump directly to the intelligent part.
Add an LLM.
Add RAG.
Add agents.
Add embeddings.
Add another model.
Before long, the architecture looks impressive, but it becomes difficult to tell which part is actually solving the original problem.
I wanted to take the opposite approach.
Start with the smallest useful primitive.
Make it inspectable.
Make it testable.
Make it predictable.
Then build intelligence on top of it.
Why Chronicles Exists
That is ultimately why I built Chronicles.
Not as another chatbot.
Not as another agent.
But as a shared memory layer for AI software engineering.
The first version doesn't try to make memory intelligent.
It tries to make memory understandable.
And I think that's an important distinction.
The goal is to give AI coding agents a way to carry useful history across tasks, sessions, and branches without making the memory itself a black box.
That's why the first version of Chronicles doesn't have an LLM or RAG at its core.
I wanted to build the memory layer before trying to make the memory intelligent.
Maybe that's less flashy.
But it gives me something I can actually inspect, test, and build on.
And for a system whose entire purpose is to remember, I think that's a pretty good place to start.
Chronicles
Chronicles is the shared memory layer I'm building for AI software engineering.
