Memory & retrieval

“Memory” and “context” are not one thing. Chronos treats them as five distinct layers, each governed with the same pattern as connected tools: source of truth in the panel, a global → team → workspace → session cascade, per-session materialization, and audit.

The five layers

1. Governed context — your organization’s standards, skills, conventions and company prompts, managed in the enterprise panel. Materialized at session start into the agent’s managed layer — highest precedence, non-overridable, and never committed to your repository.
2. Repo context — the project’s own CLAUDE.md and docs/, versioned in git and owned by the team. Chronos respects it as-is; it does not govern it.
3. Session memory — the transcript, queued prompts and tool calls of a session, kept by Chronos. It lets you detach and return to a session, and it feeds the audit trail. It stays local.
4. Cross-session memory — curated learnings that survive a session, opt-in and explicitly approved (below).
5. Retrieved knowledge — documentation and standards fetched on demand through governed connections. The relevant bits are retrieved when needed, not stuffed into every prompt.

The principle: governed context is materialized at runtime and never committed; repo-specific context is committed; memory lives governed and auditable in Chronos, not scattered across git.

Cross-session memory: explicit approval

Useful lessons can be promoted to carry across sessions — but never silently. A learning is proposed, then reviewed and approved like code before it is kept; there is no automatic background memory. Approved memory respects team boundaries: knowledge never crosses between teams that shouldn’t share it, and every proposal, approval and use enters the audit trail.

The full-featured form of this layer is Techne — governed skills: distill a finished session into a reviewable SKILL.md, approve it in the panel, and it comes back down the signed cascade as a skill every session in scope can use and invoke.

On-demand skill retrieval (progressive disclosure)

Governed skill packs such as Kairos distinguish between always-relevant and situational skills:

• Always-relevant disciplines (for example Test-Driven Development or Verification Before Completion) are injected in full into every session’s managed context.
• Situational skills (for example Brainstorming or Systematic Debugging) are not. Instead, the session carries a compact skills index — each skill’s name and its “use when …” trigger — and the agent fetches the full body only when the situation arises.

Retrieval goes through the builtin Skills tool, served on the same local connection as every other governed tool. It exposes two operations: one to list the index and one to fetch a skill’s body by id. Every fetch is audited, so you can see exactly which method the agent pulled in and when.

This keeps the context window small without giving up governance: the skills stay signed, cascaded and centrally managed, and the agent pays the token cost of a skill only in the sessions that actually need it.

Context-window discipline

The same retrieve-don’t-stuff stance applies across the board: the agent’s native compaction runs normally, older turns are summarized into session memory, reference material arrives through connected tools when it’s relevant, and optimizers like Tempo shrink what enters the model’s input — while the audit always keeps the full record.