Lesson 8: Memory

Your email triage treats every email the same. It does not know that your VP’s emails are always urgent. It does not remember that last week you corrected it: emails from [email protected] should create tasks, not just archive.

This lesson adds memory. Your machine learns from patterns and corrections.

Remember and Recall

Two new step types:

remember save_pattern
  key: "sender:" + input.sender
  value: {typical_priority: classify.priority, last_seen: "now"}

recall check_sender
  query: "sender:" + input.sender

remember stores a value by key. recall retrieves it. Memory persists across runs. The next time the machine sees an email from the same sender, it can check what happened before.

The Learning Triage Machine

Here is the email triage with memory:

machine email_triage

achieves
  goal "Route emails using learned sender patterns"
    succeeds when "known urgent senders are fast-tracked"
    never "override a human correction"

accepts
  subject as text, is required
  sender as text, is required
  body as text

responds with
  routed_to as text
  used_memory as boolean

behaves
  recall check_sender
    query: "sender:" + input.sender

  decide use_memory
    when check_sender.results != null and check_sender.results.override != null
      {routed_to: check_sender.results.override, used_memory: true}
    otherwise
      run classify_and_route

  flows
    flow classify_and_route
      ask classify, using: "anthropic:claude-haiku-4"
        with task "Classify this email.\n\nFrom: ${input.sender}\nSubject: ${input.subject}\nBody: ${input.body}"
        returns
          priority as text, is required, choices: ["urgent", "today", "later", "ignore"]
          confidence as number, is required, range: 0.0..1.0
          reason as text

      remember save_pattern
        key: "sender:" + input.sender
        value: {typical_priority: classify.priority, confidence: classify.confidence}

      decide route
        when classify.confidence < 0.7
          {routed_to: "human_review", used_memory: false}
        when classify.priority == "urgent"
          {routed_to: "notify_team", used_memory: false}
        when classify.priority == "today"
          {routed_to: "create_task", used_memory: false}
        otherwise
          {routed_to: "archive", used_memory: false}

verifies
  test "uses a stored override without calling the AI"
    assuming check_sender {results: {override: "notify_team"}}
    given {subject: "Anything", sender: "[email protected]", body: "x"}
    expect {routed_to: "notify_team", used_memory: true}
  test "classifies and routes when there is no memory"
    assuming check_sender {results: null}
    assuming classify {priority: "urgent", confidence: 0.95, reason: "Outage"}
    assuming save_pattern {stored: true}
    given {subject: "URGENT: Server down", sender: "[email protected]", body: "Offline"}
    expect {routed_to: "notify_team", used_memory: false}

Note the third assuming in the second test. remember and recall reach outside the machine, exactly like an ask does, and a test is hermetic: it may not touch a real store. So every memory step on the path a test exercises needs its own assuming, or the run stops with SPEC_EFFECT_UNMOCKED. The first test never reaches save_pattern (the stored override short-circuits before the flow runs), so it does not need one.

What Changed

Before classification, check memory. The recall step looks up the sender. If there is a stored override (from a human correction), use it directly. Skip the AI entirely. Faster and free.

After classification, save the pattern. The remember step stores the sender’s typical priority. Over time, the machine builds a profile of every sender.

Human Corrections

When someone corrects the machine (“emails from [email protected] should always create tasks”), store the correction:

machine apply_correction

accepts
  sender as text, is required
  correct_routing as text, is required

responds with
  saved as boolean

behaves
  remember save_correction
    key: "sender:" + input.sender
    value: {override: input.correct_routing, corrected_by: "human", corrected_at: "now"}
  compute done
    {saved: true}

verifies
  test "stores the human correction"
    assuming save_correction {stored: true}
    given {sender: "[email protected]", correct_routing: "create_task"}
    expect {saved: true}

The next time an email from that sender arrives, the triage machine finds the override in memory and uses it. No AI call needed. The human’s judgment takes priority.

What Memory Looks Like

ask Koda: what does email_triage remember about [email protected]?

You see:

key: "sender:[email protected]"
value: {
  typical_priority: "urgent",
  confidence: 0.94,
  override: "notify_team",
  corrected_by: "human",
  corrected_at: "2026-04-01"
}

Memory is inspectable. You can see what the machine has learned, when, and from whom.

Memory is Governed

Like everything in mashin, memory operations are tracked:

• Every remember is recorded in the execution trace
• Every recall shows what was retrieved (or not found)
• Memory is scoped to the machine and tenant (your machine cannot read another machine’s memory)
• Corrections include who made them and when

No hidden state. No black box. If the machine starts routing emails differently, you can trace it back to a specific memory entry.

The Cost Impact

Memory saves money. When the machine recognizes a known sender and has an override, it skips the AI call entirely. For a 150-email inbox where 40% of senders repeat daily:

• Without memory: 150 AI calls/day ($0.05)
• With memory: ~90 AI calls + 60 memory lookups ($0.03 + ~$0)

Small savings per day. Significant at scale.

What Comes Next

Your machine now classifies, routes, acts, and learns. It is deployed and tested. But how do you understand what it does without reading the code? How do you estimate its cost before running it? How do you verify it meets governance requirements?

Next lesson: interpretation modes. Six ways to analyze any machine without changing it.

Next: Interpretation Modes →