Pi State Flow

Incremental scoped context/memory compiler for Pi.

State Flow maintains explicit state across requests and sessions. The agent incrementally compiles requirements, decisions, findings and source knowledge into durable memory rather than carrying every completed exchange into the next request.

Drawing on the explicit-state approach of SKILL.state, State Flow combines durable state with Pi's native conversation context. In this hybrid, state carries continuity between user runs; Pi's native context carries the working trajectory within a run. The conversation is not reset after each model response or tool call. Pi retains ownership of execution, session navigation and the full inspectable trace.

How it works

A user run starts with effective memory and a new request. The agent works through Pi's ordinary inference/tool loop, updates memory when useful information changes, and returns an ordinary answer. The next run receives the accepted state and compact recent transitions instead of the completed ordinary conversation history.

Current state + Request
          ↓
Pi's native tool loop
          ↓
Patched state + Answer
          ↓
Updated state

Within a run, the available request, intermediate responses, tool results and steering remain in context. A state patch updates memory without discarding that working trajectory. Persistent context-bearing messages from other extensions are preserved as well.

This reduces reliance on repeated model-generated summaries of an accumulating transcript. Retaining the current trajectory also allows prompt-cache reuse while the relevant prefix remains unchanged. Avoiding summary calls and repeated prompt processing can improve responsiveness; the result depends on the model, provider, workload and frequency of state changes, not a fixed latency guarantee.

Native compaction remains available for long runs. State Flow may also request a completed-history boundary without another model summary, retaining the complete latest accepted run. Neither mechanism deletes Pi's append-only session trace. See lifecycle behavior and performance evidence.

Installation and activation

Requires Pi 0.87.0+ and Node.js 22.19.0+. See SDK compatibility for tested stacks and verification limits.

From NPM:

pi install npm:@llblab/pi-state-flow

From Git:

pi install git:github.com/llblab/pi-state-flow

Enable active State Flow on the current branch:

/state-flow-start

Starting in an existing conversation retains its context for one complete bootstrap run so the agent can compile what matters.

• /state-flow-start: Enable active state updates and memory-based context projection.
• /state-flow-status: Inspect effective state, retained history and known recovery issues without scanning sources or changing state.
• /state-flow-stop: End active episode semantics without deleting memory; an interrupted run retains its frozen handoff and available trajectory.

Active mode is opt-in. Passive memory projection and the memory tools are enabled by default: existing state can be read or explicitly patched without an active episode or State Flow compaction. Stop returns to the configured passive behavior. autoStart can enable active mode for genuinely new sessions; resumed branches restore their own enablement. See configuration.

State model

Scopes and effective memory

Memory has three ownership scopes:

• global: Knowledge and preferences shared across projects.
• cwd: Knowledge shared by sessions in the same working directory.
• session: State belonging to the current session and its selected branch.

They compose recursively in global → CWD → session order. More-specific values override lower-scope values, while object fields merge. Removing a local value can reveal an inherited value again.

The agent receives the effective view of this composition, not three unrelated memory dumps. It can read that view or inspect an individual scope when ownership matters. effective is a computed view, not a fourth storage scope. Scope precedence does not elevate memory into system-level instructions.

Semantic planes

Every scope uses the same shape:

• intents: Active commitments to future action.
• contract: Requirements, decisions, constraints and interface commitments.
• working: Observations, results, uncertainties and current continuation.
• artifacts: Source-addressed descriptions and compiled knowledge.
• response: The latest complete answer, captured by the runtime.
• lazy: Supporting memory available through explicit reads, with its body omitted from baseline model context.

These planes organize ordinary JSON rather than imposing a project-specific schema. The model updates the semantic planes except response, which is runtime-owned. Memory remains fallible: storing an observation does not make it current or correct.

Incremental updates and history

patch_state updates one or more named scopes atomically. Unmentioned values remain unchanged; object patches merge recursively, and null deletes an object key rather than becoming stored data.

{
  "cwd": {
    "contract": { "verification": { "command": "npm test" } }
  },
  "session": {
    "intents": { "verify": { "action": "Run the checks before publishing" } },
    "working": { "checks": "Pending" }
  }
}

During an active episode, a material patch is an inference barrier: sibling tool calls are blocked, and the next inference sees the accepted effective state. Ordinary completion needs no finalization patch or additional State Flow reasoning loop.

read_state provides targeted current and historical access:

{ "paths": ["effective.contract", "cwd.working", "session.intents"] }

• working: Current effective working memory; unscoped paths are effective aliases.
• effective[1].working: Working memory at the preceding accepted transition boundary, when retained.
• cwd.patches[0]: The latest retained CWD semantic patch.
• effective.lazy.memory[0..3]: A bounded slice of a stored collection.

Historical materializations and scope patch histories use the configurable historyLimit, from 0 to 100, with a default of 7. Materialized offsets refer to accepted semantic transitions, not user messages or an independent counter for each scope. Requested history must still exist in the active lineage; increasing the limit cannot recreate discarded history. Older patches fold into the checkpoint without removing current values.

Array ranges, structural keys reads and path-intersected patch projections support progressive access without loading whole memory collections. See progressive memory and tool contracts.

Persistence, backups and continuity

The default store is ~/.pi/agent/state-flow/, independent of registered source files. Canonical checkpoint.json, patches.jsonl and meta.json files hold each scope's state, retained changes and metadata; session configuration and runtime identity are stored separately.

Git backups are optional. When the store is a configured Git repository, accepted active turns may create versioned backups of State Flow-owned files. Backup needs a Git commit identity; accepting and persisting state does not. A backup failure produces a warning without rejecting or rolling back accepted memory. Git history can be inspected separately, but it is not the authority for read_state or automatic restoration of expired semantic boundaries.

Resume and tree navigation restore the selected retained session boundary over current shared global/CWD memory. A new session gets its own session layer. Supported native forks copy selected session state into a new owner without changing the parent's private data. Expired, incomplete or contradictory boundaries fail closed rather than silently substituting newer state. See fork support and storage recovery.

Version 0.17 accepts only the current canonical storage contract and has no in-place predecessor converter. Preserve existing data and check the format boundary before changing versions or moving a store.

Operational boundaries

State Flow adds memory, not another agent controller. It does not introduce background reasoning, a scheduler, automatic reference hydration or rollback of external tool effects. State and the current trajectory are not size-capped; performance depends on how much useful information the agent retains.

The packaged state-flow-guide Skill covers concrete operations and recovery. state-flow-memory supports explicitly requested curation, for example: “Review and clean State Flow state” Normal handoffs reconcile touched memory; dedicated cleanup is not an automatic audit after each task.

Treat state, diagnostic logs and backups as private data. Revalidate consequential observations before acting, and verify a transfer's destination before deleting its source. Removing a value from current state does not erase older histories or remote copies.

Documentation and development

• Usage and recovery — Configuration, lifecycle, diagnostics and storage operations.
• Architecture — Semantic model, temporal boundaries, artifacts and integration contracts.
• SDK compatibility — Tested stacks and verification limits.
• Performance — Measurements, workload definitions and limits.
• Acceptance map — Properties tied to concrete tests.
• Documentation index — All maintained guides.

For development, run npm install and npm run validate. npm run benchmark is opt-in and separate from the normal suite; see benchmarks/README.md in a source checkout.

Project context: AGENTS.md, BACKLOG.md, CHANGELOG.md.