Lex

Your agent can read the code. Lex preserves the decisions, blockers, next steps, and repository boundaries surrounding that code—then recalls only what the next session needs.

Local-first. Inspectable. No transcript dump.

See the core loop · Should I use Lex? · Five-minute pilot · Agent evaluation · Documentation

The problem Lex solves

A coding agent can inspect the repository in front of it. What it cannot reliably recover is the work surrounding that code:

• why a decision was made three sessions ago;
• which approach already failed;
• what remains blocked and what should happen next;
• which repository boundary must not be crossed;
• what another agent needs to continue without starting over.

Lex preserves that continuity as deliberate, high-signal Frames.

A Frame is a deliberate handoff, not continuous surveillance. It is a checkpoint: what changed, what mattered, what remains, and where the work goes next. Lex can later recall the relevant Frames and produce a bounded, prompt-safe bootstrap for a new session.

Work happens → Lex remembers what mattered → the next session continues

Start with remember, recall, and context. SQLite is the local default. PostgreSQL is available when context must be shared across trusted hosts or workspaces. Everything else is optional.

Remember → recall → continue

lex remember \
  --summary "Kept authentication token validation in API middleware" \
  --next "Add the service grant and rerun tests" \
  --modules unscoped \
  --blockers "Missing PermissionService grant"

lex recall "authentication"

lex context "authentication" --max-tokens 500

That is the core loop:

• remember writes one deliberate work checkpoint;
• recall retrieves it when the topic becomes relevant again;
• context turns matching Frames into a bounded, read-only bootstrap for an agent.

What the next session gets

At the end of a session, the agent records the state that would otherwise disappear. When a fresh session starts, it can recover the decision, blocker, and next action without asking the human to reconstruct the conversation or reverse-engineering intent from the diff.

Decision: token validation belongs in API middleware
Blocker: the service grant is still missing
Next: add the grant and rerun the authentication tests

The value is not that Lex stored a record. The value is that the next session can continue.

Should I use Lex?

Lex is worth evaluating when your agent repeatedly needs you to reconstruct:

• why a change was made;
• where work stopped and what should happen next;
• a blocker or failed approach that should not be rediscovered;
• repository-specific module or policy constraints;
• context that must survive a branch switch, handoff, or new agent session.

Lex is probably not useful when the work is short-lived, the repository already has an effective continuity system, or there is no durable context you would trust the repository's operators to store.

Ask your agent

The evaluation is intentionally read-only. Paste this into an agent that can inspect your repository: