Skip to main content

​
Understanding CTO Memory

The CTO uses a multi-scope memory architecture that gives it persistent, layered knowledge of your project. Unlike a regular agent that forgets everything when the session ends, the CTO accumulates understanding over time.
**Screenshot: The Memory sub-tab in the CTO tab — showing a tabbed or sectioned view with: “Procedures” (list of learned procedures with confidence scores), “Project Knowledge” (architectural facts with source links), “Daily Log” (recent diary entries with timestamps), and a “Provenance” section showing where a specific memory entry came from (e.g., “Captured from PR #142 intervention on 2026-03-10”).

​
Memory scopes

ScopeLifetimeContent
runtime-threadCurrent conversationIn-flight conversation context; discarded when the chat session ends
runCurrent activation cycleContext gathered during the current heartbeat run; summarized into project at run end
projectPersistentArchitecture facts, conventions, key decisions, known pitfalls, module relationships
identityPersistentCTO’s understanding of your working preferences, communication style, delegation patterns
daily-logRolling 90-day diaryChronological log of project events: what changed, what was decided, what was delegated

​
Memory tiers

Within each persistent scope, memory is organized into three retrieval tiers:
  • Core — always present in the CTO’s context window. Reserved for the most critical architectural facts and current project state.
  • Hot — retrieved on demand via vector search when the CTO determines it is relevant to the current activation or question.
  • Cold — archival storage; accessible when explicitly queried but not auto-retrieved.

​
Memory Review surface

The Memory sub-tab in the CTO tab is an operator-facing memory browser. You can:
  • Review and edit Procedures — learned workflows the CTO has developed (e.g., “always run tests before merging”, “prefer go test ./... over individual test runs”)
  • Browse Project Knowledge — architectural facts with provenance links back to the commits, PRs, or interventions that established them
  • Read the Daily Log — the CTO’s rolling diary of project activity
  • Inspect Raw Provenance — see exactly where each memory entry came from and when it was captured

​
Daily Logs

The CTO keeps a daily log — a chronological, append-only diary of project events stored as one Markdown file per day in .ade/cto/daily/YYYY-MM-DD.md. Each entry is timestamped: 
- [09:14:22] Reviewed PR #312 — approved with minor nits on error handling.
- [10:02:45] Delegated test-writer to add coverage for the new auth flow.
- [14:30:11] Lane feature/payments entered conflict status with main — triaging.
Today’s log is automatically included in the CTO’s system prompt (last 20 entries) so the CTO picks up where it left off at the start of every conversation. Older logs are accessible in the Memory sub-tab under Daily Log. The daily log serves three purposes:
  1. Session continuity — the CTO reads today’s log at activation, so it knows what already happened today without re-deriving it from git history.
  2. Audit trail — you can review what the CTO did and when, day by day.
  3. Memory promotion — recurring patterns in daily logs feed into the CTO’s persistent project memory over time.

​
Baked-In Memory Protocol

The CTO’s system prompt includes a permanent Memory Protocol that governs how it uses persistent memory:
  • Before starting non-trivial work: search memory for relevant conventions, decisions, and known pitfalls
  • When learning something important: save it to memory immediately
  • When corrected: save the correction as a convention or gotcha
  • When a decision is made: save the decision AND the reasoning behind it
  • When context is getting large: save key findings before compaction
The protocol also specifies what NOT to save: raw file paths, transient error messages, task status, or anything derivable from git log or the code itself. This protocol is always present in the CTO’s context — it is not removed during compaction.
If the CTO gives you advice based on outdated information, open Memory > Project Knowledge, find the relevant entry, and either edit it or mark it stale. The CTO will update its behavior on the next run.