Architecture

Overview

Owner
  -> Native App / CLI / Channel / Agent Plugin
  -> Aegis Core
      -> Aegis Manager + provider planning
      -> Sessions / Tasks / Memory / Approvals
      -> Evidence / Tool Ledger / Provider Trace
      -> Talents Runtime
      -> Gateway / Channels
      -> Local Gateway / Native Nodes / Agent Runners
  -> Results / notifications / evidence / memory review

Responsibilities

Component	Owns	Does not own
Aegis Core	State, memory, tasks, queues, permissions, approvals, evidence, Gateway, agent runs	Directly operating local GUI or files
Aegis Manager	Natural-language understanding and provider-backed planning	Keyword matching or worker guessing
Aegis App	Owner-facing daily experience	Replacing Core
Local Gateway	Local worker execution, tools, terminal, files, browser, GUI, MCP	Global product state
Native Node	Desktop, mobile, device, and future robot capabilities	Bypassing Core
Talents	Installable capability contracts, settings, permissions, health	Hiding product behavior in prompts
Evidence	Run/tool/provider/approval/device proof	Replacing business state
Gateway	Channels, inbound/outbound delivery, recovery	Being the main product identity

Data Boundary

The default personal path uses local storage:

.aegis/profiles/<profile>/
  db/aegis.sqlite
  attachments/
  logs/
  run/
  evidence/
  cache/
  exports/
  archive/

Core keeps transactional state in SQLite. Large binary artifacts, logs, exports, evidence bundles, and cold archives stay as local files.

Planning Boundary

Natural language follows this route:

user message -> Aegis Manager -> provider planning -> structured tool/task calls -> executor -> evidence -> response

Workers and nodes execute explicit payloads. They do not read user prose and decide which tool to run.