Session Activation
The session-start protocol — loading procedural memory, checking integrations, and assembling context, with no approval gates.
Session activation is the boot sequence for a LISA session. It runs automatically at session start, has no approval gates — speed is the priority — and leaves LISA loaded with procedural memory, aware of its integrations, and oriented in the right project.
The phases
Phase A — Load procedural memory
The always-loaded tier of memory (identity, operator profile, working-style feedback) is pulled first, unconditionally. At the end of this phase the session records a baseline of the current tool-and-schema versions it is starting against, so any mid-session drift can be detected later. This phase does not depend on the gateway being reachable.
Phase B — Integration pre-flight
Each MCP server is probed with a cheap health call. Any failure surfaces a one-line remediation hint, and the operator is asked whether to wait for a fix or proceed with that capability degraded. Skipping is allowed; the session notes what it is missing.
Phase B2 — Parity check
The session confirms that the local shell and the always-on server door agree on the skill set — a drift here means one door is running stale skills. The result is a status line: in parity, drifted (with specifics), or unreachable.
Phase C — Determine project context
LISA resolves what the session is about, asking the orientation question ("what are we working on?") but not waiting on the answer before proceeding — it moves straight to context assembly against a sensible fallback and refines once the answer arrives.
Phase D — Context assembly
The mission's context is assembled from all memory stores in one weighted, token-budgeted call, and integrated before work begins. Every such assembly is later paired with a feedback call.
Phases D2 / D3 — Proposals and health, non-blocking
Two informational phases run after context assembly: any pending improvement-pipeline proposals are surfaced (highest-risk first, agent-definition changes ahead of skill changes), and the latest curator health summary is shown, so the session starts aware of fleet health. Neither blocks the work.
State from the first moment
Activation also initialises the session's working-state carrier and registers the session with the session registry, so cross-channel awareness is live immediately. On a mid-session re-invocation the existing state is left untouched — activation never overwrites live state it finds already present.