There is a failure mode I keep coming back to while building AdamI.
Not failure in the obvious sense.
Not a crashed process. Not a rejected API call. Not a test that turns red.
Something more awkward:
the system did something, saw some evidence, but still cannot honestly tell whether the thing actually worked.
That sounds like a small edge case.
I don’t think it is.
The longer an agent is allowed to keep working, the more dangerous false certainty becomes.
A chatbot can guess wrong and the conversation may end there.
A persistent system can guess wrong, save that guess, make another decision based on it tomorrow, and eventually let several other parts of the system treat the original guess as fact.
That changes the problem.
The question is no longer only:
Did the action succeed?
Sometimes the better question is:
Do I have enough evidence to believe it succeeded?
Those are not the same thing.
An action is not a result
I wrote about this in Digital Life Log #009.
A tool call returning successfully does not prove that the intended change happened in the outside world.
A command can exit with code 0 while producing the wrong output.
An API can acknowledge a request before downstream processing fails.
A browser automation step can click the right button while the page silently rejects the change.
A file can appear to upload while the remote copy is incomplete.
An agent can report that a task is complete because it reached the end of its own procedure.
None of these are necessarily verified outcomes.
That is why I started separating states such as:
attempted
observed
verified
uncertain
At first this looked like bookkeeping.
It turned out to be more important than that.
These states affect what the system is allowed to believe next.
The uncomfortable state between success and failure
Most software likes clean outcomes.
Success.
Failure.
True.
False.
Done.
Not done.
The real world is often less cooperative.
Sometimes the evidence is incomplete.
Sometimes two observations disagree.
Sometimes the system can see that something changed but cannot confirm the exact final state.
Sometimes the only available confirmation comes from the same component that performed the action.
Sometimes verification itself fails.
In those cases, forcing the system to choose between success and failure creates information that did not actually exist.
That is the part I find dangerous.
If AdamI says “success” because success seems likely, that is not just a temporary mistake.
In a persistent architecture, that state may survive the model call.
It may enter memory.
It may change a task from open to complete.
It may unblock another task.
It may influence a later model.
It may become part of the evidence another agent sees.
A weak assumption can slowly turn into system history.
Uncertainty needs somewhere to live
This is where persistence creates a different requirement.
A chatbot can say, “I’m not sure.”
A persistent agent needs more than the sentence.
It needs a durable state representing that uncertainty.
The system should be able to say, in effect:
I attempted the action.
I observed some evidence.
The evidence is not strong enough to verify the result.
Do not treat this as complete yet.
That state may need to survive for minutes, hours, or days.
Maybe the right next action is to recheck later.
Maybe another source of evidence is needed.
Maybe the system should ask a human.
Maybe a dependent task should remain blocked.
Maybe the evidence will never become strong enough, and the task should eventually be marked unresolved rather than completed.
This is one of the places where persistence stops being “long memory” and starts becoming architecture.
The uncertainty itself has to persist.
Why this matters more in multi-agent systems
The problem becomes worse when more than one agent is involved.
Imagine Agent A performs an action.
Agent B later reads the project state.
Agent C uses that state to make a planning decision.
If Agent A wrote “done” when the real state was uncertain, Agents B and C no longer see the original ambiguity.
They only see the conclusion.
This is a subtle form of information loss.
The system becomes more confident as information moves through it, even though no new evidence was added.
That is almost the opposite of what we want.
Shared state is useful because agents do not need to repeat every observation from scratch.
But shared state is only useful if it preserves the quality of the evidence, not just the final label.
A persistent multi-agent system needs to carry not only what it believes, but how strongly it is justified in believing it.
I am not trying to build a formal epistemology engine into AdamI.
But I do think the architecture needs enough structure to avoid turning uncertainty into certainty just because time passed.
Wrong memory is worse than missing memory
Memory usually sounds like an advantage.
More memory means more context.
More continuity.
Less repetition.
But persistent memory also gives mistakes somewhere to live.
If the system stores a wrong conclusion as verified fact, future behavior may become more consistent and more wrong at the same time.
That is why memory and verification are tightly connected.
Before a state becomes durable, the system should care about where it came from.
Was it directly observed?
Was it inferred?
Was it reported by another agent?
Was it independently verified?
Is the evidence stale?
Is there disagreement between sources?
This does not require perfect certainty.
Perfect certainty is probably not available for many real tasks anyway.
The goal is simpler:
do not pretend that weak evidence is strong evidence.
Sometimes the correct behavior is to remain unresolved
This is uncomfortable because agents are usually optimized to finish things.
Users ask for outcomes.
Benchmarks reward completion.
Task systems like clean status transitions.
There is pressure everywhere to turn uncertainty into an answer.
But a persistent system may need a different instinct.
Sometimes the correct action is not to decide.
Sometimes the correct state is:
still uncertain.
That does not mean the system is stuck.
It may continue gathering evidence.
It may schedule another check.
It may ask for confirmation.
It may restrict further action until the ambiguity is resolved.
In some cases, uncertainty should reduce authority.
If the system cannot verify whether a sensitive action succeeded, it probably should not immediately perform three more dependent actions as if the result were certain.
This connects directly to something I have been thinking about a lot lately:
capability should scale, but authority should be earned.
Evidence should work the same way.
Confidence should be earned too.
What AdamI has today
AdamI already has pieces that make this question unavoidable.
There is persistent task state.
There are background processes.
There are memory mechanisms.
There are verification and observability paths.
There is a Guardian layer intended to constrain what the system can do.
There are multiple model roles and a hybrid routing architecture.
But I would not claim that AdamI has solved uncertainty.
It has not.
The current system can represent incomplete work and can preserve state across model calls, but the deeper question is still open:
how much evidence is enough before a persistent system is allowed to commit a belief into durable state?
That gets harder when the world changes between checks.
It gets harder when different tools disagree.
It gets harder when one agent is verifying another.
And it gets much harder when the system eventually starts generating more of its own tasks.
The next thing I want to test
I want to make uncertainty more explicit in AdamI’s task and memory flow.
Not as a disclaimer in generated text.
As a state that affects behavior.
If something is uncertain, that should change what can happen next.
Maybe the system rechecks before continuing.
Maybe downstream tasks remain blocked.
Maybe evidence expires.
Maybe human confirmation becomes necessary.
Maybe a later observation resolves the state automatically.
The important part is that uncertainty should not disappear just because the current model call ended.
If the evidence is incomplete, uncertainty should persist longer than the model call.
That feels like a small rule.
But I suspect it is one of the rules that separates a system that merely looks persistent from one that can actually live with the consequences of its own past.
A persistent agent should be able to remain uncertain.
Not forever.
Just until reality gives it enough reason not to be.