Skip to main content

Architecture foundations

The clean-slate Aegis design starts from one strong constraint: durable truth must have an explicit owner.

Older personal-AI designs let identity, work, memory, and learning overlap across prompt prose, manual tools, and semi-separate subsystems. The target architecture removes that overlap and simplifies the runtime around a small set of durable owners plus one derived runtime frame.

Core principles​

Runtime-owned persistence​

Durable updates are a runtime responsibility. The model may emit useful hints, tool requests, or structured deltas, but Aegis must still reconcile state from the observable turn, the execution outcome, and created artifacts.

One semantic concept, one durable owner​

The same fact should not be jointly owned by prompt text, a memory helper, a capability surface, and a secondary ledger. Each concept should have one durable home.

Prompt is projection, not storage​

Prompt layers are assembled from durable state. They may be cached, compressed, or reordered, but they are never the canonical storage model.

Continuity is derived, not a fifth store​

Continuity lives in a turn-scoped SessionFrame, not in a separate database. That keeps continuity rebuildable and prevents a second hidden source of truth.

Learning produces procedures, not a second memory system​

Learning starts from outcome evidence, distills reusable patterns, verifies them, and promotes procedures back into the runtime. It does not create another vague owner such as a free-floating growth or experience store.

Operator sovereignty​

Users should be able to inspect, patch, supersede, freeze, or delete durable state without editing hidden files or hoping the model remembers a ritual tool call.

The durable owners​

ProfileGraph​

Use ProfileGraph for:

  • durable human identity and collaboration preferences
  • relationship posture and trust calibration
  • stable boundaries and communication style

It does not own active work truth, evidence rows, or reusable procedures.

WorkGraph​

Use WorkGraph for:

  • goals, tasks, blockers, milestones, and deadlines
  • work dependencies and decision lineage
  • active focus state and next-step candidates

It is the spine of continuity. The runtime should organize the next move around active work, not generic text similarity.

EvidenceGraph​

Use EvidenceGraph for:

  • normalized events and memory records
  • artifacts, citations, provenance, and correction chains
  • summaries, recall reasons, and resume traces
  • rebuildable retrieval indexes and derived evidence summaries

It keeps evidence on one governed path instead of scattering truth across prompt summaries and tool-specific ledgers.

ProcedureLibrary​

Use ProcedureLibrary for:

  • verified reusable procedures
  • verification bundles and promotion history
  • optional skill packages generated from verified procedures

A procedure can help the runtime, but it does not become the owner of profile, work, or evidence truth.

CapabilityRegistry​

Use CapabilityRegistry for:

  • available tools and models
  • auth adapters and delivery surfaces
  • capability metadata and disclosure rules

This is a catalog of what the runtime can use, not a place where durable user or work truth should live.

Why this owner model matters​

This split makes the runtime easier to reason about:

  • writes have clear destinations
  • retrieval has one evidence path
  • continuity can be rebuilt on demand
  • learning stays governed instead of magical
  • operator inspect surfaces can explain what changed and why

Operator surfaces​

The target inspect model follows the same owner boundaries:

  • /profile for identity, relationship, and preference state
  • /activity for active and latent work state
  • /memory for evidence, recall reasons, reasoning availability tiers, and compression levels
  • /skills for procedure-backed skill packages and operator-visible procedural guidance
  • /audit for SessionFrame construction, prompt composition, and next-move explanations

Where to go next​

Once the durable owners are clear, the next question becomes: how does one turn actually get assembled? Continue with Continuity and SessionFrame.