Engrams

An engram is a single piece of learned knowledge: a correction, preference, convention, or decision the agent should remember. Engrams are typed, scoped, and have an activation level that rises with use and decays with neglect.

The minimum viable engram

id:        ENG-2026-0525-001       # auto-generated
status:    active                  # active | dormant | retired | candidate
type:      procedural              # behavioral | terminological | procedural | architectural
scope:     project:my-app          # who can see this engram
statement: "When deploying, run migrations before rolling pods."

Five fields. Everything else is optional. Full schema: Engram schema reference.

The four types

Type	What it is	Example
behavioral	How the agent should act	”Stop summarising what you just did at the end of every response.”
terminological	Definitions and naming	”In this repo, ‘tenant’ means the customer org, not the user.”
procedural	Steps and recipes	”Bumping a release: edit CHANGELOG, run `./scripts/release.sh`, then tweet.”
architectural	Structural facts	”The chief-of-staff service consumes `agent_emit` events from six call sites.”

Types matter because they’re handled differently at injection. Behavioral engrams are usually pinned, terminological ones are loaded eagerly when the term appears, procedural ones fire when a matching task is detected, architectural ones are loaded on-demand by domain.

Lifecycle

candidate  →  active  →  dormant  →  retired

candidate — proposed but not yet promoted. Created by extractors that aren’t sure.
active — in use, eligible for injection.
dormant — low activation. Kept but not injected by default. Returns to active when relevant.
retired — superseded or wrong. History preserved; never injected.

Status changes are tracked, never deleted. You can ask plur_history ENG-... to see every transition.

Activation

Every engram has an activation level. Three forces move it:

Time decay — modelled on ACT-R; activation drops on a power-law curve when an engram isn’t accessed.
Strengthening — every recall, injection, and positive feedback nudges activation up.
Penalty — negative feedback and superseding moves drop activation faster.

Stale knowledge fades naturally — you don’t have to clean up engrams that turned out wrong. They simply stop surfacing. See Activation & decay.

Polarity

PLUR auto-classifies engrams as directive (“do X”) or constraint (“don’t do Y”). At injection time these are loaded separately so the agent can’t confuse a rule with an example. Polarity is inferred from the statement; you can override with polarity: directive | constraint.

Commitment

When you save an engram, you can mark how firmly you’ve committed to it:

exploring — trying it out, easy to drop
leaning — provisional preference (default)
decided — committed for the foreseeable future
locked — meta-rule. Pinned to context regardless of relevance.

Locked engrams bypass the relevance gate at injection. Use sparingly — they’re for safety conventions and operating principles, not regular knowledge.

The best engrams read as advice to your future self. Concrete, actionable, and tied to a reason.

Where engrams live

By default, in ~/.plur/engrams.yaml (or sharded by scope across ~/.plur/engrams/). Plain YAML, human-readable. Diff-friendly. You can grep them. You can commit them to git. They are the source of truth — every index PLUR builds is derived.

For Enterprise installs, engrams live in Postgres with the same logical model and JSON-serialisable schema — see Enterprise architecture.

Next: Episodes →