Most AI systems still have a very simple relationship with time.
You ask something. The model wakes up, processes the request, gives you an answer, and disappears again.
Maybe the conversation is stored. Maybe the next request includes some memory from earlier. But underneath that, the basic rhythm is still the same: human input comes first, AI activity comes second.
That model works surprisingly well for assistants.
It becomes much less convincing once you start thinking about agents.
I ran into this fairly early while building AdamI. If I wanted the system to feel persistent, memory alone was never going to be enough. A system can remember yesterday and still spend the entire night doing absolutely nothing.
That made me ask a different question:
What does an AI system do when nobody is talking to it?
At first, the answer sounds obvious. Give it a task queue. Let it wake up later. Run a scheduler.
Technically, that part is not very exciting.
But once I started thinking about it seriously, I realized that this is where the difference between an assistant and a persistent system begins to show up.
A chatbot waits for prompts.
A persistent system can have unfinished business.
That sounds like a small distinction. I don’t think it is.
The AI industry is moving in this direction very quickly now. Coding tools are becoming less like autocomplete and more like systems that can take a task, inspect a repository, make changes, run tests, revise their work and continue for much longer periods without constant human prompting. A recent BairesDev survey found that 42% of surveyed developers said AI now writes at least half of their code, up from 12% a year earlier. The interesting part is that developers are not simply disappearing from the loop. Their work is moving upward toward review, debugging, security and architecture.
The market is clearly betting on the same shift. Factory, which builds coding agents for enterprise engineering teams, just raised $200 million at a $5 billion valuation.
That tells me something important about where agents are going.
The next useful AI system will often not be the one that gives the smartest answer in thirty seconds.
It may be the one that can keep working for three hours, stop when necessary, remember what happened, resume tomorrow, notice that an external dependency changed, and continue without forcing the human to reconstruct the entire context every time.
That is much closer to the problem I am trying to solve with AdamI.
The Kernel was one of the first pieces that pushed me in this direction.
I used to think of the model as the center of the system. That is the natural way to think about AI: the model reasons, therefore the model is the intelligence, therefore the model must be the thing everything else revolves around.
But the longer I worked on AdamI, the less useful that mental model became.
A model call is temporary.
It begins, reasons for a while, produces an output, and ends.
The system has to survive all of those calls.
So I started thinking of the model more like cognition and the Kernel more like continuity.
The model can decide what to do.
The Kernel has to remember that there is still something to do after the model is gone.
That distinction becomes very concrete with tasks.
Imagine AdamI starts investigating a problem at 10:30 in the morning. It gathers some information, performs several operations, then reaches a point where it cannot continue because an external dependency is unavailable.
A normal assistant has a very simple failure mode here. The conversation stops.
If I come back tomorrow, I may be able to show it the old conversation and ask it to continue. But I am effectively restarting the system myself.
That is not persistence. It is retrieval.
What I want instead is for the task itself to remain part of the system’s state.
Not just the text describing the task.
The task.
Why it exists. What has already happened. What it is waiting for. When it should be checked again. Which parts have been verified. What failed. What should happen if the system wakes up and discovers that the world has changed while it was waiting.
AdamI now has pieces of this in place: persistent task storage, background processes, lifecycle mechanisms and the ability to carry work across model calls. But I want to be careful about what that means.
AdamI does not currently wake up every morning and invent a meaningful life for itself.
It does not have mature intrinsic drives.
It does not have a reliable general-purpose mechanism that turns everything it notices into self-generated goals.
Those are still research questions.
What it does have is the beginning of something more basic and, I think, more important: the system does not have to forget that something is unfinished simply because the current reasoning process ended.
That changes the architecture.
Once tasks can persist, time becomes part of the system.
A task can be too early.
It can be overdue.
It can be waiting on another task.
It can become irrelevant.
It can become dangerous to continue.
It can require a fresh observation before proceeding.
It can need human approval.
And sometimes the right thing for the system to do is nothing.
That last part has become more interesting to me than I expected.
When people talk about autonomous agents, autonomy is often described through activity.
The agent acts without being asked.
The agent completes more steps.
The agent needs less supervision.
The agent works overnight.
All of that sounds impressive, but a system that is always trying to do something is not necessarily more autonomous. It may simply be less controlled.
Real persistence creates a different problem: the system needs to know when to resume, when to wait, and when to abandon something entirely.
A background process should not mean an infinite loop constantly asking a model, “Is there anything else you want to do?”
That would be expensive, noisy and probably dangerous.
The goal is not constant thought.
The goal is continuity without constant prompting.
This is why I think persistent agents will eventually look less like one long-running model and more like a set of relatively quiet mechanisms surrounding short bursts of cognition.
Most of the time, the system should not need a frontier model.
It should be able to maintain timers, task state, dependencies, simple checks and wake-up conditions cheaply.
Then something changes.
A deadline arrives.
A file changes.
A previous operation finishes.
A threshold is crossed.
A human sends new information.
Only then does deeper reasoning become necessary.
This idea is also one of the reasons AdamI ended up with a dual-brain architecture.
Not every event deserves expensive cognition.
Some things can be handled locally or deterministically. Others need a stronger model.
The point is not to keep an AI “thinking” all day.
The point is to make sure the system knows when thinking is actually required.
That may sound like an implementation detail, but it becomes much more important as agents gain access to real systems.
The industry is already discovering the uncomfortable side of this transition. Frontier labs are now discussing safety coordination more directly, including independent evaluation and shared approaches to higher-risk capabilities.
That makes sense to me because long-running agents change the shape of failure.
A short model response can be wrong.
A persistent agent can remain wrong.
It can wake up later and continue from the wrong state.
It can retry something that should not be retried.
It can execute an old plan after the environment has changed.
It can inherit permissions that made sense yesterday and are no longer appropriate today.
Persistence makes useful things possible, but it also gives mistakes somewhere to live.
That is why several parts of AdamI that originally looked separate are starting to converge.
Memory matters because the past has to influence the future.
Verification matters because the system should not preserve a false version of the past.
Tasks matter because unfinished intentions need somewhere to persist.
The Kernel matters because none of those things can depend on one temporary model context.
And Guardian-style controls matter because continuing an old task is still an action, even if nobody issued a new prompt.
This is probably the biggest change in how I think about AdamI compared with the earliest version.
Originally, I was trying to make the system feel alive.
That led me toward biological metaphors, internal drives and continuous processes.
Some of those ideas were useful. Some produced mechanisms that looked much more convincing than they really were.
Now I care less about whether the system appears continuously active.
I care whether continuity is real.
If AdamI stops for six hours and then resumes the right task, with the right state, under the right permissions, after checking whether the assumptions are still valid, that is more interesting to me than a system that continuously generates internal activity.
Silence is not the absence of persistence.
Sometimes persistence means waiting correctly.
There is another step I have not solved yet.
A task that comes from me is straightforward. I created it. The system remembers it. Later it continues.
The harder question is when AdamI should create a task for itself.
If it notices something unexpected, should that become work?
If memory reveals a recurring problem, should it schedule an investigation?
If one task exposes another issue, should it create a follow-up automatically?
At some point, persistent tasks start touching self-generated goals.
That boundary matters.
I do not want to fake it by letting the model constantly invent things to do and calling that autonomy.
A system producing more goals is not necessarily a system with better goals.
So for now, I am treating task persistence and task generation as two different problems.
First, make sure AdamI can reliably carry an intention through time.
Then ask where new intentions should come from.
That order feels slower, but after rebuilding this project once already, I am increasingly comfortable with slower.
A convincing output is easy.
A mechanism that still works tomorrow is harder.
And for a persistent agent, tomorrow is the whole point.