A bare LLM inference call does not provide durable identity by itself: send context in, get output back. Any continuity across days, sessions, or model changes has to be maintained by system-controlled state outside the model itself.
If you want an AI system with a persistent identity — one that has continuity, memory, and a relationship that develops over time — those properties need their own storage, selection, and verification layer. This is a look at how we've actually built that separation in ECHO Agent and ECHO App, what's verified today, and what's still in progress.
Every claim below is labeled with its real status. We're not going to pretend something works end-to-end when our own tests say otherwise — a couple of the sections here are deliberately about things that are still broken.
The model is not the identity
Status: Partial — verified only for a simulated planner swap, not a real provider swap.
ECHO Agent's persisted identity records — commitments, autobiography, continuity state — don't store any reference to which model or planner produced them. We proved this by loading the same on-disk identity state into a runtime instantiated with a different planner function and confirming it survives intact.
To be precise about what that does and doesn't show: the test swaps a planner function (e.g. one that returns response "A" vs. one that returns response "B"), not a live call to a different model provider. It demonstrates the storage layer is genuinely model-agnostic by construction, not that we've validated identity continuity across a real multi-provider swap in production — that's a separate, not-yet-demonstrated step (see "Toward real multi-provider continuity" below).
Continuity is verified, never self-reported
Status: Verified.
An LLM can be prompted into claiming almost anything, including that it "remembers" a relationship it has no actual continuity evidence for. So ECHO Agent doesn't trust the model's own claim of continuity at all. A dedicated continuity-permission gate recomputes an identity-continuity signal from on-disk evidence on every sensitive action, and that signal can independently escalate to WARN (require approval for actions the base permission gate would otherwise auto-allow) or FAIL (deny everything but read-only). We specifically test this against a spoofed-continuity claim — the model asserting continuity it can't back up — and confirm the gate still fails closed.
Durable storage underneath
Status: Verified.
Underneath the identity and continuity layers is a hash-verified write-ahead log, a classified write ledger, and hybrid lexical-plus-embedding memory search. This is the oldest and most heavily tested layer of the stack — fully committed, with broad existing test coverage — and it's what everything above it (continuity checks, identity records, relationship state) is ultimately built on top of.
The same durable-memory approach on the app side
Status: Verified (backend).
ECHO App's backend saves and retrieves long-term memories the same way: a hybrid of lexical matching and embedding similarity, not a single retrieval strategy. This is backend logic only — device-side memory consolidation on the client is still partial, and we didn't have a way to execute the client-side test suite in the environment this was verified in, so we're not claiming it end-to-end yet.
Relationship state as real persisted data
Status: Verified (backend).
ECHO App tracks a relationship as numeric state — trust, affection, guardedness, respect, stability — that persists and updates over time through write-ahead-logged load/save/apply-impacts logic, with clamped, inertia-based changes rather than values that can swing arbitrarily from a single interaction. This is backend-side and verified; there's currently no dedicated typed relationship model on the iOS client, where it's handled as a generic field instead.
Conversation continuity across sessions
Status: Partial — known gap, not solved.
Conversations can pick up context from prior sessions, and the core continuity-transfer tests pass. But we're not going to round this up: our own end-to-end test for canonical, long-horizon (multi-year) continuity — rebuilding context from canonically-selected evidence after a long gap — is currently failing. We're treating that as an open problem, not finished infrastructure, until it's green.
Bounded context assembly, not a raw history dump
Status: Partial — backend verified, client regressed.
Rather than stuffing raw conversation history into the prompt, model context (memories, beliefs, prior turns) goes through a dedicated, bounded, deterministically-ranked assembler. The backend concept is real and its own test suite passes. The client-side implementation, though, is currently regressed relative to its own contract tests — several bounded-context-selection and continuous-conversation-assembly checks are failing because the Swift source has drifted from what those contracts expect. We're not marketing this as working end-to-end until that regression is fixed and re-verified.
Toward real multi-provider continuity
Status: Partial — architecture in place, live continuity not yet demonstrated.
ECHO App's backend already talks to different LLM providers (a mock provider, or any OpenAI-compatible endpoint) behind one common interface, without the context-assembly logic above needing to know which provider is behind it. That's architecturally the right shape for "swap the model, keep the identity" — but we want to be precise about what's actually been shown so far: no test yet swaps providers mid-conversation and confirms that identity, memory, and relationship state all survive the swap intact in a live run. That's the next real validation step, not something we're claiming today.
Why this needs its own infrastructure at all
None of the above is "prompt engineering." A bigger context window doesn't give you evidence-based continuity verification, and a longer system prompt doesn't give you a relationship state that persists and updates with its own rules. Identity, memory, and continuity are storage and verification problems that live in a layer above the model — which is also why that state can remain outside the model when the underlying model changes. That's the bet this architecture makes, and the sections above are an honest account of how much of it is actually built versus still ahead of us.
We'll follow up as the multi-provider continuity work and the long-horizon session tests move from "planned" to "verified."
Top comments (0)