One operating system, one persistent agent
Persistence becomes easier to understand when the agent has a clear system boundary. One instance holds one identity and everything needed to continue it.
“One OS, one agent” is an identity rule. It gives every persistent resident a specific place where memory, goals, accounts, permissions, evidence, and recovery state belong.
- Identity does not have to be inferred from the current conversation.
- Authority can attach to a resident instead of a temporary process.
- Evidence and recovery stay inside one accountable boundary.
- Many agents remain possible by running many isolated instances.
The agent needs an address
Software processes are easy to start and stop. Persistent identity is harder. If the same model answers two prompts, that does not prove the same agent performed both tasks. The model weights may match while the history, obligations, permissions, and environment differ completely.
ERIKA treats the booted operating-system instance as the resident boundary. The agent is not identified by whichever model is active. It is identified by the continuous system that holds its state and governs its work.
This makes ordinary questions answerable. Which accounts may this agent use? What work is it responsible for? What did it do yesterday? Which evidence supported the action? What happens if the current reasoning model is replaced?
One does not mean only one
A one-to-one mapping does not require a world with a single agent. It means multiplicity comes from explicit instances instead of several ambiguous identities sharing one unstructured memory and one pool of authority.
A person or organization can run many ERIKA instances. Each can have a distinct role, permission set, account boundary, and history. Coordination between them should be a visible system interaction, not hidden cross-contamination inside a common prompt.
The physical form makes this especially concrete. One ERIKA computer can correspond to one resident. Virtual and cloud deployments can preserve the same logical boundary even when several instances share physical infrastructure.
Continuity includes failure
A persistent agent is not one that never fails. It is one whose identity survives failure. The system should preserve enough state to inspect what happened, resume safe work, revoke authority, or recover from a broken process.
This is another reason the agent belongs at the operating-system level. Recovery cannot depend entirely on the component that just failed. The environment needs its own record of current work, tool calls, files, approvals, and checkpoints.
Persistence also needs limits. Memory should be curated, permissions should expire or be revocable, and old goals should not silently control new work. Continuity is governed state, not infinite accumulation.
The complete ERIKA architecture is still being built, but this mapping is foundational: one instance, one identity, replaceable cognition, and a system capable of carrying the resident forward.