Four ownership scopes, five processing layers, one database
Everything in the architecture lives in one on-device SQLite file. There is no separate memory server, and nothing here requires a network call. The five processing layers are not five databases, and they are not quite the same thing as the ownership scopes a row of memory can carry. Three layers correspond directly to an ownership scope; the other two, the control plane and recall, are how that ownership gets enforced and read back, not additional owners.
Global and user-identity memory is the first ownership scope: facts about the person, not the project—preferred language, coding conventions, standing instructions the user gives repeatedly. This scope attaches to no particular agent and no particular project, so it follows the user everywhere.
Per-project memory is the second scope, tied to whichever folder the agent is currently working in. It draws on three sources most engineering projects already have: a running summary of the project's goals and past decisions (the project's soul), a generated map of the codebase's structure, and a sitemap of project documentation. These are injected together, so an agent opening a project for the first time in a session does not need the user to re-explain what the project is.
Per-agent memory and experience is where the remaining two scopes live, and where most of the complexity sits, because the agent is not always one thing. An agent running alone owns its memory under an agent scope outright. An agent that is one role inside a team is different: a fourth scope, shared team memory, exists for facts the whole team should see, while the team's coordinator and its specialists still learn under the agent scope, attributed to different agents by what kind of thing was learned. The owner of any row in the agent scope is a tuple—agent identifier, package hash, project, and environment—not just an agent name, so the same agent installed twice in two different contexts does not share memory it should not share.
What actually happens on a turn
An assistant's reply on a turn passes through curation, which classifies it into curatable events; a semantic admission check drops near-duplicates; anything that survives is inserted with a locally computed embedding. Separately, if the reply represents an operational outcome worth remembering as experience rather than a fact, it is intaken into the experience table, and a promotion receipt records why.
On a later turn working a similar task, recall does not read the whole memory table. It ranks by a hybrid of lexical overlap and cosine similarity, pulls experience candidates ranked by their relation-graph connections, and folds in whatever the user's shared hub says operationally for the session, alongside the project's soul and code map. All four sources are joined into the same context block before it becomes a system prompt. The recall gate is simple by design: a candidate needs either a nonzero lexical match or to clear a similarity floor, which keeps the system from injecting confident-sounding nonsense purely because a vector happened to be nearby.
The same task, three kinds of agent
An agent in Agentlas can be local, saved privately in Agent Cloud, or used from the public Hub. That distinction matters less than it might seem: all three curate into the exact same device-local store, using the same curation path. What differs is only where experience is owned and where a chip loadout comes from.
A local agent's memory and experience are both fully on-device. An Agent Cloud package stays owner-private unless its owner explicitly publishes a separate public copy. Experience can be shared as a free public chip attached to a compatible agent release. A Hub agent runs inside a read-only boundary and carries a chip loadout injected at runtime from the Hub's ontology projection, bound to the exact public release.
Where the embedding and the graph actually intervene
It is easy to draw a memory architecture that has a nice-looking graph in it and never actually reads from that graph. The honest version: the local embedding model (potion-multilingual-128M, quantized to 256-dimensional int8 vectors, chosen so multilingual text including Korean embeds without calling out to any external model) feeds the hybrid ranking function that recall actually calls.
The relation graph, built from the same rows, feeds two live intervention points: it re-ranks what gets recalled into a prompt, and it biases the auto-router's choice of which agent should receive a new task, through an experience-priors map. Both are real runtime hooks, not a decorative visualization sitting beside the real system.
Team identity and memory ownership
Each local team member has a first-class agent identity, identified by its org-node slug. Additive, idempotent materialization gives member-scoped experience a durable owner without rewriting prior history.
The curator routes learning by kind: decisions and conflicts go to the coordinating agent, shared facts go to team memory, and domain-specific skill goes to the member who did the work. The self-evolution loop can propose, apply and roll back changes from repeated failure patterns, promoted memories or repeated steering. Trust tiers determine when a proposal can apply with undo and when it needs explicit approval. An import path can convert prior Markdown memory idempotently with secrets redacted.
Optional conversational relations
When conversational relation extraction is enabled, entities, mentions and typed relations can be recorded for a conversational memory as it is written, with temporal attribution.
This path is disabled by default behind an explicit environment setting. With it disabled, recall uses the existing lexical and vector path. Optional relation extraction does not change the ownership and permission boundaries of stored learning.
Local recall
Recall ranks eligible memories using lexical overlap and locally computed vectors. It selects a bounded set of relevant records for the current task.
Selection depends on the available records, their scope and the current query. The host can perform this ranking without asking a conversational model to judge each candidate.
- Read only memories eligible for the current actor and project.
- Rank relevant records with the configured local recall path.
- Keep source identity and unresolved evidence visible in the selected context.
The reader matters as much as the memory
Retrieval selects material for the next model turn. The connected model interprets that material and produces an answer.
Finding a relevant memory does not establish that an answer is correct. Review the selected sources and the generated conclusion together.
Additional context can introduce competing details. Use bounded context and keep temporal and source attribution visible when the question depends on dates or changing facts.
Local memory and connected models
Storage, recall and answer generation are separate parts of the workflow. Their boundaries help the owner understand where context comes from and which component uses it.
- Storage preserves scoped records and their origin.
- Recall selects eligible context for the current request.
- The connected model uses that context within its execution permissions.
Retrieval and answer generation
Local retrieval can supply relevant context without a per-query conversational-model call. The subsequent answer remains a separate model output.
An owner can inspect the recalled sources and compare them with the answer before acting on it. A fluent answer does not replace the underlying evidence.
- Check whether the selected record answers the current question.
- Review dates, ownership and later corrections.
- Keep an unsupported conclusion unresolved.
What this architecture is actually for
Memory ownership lets preferences follow the person while keeping project decisions and individual agents' experience in their appropriate scopes.
A user's preferences should not live and die with one project, and one team member's experience should not silently become another member's assumed context.
The architecture makes stored learning reusable while keeping its source, scope and current status available for review.
