Skip to content
Coro Docs

Manage memory

Tenant and repo overlays carry a memory/ tree that survives across jobs. Agents do not get the full corpus injected automatically anymore — procedures call read_memory when they need pitfalls, conventions, snippets, ADRs, or pending proposals.

File layout basics

Canonical layout (often starts from base templates shipped with @coro-ai/intelligence-base):

memory/
  MEMORY.md              # Curated index of links/descriptions
  known-pitfalls.md
  successful-patterns.md
  architecture-decisions.md
  snippets/              # Optional deep dives (plugin keys, etc.)

Merge rule: memory/**/*.md appends with provenance banners when layers stack (/guides/tenant-overlay/). That means memory is cumulative in the resolved view — new entries should be short, copy-pasteable recipes (see evaluator budgets in base agents/evaluator.md).

Capturing learnings during a run — add_insight

Every agent can call add_insight to record:

  • Toolchain friction (auth, sandbox quirks, provider bugs).
  • Spec ambiguity that blocked progress.
  • Workarounds that must not be rediscovered.

The Evaluator (or dedicated self-improvement agents) later grooms insights into propose_change memory updates — one bundled PR per layer per job when possible (/guides/review-proposals/).

Operational rules from base runtime instructions:

  • Record in the same turn the finding clicks—do not batch at end-of-phase.
  • Include copy-pasteable fixes in suggestion (command, env var, config snippet).
  • Choose a structured category (toolchain-pitfall, intelligence-gap, …) so dashboards and analytics stay filterable.

Grooming and deletion — memory-curator workflow

Memory only grows during normal jobs. The dedicated memory-curator workflow (workflows/memory-curator/workflow.md in the base layer) is the subtractive path:

  • Trigger via dashboard or CLI, e.g. coro job --workflow memory-curator --description "Trim known-pitfalls.md".
  • The curator agent merges duplicates, enforces evaluator length budgets, and ships exactly one consolidated propose_change per affected writable layer — still human-reviewed PRs (interactive_checkpoint: true).

Use curator runs when telemetry shows runaway tokens on read_memory, or evaluator insights flag duplication.

Operational checklist

ConcernAction
Verbose paragraphsRewrite into ≤8-line pitfalls / ≤10-line patterns before merging PRs
Sensitive dataStrip secrets — memory is replicated to every engineer’s runner
Cross-team vs per-repo loreTenant memory vs .coro/memory/ (/guides/repo-overlay/)