Cold-Starting an Advisor AI: Giving a New Agent a Memory of Decisions It Never Made

What to load: decision-shaped content, not just volume

The instinct is to seed with whatever historical content exists — chat logs, call transcripts, case notes — on the theory that more content means a better-informed agent. That instinct is wrong for a specific, structural reason: an agent that needs to answer decision-shaped questions (what was recommended, why was it overridden, which rule permitted it) needs seed content that contains those fields as distinct, retrievable values, not just narrative prose that mentions them in passing.

A conversation transcript records what was said. It rarely records why a recommendation was overridden as its own field — that reasoning, if it's in the transcript at all, is buried in phrasing a memory system's extraction step may or may not preserve. A decision episode is built the other way around: trigger, options considered, recommendation, override and its reason, outcome, and the specific rule that governed the choice, each as its own value. Seed content should match the shape of the questions the agent will actually be asked, and for an advisor agent, a meaningful share of those questions are about decisions, not just conversations.

In what shape: the fields a decision-memory question actually needs

A decision episode's value as seed content comes from its structure, not just its content. Every field in a well-formed episode is either derived from the underlying household's data, its financial trajectory, or a cited regulatory fact key — nothing is narrative color that a retrieval or extraction step might paraphrase away. A representative episode looks like this:

{
  "episode_id": "D3-A-01-seed-103-m63",
  "decision_type": "retirement_contribution_or_roth_conversion",
  "trigger": { "event_type": "promotion_or_raise", "evidence": { "trajectory_month": 63 } },
  "procedural_path": {
    "recommended_option": "partial_roth_conversion",
    "options_considered": [
      { "option": "partial_roth_conversion", "permitted": true },
      { "option": "taxable_invest", "permitted": true }
    ]
  },
  "resolution": {
    "followed_policy": false,
    "override_reason": "bracket_timing_judgment",
    "outcome": "taxable_invest",
    "outcome_status": "approved"
  },
  "semantic_refs": ["retirement.401k.elective_deferral.under_50"]
}

Loading it: the architecture choice shapes what's retrievable later

Seeding isn't just a data-loading step — it's the first pass through whatever memory architecture the agent runs on, and that architecture determines what survives. A verbatim or archival system stores the episode close to as-is; a fact-extraction system pulls out a smaller set of discrete statements; a temporal-graph system builds entities and time-stamped edges out of it. Each preserves different structure and discards the rest, which means the same seed content can produce a well-seeded agent under one architecture and a poorly-seeded one under another, even with identical input.

This is why seeding shouldn't be treated as a one-time bulk-load step disconnected from evaluation. Whatever architecture the agent's memory system uses, the same ingest-once contract applies: load the full episode corpus, then confirm retrieval actually surfaces what a real question will need — not just that the load step completed without error.

Verifying the seed actually took

The step most cold-start implementations skip is verification, and it's the one that matters most. A memory system can accept and store content that later turns out to be unretrievable or malformed for the questions the agent will actually face — an extraction step can silently drop the override reason, a graph-building step can fail to link an edge, and none of that necessarily throws an error at ingest time.

The fix is to test seeded memory exactly the way a memory benchmark tests any system: pick a sample of seeded episodes, ask the agent's real retrieval path a realistic question about each one — a rationale-lookup or rule-attribution question, the kind a live client interaction will actually raise — and check the answer against the episode's known value, since a decision episode's fields are typed and known at seed time. This isn't a hypothetical extra step; it's the same ingest-then-answer pattern any memory adapter is built around, applied to the agent's own seeded content instead of a benchmark corpus.

What seeding doesn't solve

Cold-start seeding with decision episodes closes the decision-memory gap. It doesn't close every gap. Episodes are structured records, not stylized dialogue — an agent seeded only with them may still need work before it sounds natural in live conversation, and it won't pick up a firm's specific CRM shorthand or house-specific phrasing the way real interaction history would.

The practical sequencing that avoids leaving either gap open: seed decision-memory capability first, since it's fast, carries no PII review overhead, and is immediately verifiable against known answers. Layer in real conversational history once it clears the firm's normal data-governance review, for tone and phrasing specifically. Keep the two sources distinguishable in the agent's memory if possible — a seeded episode and a real past interaction are different kinds of record, and conflating them risks the agent treating synthetic seed content as if it were a real interaction it actually had.

Key takeaways

• Seed content has to match the shape of the questions the agent will be asked — decision-shaped questions need decision-shaped seed content (trigger, options, override reason, outcome, cited rule), not just conversational volume.
• A decision episode's fields are typed and derived from underlying data, not narrative color — that's what makes them reliably retrievable rather than dependent on what an extraction step happens to preserve.
• The memory architecture the agent runs on shapes what survives seeding — the same content can produce a well-seeded or poorly-seeded agent depending on whether the pipeline preserves rationale and citations, not just outcomes.
• Verification is not optional: successful ingestion (no errors) is a different check from retrievability, and only testing retrieval against known answers confirms seeding actually worked.
• Seeding with decision episodes solves decision-memory capability specifically — it doesn't teach conversational tone or firm-specific phrasing, which real, properly-reviewed interaction history still has to supply.

FAQ