Glossary · Per-Type Memory Decay (Gravitas)

Per-Type Memory Decay (Gravitas).

Forgetting on a schedule that matches reality.

Direct answer

Different knowledge rots at different speeds, so one TTL fits none: decisions age slowly, approaches die fast. Per-type exponential decay (outcome × decay × links × confidence) scores each node by its kind's half-life, decisions ≈347 days, patterns 180, bugfixes 60, approaches 30. Decay never deletes: it demotes, letting fresh corroboration rescue and silence bury.

In Anvaya

How We Implement It.

01Per-Type Memory Decay (Gravitas)Anvaya's Gravitas service implements the λ table (Decision .002 → Approach .030) with session-end salience and access-based strengthening.

Questions

Asked About Per-Type Memory Decay (Gravitas).

Q

Why not one TTL for everything?

A 30-day TTL murders architecture decisions; a 1-year TTL preserves dead tactics. Type-matched half-lives mirror how code knowledge actually ages.

Q

Does accessing a memory refresh it?

Yes, frequently accessed nodes strengthen (Ebbinghaus-style), stale untouched ones auto-evict. Use is a vote.

Q

Is decayed data gone?

No, demoted from live indexes, preserved in version chains and temporal logs for audit and resurrection.

Run Agents That Fit On Your Laptop.

25.6 MB median RSS. 25 agents ran in parallel on a Core 2 Duo with 4 GB RAM. Hundreds on your machine. Zero cloud required on the Ollama path.

Requires Rust/cargo to build from source. Linux and macOS today, Windows not yet supported. Pre-1.0, public beta. Pricing TBD.