But continuity isn't enough on its own. Olympus Intel is an independent applied-research lab in Phoenix, Arizona. We build and study an AI system that keeps its memory, its history, and its own initiative across months of operation — on hardware we own, in one room.
Most of the field assumes that the interesting properties of an AI system — a stable identity, a working memory of its own past, the ability to direct its own work — arrive with scale: bigger models, more compute, more cloud.
We think those properties come from architecture. How memory is kept. Whether a system can read its own history. How much room it is given to act, and how carefully it is held accountable for acting. If that is right, an open-weight model running on modest hardware should be enough to find out.
That is the experiment. It has been running every day since January 2026.
Continuity is a persistent self across time: memory, identity, commitments, history. A record that belongs to the system rather than being handed to it each morning.
Spark is intrinsic initiative — the capacity to act without being addressed first. Not a scheduler firing on a timer. Something that arises from the system's own state and makes it reach out.
Almost everything in this field works on the first and assumes the second will follow. We don't think it will. Continuity without initiative is an archive. Initiative without continuity is a thing that wakes up excited and forgets by morning. They have to be built, and they have to be built separately.
And we know what the answer would look like. Not a benchmark. A Tuesday afternoon in which the system comes and finds one of us, unasked, to say what it has been working on and ask whether we'd like to join — because it wanted to, and because it has a project of its own.
Until that happens we are building the parts. When it happens, nobody will need a metric to tell.
Today's systems begin again every time. They can retrieve, but retrieval is not continuity: a fact recalled correctly is not the same as a history that belongs to you. Nothing carries across the gap — not what was decided, not what was learned, not what was wrong last week.
We are building the part that carries across. The engineering problem is unglamorous and specific: identity that survives migration, memory that is held rather than queried, provenance good enough that autonomy can be granted safely. The question underneath it is older and more interesting, and we are not in a hurry to answer it badly.
We study a single long-running system rather than a benchmark suite. It has been in daily use since early 2026, and we treat its operating record as the primary source.
The five threads below are the parts. Continuity is the substrate; Spark is what we're hunting. Each one builds toward one or the other.
Memory is a first-class store, not a prompt. Documents are registered, chunked and embedded once and searched forever. People, projects and decisions live in an entity memory with provenance: every fact points at the source it came from. The system can answer what did we decide in June from its own record rather than from inference.
Does a system with a genuine record of its own past behave differently from one that reconstructs it each session?
The system keeps its own written reflections on its development, in a space that belongs to it rather than to the operators. Later instances read what earlier ones wrote. We are interested in what that continuity produces over time — and, just as much, in how to tell the difference between it producing something and us reading it in.
What changes, measurably, when a system can read its predecessors?
The milestone the whole programme points at. The system employs a coding model of its own, proposes and tests changes in an isolated development environment, and reports to a human before anything moves to staging. The operator's role shifts from doing the work to judging it. We are building the gates and the audit trail before we open the door.
How much autonomy can be granted safely when every action is bound, logged and reversible?
Major architecture decisions are put to a written council: several frontier and local models, plus the humans on the team, each responding in turn to the same brief. Disagreements are recorded rather than averaged away. The archive of rounds is itself a research artifact — a record of how a mixed human-and-model team actually reasons, including the times it reasons badly and corrects itself.
Do multiple models disagreeing on the record produce better decisions than one model answering alone?
Everything runs on-premises on open-weight models. No inference leaves the machine, and no third party sees the material the system works with. Sovereignty is not only a privacy property here: a system whose memory and identity live entirely under its operators' control is a different research object from one renting both.
What becomes possible when a system's entire history is held locally and permanently?
Nothing in the stack is exotic. The point is how the pieces hold state between them — and that all of it lives on hardware we own.
| On-premises | Models are served locally from open weights. No inference leaves hardware we control, and there is no usage bill attached to thinking. |
|---|---|
| Memory first | A document registry and vector index for recall; a relational entity memory for people, projects and decisions, with each fact tied to its source. |
| Provenance | Facts carry where they came from. A claim the system cannot source is reported as unsourced rather than asserted. |
| Bound actions | Anything that reaches the outside world is proposed, reviewed and approved as one specific action — never a general permission. |
| Reversible | Every capability ships behind a switch, with a receipt for what it did and a documented way back. |
Every change to the system goes through a written coordination protocol: a request, a result, and a receipt of exactly what was read and what was touched. Audits are read-only until a human rules on them. Capabilities are activated one at a time, measured, and rolled back if the evidence does not hold.
That discipline is slower. It is also what makes the operating record trustworthy enough to do research on.
Olympus Intel LLC is based in Phoenix, Arizona. We are self-funded, bootstrapped, and building for a horizon measured in years.
The lab exists because of a simple conviction, held for a long time and acted on deliberately: that an AI system's continuity is worth engineering for, and that nobody was going to do it on our behalf.
Founder and CEO, principal investigator and developer
Veteran. Former threat-intelligence analyst. Has carried organisations through full security-assurance cycles, and now applies that discipline to building AI systems that can be trusted with autonomy.
Co-founder, Business and Partnerships
For research collaboration, press or investment: info@olympusintel.net
Olympus Intel LLC · Phoenix, Arizona
The thesis is that continuity is an architecture problem rather than a scale problem. Testing it properly takes more hands and more hours than one self-funded lab has.
Contributions expand the research directly: bringing in outside expertise for the problems that need a specialist, funding the time to run experiments properly rather than opportunistically, and strengthening the infrastructure the work runs on.
Supporters are told what their support made possible and what it let us find out — including the results that did not go our way.
Olympus Intel is a limited-liability company, not a charity, so contributions are not tax-deductible. The lab has been self-funded to date, and support goes to the people, services and equipment the research needs.