Building Systems That Can Actually Operate
When I started building AdamI, I thought the difficult part would be intelligence.
Reasoning.
Planning.
Tool use.
Choosing the right model.
Those were the obvious problems.
But after spending more time on persistent agents, I’ve become much less convinced that the model is the hardest part of the system.
A strong model can already do a surprising amount inside a single interaction.
It can write code, inspect files, reason through an unfamiliar problem, call tools, and often recover from small mistakes.
The trouble starts when the interaction is supposed to continue.
What happens after the model call ends?
Who remembers what was happening?
Who knows which actions actually succeeded?
Who decides what can run next?
Who owns the credentials?
Who notices that something failed three hours later?
Who decides whether to retry, roll back, switch models, or ask a human?
That is the point where an agent stops looking like a prompt wrapped around a model.
It starts needing a runtime.
For me, this has been one of the biggest changes in how I think about AI systems.
The model provides cognition.
The runtime provides continuity.
And once continuity matters, a whole set of engineering problems appears that has very little to do with benchmark scores.
A model can decide what should happen next.
But something else has to keep the system alive long enough for “next” to mean anything.
That layer has to maintain state across model calls, process unfinished work, decide when to wake the model again, and keep track of what happened while the model was not running.
In AdamI, this is why the Kernel became increasingly important.
It is not the intelligence layer.
It is the part that keeps the system present between bursts of intelligence.
That distinction sounds small, but it changes the architecture.
A persistent agent should not need a frontier model thinking every second.
Most of the time, nothing interesting is happening.
A task may be waiting for an external service.
A file may not have changed.
A process may still be running.
A user may not have approved the next action yet.
The system has to remain alive without constantly generating thoughts.
That means persistence is not continuous cognition.
It is continuous state.
And state creates another problem immediately: memory.
I used to think of memory mostly as retrieval.
Store useful information, embed it, search it later, put it back into context.
That is useful, but it is not enough for a long-running system.
Once stored information can change future behavior, memory becomes part of the runtime.
A past event may change how the agent plans.
It may change which tool it selects.
It may change how much confidence it has in a result.
It may even change whether an action is allowed.
At that point, memory is no longer just something the model reads.
It is part of system state.
This is also where provenance starts to matter.
If an agent remembers that a deployment method is correct, where did that belief come from?
Was it observed once?
Was it verified?
Was it copied from another agent?
Was it inferred from an outdated file?
Can it expire?
Can it be revoked?
Without those answers, persistent memory can quietly turn old mistakes into future behavior.
The longer the agent runs, the more dangerous that becomes.
Permissions create a similar problem.
Giving a model access to a tool is easy.
Deciding when it should be allowed to use that tool is much harder.
A system that can write code, open network connections, use credentials, modify files, or call external APIs needs more than a list of available functions.
It needs authority boundaries.
Which identity is performing this action?
Who granted the permission?
What is the scope?
Does the permission expire?
Can it be revoked?
Does this action require approval?
Should a sub-agent inherit the same authority?
This is why I increasingly think agent safety will live partly outside the model.
The model can reason about whether an action seems appropriate.
But the runtime still needs the ability to say no.
Capability and authority should not be the same thing.
Another layer that became much more important than I expected is verification.
Agents are very good at telling you that they completed something.
That does not mean it happened.
A tool call may return success while the external state is wrong.
A command may run without producing the intended result.
A deployment may finish while the new version is not actually serving traffic.
A file may be written but contain the wrong content.
So the runtime needs to distinguish between an attempted action and a verified outcome.
That sounds obvious in traditional software engineering, but it becomes easy to blur when a language model is narrating the process.
A convincing explanation is not evidence.
The system needs postconditions.
It needs observations.
It needs independent checks where possible.
And if the evidence is incomplete, uncertainty should remain part of the state.
That leads naturally to recovery.
I think this is one of the least discussed parts of agent architecture.
We talk constantly about planning.
Much less about what happens when the plan fails halfway through.
Should the system retry?
How many times?
Should it use the same model?
Should it route the task to another model?
Should it restore a previous state?
Should it ask another agent to inspect the failure?
Should it stop and wait for a human?
This is where orchestration becomes more than task assignment.
It becomes recovery architecture.
A mature agent runtime will probably spend a surprising amount of its effort deciding not how to succeed the first time, but how to recover safely when success does not happen.
That also changes how I think about multi-model and multi-agent systems.
The obvious use case is specialization.
One model plans.
Another writes code.
A cheaper local model handles routine work.
Another model reviews security.
That is useful.
But routing based only on capability is probably not enough.
The runtime also needs to route based on risk, cost, uncertainty, permissions, and failure state.
Sometimes the best model is not the right model.
Sometimes the system should use a weaker model because the task is cheap and reversible.
Sometimes it should use two independent models because the result matters.
Sometimes no model should act at all.
That last case matters more than it sounds.
Autonomy is not just the ability to continue acting.
It is also the ability to know when the correct next action is to wait.
All of this makes observability essential.
If a persistent system is going to operate for hours, days, or longer, I need to know what it is doing without reading a transcript of every model call.
What tasks are active?
What is waiting?
What failed?
What has been verified?
What changed in memory?
Which permissions were used?
Which model made which decision?
What state is currently uncertain?
Traditional software already has logs, metrics, traces, and health checks for a reason.
Agents will need their own version of the same discipline.
Probably more of it, not less.
Because their behavior is less deterministic.
This is roughly where AdamI is today.
There is a Kernel responsible for continuity.
There is an Orchestrator for coordinating work.
There are memory layers and an ExperienceSink.
There is a HybridLLMRouter for choosing between different model roles.
There are task persistence mechanisms, skills, peripherals, Guardian controls, and early observability pieces.
But these parts are not yet a clean, finished runtime architecture.
Some boundaries are still messy.
Memory and task state are not always as clearly separated as they should be.
Verification is improving, but not every important action has a strong postcondition.
Recovery logic is still more limited than I want.
Permissions and ownership need to become more explicit as the system gains more capability.
That is exactly why I find this layer interesting.
The problem is no longer “How do I connect a model to tools?”
That part is becoming easy.
The harder problem is:
How do I build a system that can keep operating without slowly losing control of its own state?
I currently think of the runtime as the place where several things come together:
identity,
memory,
permissions,
orchestration,
verification,
recovery,
and observability.
Not because these need to become one giant component.
They should not.
But they need to share a coherent model of what the system is, what it is allowed to do, what it believes happened, and what should happen next.
That coherence may matter more than any individual subsystem.
A smarter model gives you better decisions.
A persistent runtime gives those decisions continuity.
Permissions give them boundaries.
Verification gives them evidence.
Recovery gives them resilience.
And observability gives humans a way to understand what the system is becoming.
I used to think the model would be the center of an autonomous AI system.
Now I think the model may eventually become one of the most replaceable parts.
Models will improve.
Different models will be better at different things.
Prices will change.
Local models will become stronger.
New providers will appear.
But the runtime will still need to remember the system’s history, preserve its identity, enforce its boundaries, recover from failure, and coordinate everything around the model.
That is a much more durable layer.
The brain provides cognition.
The runtime provides continuity.
And if we ever want agents that can operate reliably for long periods of time, continuity may turn out to be the harder problem.