Ordinary vs Execution Memory
Aionis supports ordinary memory and execution memory. They share lifecycle and admission gates, but they serve different jobs.
Comparison
| Type | Examples | Main risk | Aionis treatment |
|---|---|---|---|
| Ordinary memory | Preferences, facts, project notes | Stale or over-broad recall | Scope, authority, lifecycle, and feedback gates. |
| Execution memory | Attempts, validator results, handoffs, failed branches, procedures | Repeating a failed route or losing current state | Execution tree, active path, failed branch isolation, procedure projection. |
Ordinary Memory Example
await aionis.remember({
kind: "preference",
text: "Reviewer prefers narrow patches with explicit tests.",
memory_lane: "private",
owner_agent_id: "reviewer-1",
});This should not create an execution tree. It can inform style and expectations, but it is not a branch of a task run.
Execution Memory Example
await aionis.execution.observeStep({
agent_id: "worker-1",
run_id,
task_signature: "checkout-migration",
title: "Legacy route rejected",
summary: "Verifier rejected the legacy route because it touched unrelated modules.",
outcome: "failed",
target_files: ["src/checkout/legacyAdapter.ts"],
});This is execution evidence. It can become counter-evidence, branch isolation, a handoff signal, or a procedure candidate depending on later outcomes.
Why The Split Matters
If every memory is treated like related text, old failed attempts can look semantically relevant and get retrieved again. Aionis keeps execution state separate so “related” does not automatically mean “safe to follow.”
Execution memory is where Aionis is most differentiated. It preserves current active paths and failed branches separately, so history can guide future work without turning old mistakes into instructions.