Historical Actions and Learning

History is valuable when it records what was attempted, why it was authorized, what actually happened, and what remains uncertain. It becomes dangerous when an agent treats an old action as a timeless instruction.

The complete learning loop is implemented in TypeScript/JavaScript, Python, PHP, Go, and Rust. The snippets below focus on the history model; use the matching language implementation for authenticated calls, approval separation, observation, and reflection.

Store different kinds of history separately

Do not flatten these records into one summary that loses provenance, timing, approval, or uncertainty.

Example: history changes the next action

Assume a previous support decision predicted that a cache reset would resolve an account-sync issue within five minutes. The action was approved, but the observation showed a 40-minute recovery and a repeated failure. Reflection suggested checking queue backlog before recommending another reset.

For the next similar task, request:

const nextRun = await client.consequencePlan({
  scopeIds: [
    "product:account-sync",
    "history:account-sync-incidents",
    "policy:support-operations"
  ],
  task: "Compare safe recovery options for the current account-sync incident.",
  domain: "support_operations",
  contextPolicy: {
    includeMemory: true,
    includeKnowledge: true,
    includeContextCapsules: true,
    includePastDecisions: true,
    includeReflections: true
  },
  policy: {
    depth: 5,
    allowExecution: false,
    storeSafeArtifactsOnly: true
  }
});

The new run can use the prior decision and lesson to increase uncertainty, request queue-backlog evidence, penalize an unsupported repeat, or prefer a reversible diagnostic step. It must not conclude that every cache reset will fail.

Inspect the trace:

const historicalEvidence = {
  priorDecisionIds: nextRun.trace.priorDecisionIds,
  reflectionLessonIds: nextRun.trace.reflectionLessonIds,
  recalledMemoryIds: nextRun.trace.memoryIds,
  warnings: nextRun.warnings
};

An empty list is meaningful. The agent should report that it found no applicable historical evidence instead of inventing continuity.

Promote reflection deliberately

consequenceReflect creates a lesson candidate; it does not make that lesson universal policy. Review it first:

const lesson = reflected.reflectionLessons.at(-1);

if (!lesson) {
  throw new Error("No reflection lesson was produced");
}

if (lesson.memoryWritePolicy === "requires_review") {
  await queueForDomainReview(lesson);
}

if (lesson.memoryWritePolicy === "candidate" && reviewerApproved(lesson)) {
  await client.remember({
    scopeId: "history:account-sync-incidents",
    type: "tool_lesson",
    privacyClass: "tenant",
    text: lesson.summary,
    metadata: {
      sourceDecisionId: lesson.decisionId,
      sourceLessonId: lesson.lessonId,
      reviewStatus: "approved"
    }
  });
}

queueForDomainReview and reviewerApproved are application-owned controls. Never implement them as unconditional approvals.

Prevent historical bias

Use these controls when history influences new actions:

• Scope relevance: require overlap with the current subject, product, workflow, or user boundary.
• Time relevance: use since, until, validity windows, or retention limits when conditions change quickly.
• Source provenance: preserve links to the run, decision, observation, tool output, or reviewed human record.
• Current evidence: retrieve live operational or domain data before reusing an old recommendation.
• Counterfactuals: preserve rejected alternatives so the agent can see why they lost under the old conditions.
• Uncertainty: decrease confidence when observations diverged from predictions or data is missing.
• Diversity: avoid learning only from successful actions; include failures, near misses, and no-action outcomes.
• Human review: require it before sensitive lessons become active memory or shared policy.
• Deletion: tombstone the run and promoted memory when ownership, retention, consent, or correction requires it.

Correct or supersede a lesson

Do not overwrite history silently. Store the corrected reviewed record, tombstone the obsolete memory, invalidate affected context caches, and retain the audit event required by policy. Queue, archive, compaction, and retry paths must respect the tombstone.

When a team policy changes, update the policy knowledge base separately from the historical observation. “The old action complied with policy at the time” and “the action is allowed now” are different claims.

Test the learning loop

Prove the behavior with paired cases:

1. Create a bounded decision with a measurable prediction.
2. Record an observation that differs from that prediction.
3. Reflect and verify the delta, confidence adjustment, and write policy.
4. Start a new run with the same relevant scopes and history enabled.
5. Verify its trace contains the prior decision and reflection identifiers.
6. Confirm the new scenario requests the missing evidence or adjusts uncertainty.
7. Start an unrelated run and verify the lesson is not retrieved across scopes.
8. Tombstone the lifecycle data and verify queued work, retries, archives, and compaction cannot resurrect it.

What not to remember

• Raw chain-of-thought or private model reasoning
• Hidden prompts or model scratchpads
• Unreviewed model output presented as an observed fact
• Secrets, credentials, or full authorization tokens
• Unnecessary personal, clinical, financial, location, or customer data
• A recommendation without its conditions, evidence, confidence, and date
• A temporary exception promoted into permanent policy without approval