$ git clone https://github.com/yologdev/gasp

$ cp -r gasp/fixture my-agent && cd my-agent

$ : > state/events.jsonl # start with an empty log

$ git init && git add -A && git commit -m "genesis"

$ (cd ../gasp && cargo run -q -- ../my-agent) # all 7 checks pass

a conformant control loop — stateless over the committed log

take_lease()
state = fold(state/events.jsonl)        # reconstruct projection from the log
start_run(goal)                          # append goal / task / run events
while not run_done:
    decision = model.next(view(state))   # PURE: state in, decision out
    if decision.is_tool_call:
        result = run_tool(decision)      # the gate yields an `eval`
        append(events_from(result))
close_run():
    append(patch / decision)             # promote or revert per executor policy
    regenerate(journal, active_memory)
    commit(...) with Run-Id / Outcome trailer
release_lease()

writing in Rust?

One JSON object per line of state/events.jsonl: id, schema_version, ts_ms, actor, kind, payload, causation_id, correlation_id. No extra top-level fields, none missing. Physical line order is the authoritative total order — ts_ms is advisory.

{"id":"event_01","schema_version":1,"ts_ms":1739000000000,"actor":{"kind":"agent","id":"evolve"},
 "kind":"goal.created","payload":{"id":"goal_retry","title":"Make retry reliable", …},
 "causation_id":null,"correlation_id":"goal_retry"}

Every entity-creating domain event (goal.created, patch.proposed, eval.finished, …) is followed by exactly one state.ops_applied whose causation_id is the domain event and whose ops create the entity consistently. Only ops events fold into the graph; domain events are the audit layer. This is what keeps the two from silently diverging.

The JSONL append is the durability guarantee — flush each event immediately so a crash loses nothing. The commit is the shipping guarantee — one closing commit per run with a Run-Id / Goal / Outcome trailer. Committing per event destroys history; buffering until commit loses the tail on crash.

A single-writer lease (.agent/lease, local-only, gitignored) checked inside the store's append makes concurrent-writer corruption structurally impossible. Multiplayer and A/B use branches, not concurrent writes to one ref.

rung 1

rung 2

rung 3

WHAT YOU HAVE TODAYGASP HOME

Identity / persona / constraints filesidentity/

Learnings / notes-to-self, append-onlymemory/facts.jsonl → active_memory.md

Journals / narrative logsjournal/ — now a projection of run events

Skills / prompt-library foldersskills/ — versioned, one change per commit

Session archives / audit branchestranscripts/ — cold, prunable

"pass → commit, fail → revert" CI scriptsthe patch → eval → decision lifecycle

(usually nothing)state/events.jsonl — the core addition

$ cargo run -q -- fixture --fixture # verify the fixture (all 7 checks)

$ cargo run -q -- path/to/agent-repo # verify any emitted repo

the conformance claim

No — a name collision only. git restore restores files in a working tree (it discards local edits). gasp restore rebuilds a whole agent from its repo URL: clone, load identity and skills, fold the log, resume. Same English word, unrelated operations.

The current state is the replay's result — GASP just refuses to store it as an authority. A deterministic fold of the same lines yields the same agent on any machine; a stored "current state" would make one copy the truth and the log decoration. And the closed history in the folded graph is load-bearing, not archival: a patch rejected last week stops the agent from blindly proposing it again, every memory fact's derived_from stays checkable against the runs that taught it, and "why does the agent behave this way" is a walk over closed lineage — open goals alone can't answer it. Keep only the open items and you have a to-do list, not an agent with a past.

No — a snapshot is a cache for reaching now faster. Restore verifies its integrity record (a hash of the exact log prefix it folds through) and then folds only the tail; on any mismatch it falls back to a full fold. Deleting every snapshot loses nothing, ever. Viewing a past state is the separate feature: --at <event-id> deliberately stops the fold partway — the agent exactly as it was at that moment, for debugging, audit, or forking from before a bad decision.

Because each layer is thin on purpose, and none of the others holds the agent's ongoing life. identity/ is who the agent is — static, human-gated. memory/facts.jsonl is distilled lessons only — the admission criterion forbids it from mirroring history. The folded graph is the episodic layer: open goals, in-flight runs, the patch → eval → decision record. In human terms: identity is personality, skills are abilities, memory is semantic knowledge (“stoves are hot”), and the fold is episodic memory — what you're working on, what you tried yesterday, why you decided what you decided. A person with the first three but not the fourth wakes up every morning as a competent stranger to their own projects. Memory can stay small precisely because history has its own home.

Two different "too big"s. For the machine, a year of events is trivial — on the reference agent's cadence, roughly 36k lines / ~20 MB, folded in well under a second, and snapshots make restore O(tail) anyway. For the model, the folded graph never enters context wholesale — the control loop reads view(state), a projection: the distilled synthesis, open goals, the current run's frame, plus targeted lineage queries on demand. Closed history doesn't qualify for the view, so a 365-day-old agent and a 3-day-old agent present the same context footprint. What grows with age is the depth of what can be queried — the asset, not the liability. Your episodic memory holds decades; your working memory holds seven things. Recall, not loading.

GASP standardizes what's stored and recallable; the recall policy — view() — is deliberately the executor's. Best practice is four layers, each with a different trigger:

• Standing — identity + the distilled synthesis, always loaded, defended by an explicit token budget (the admission criterion and the synthesis step exist to protect this layer).
• Situation-triggered — at run start, query the graph by status and adjacency: open goals, last run's outcome, failures on the target at hand. For operational state, graph structure beats semantic search.
• On-demand — give the model query tools (lineage(goal), why(patch)) and let it pull when uncertain; each lookup is itself a logged event, so recall is auditable.
• Negative-space — before proposing an action, force a structural check for prior rejections on the same target. This one can't be left to the model's initiative: it can't choose to recall a rejection it has no hint exists.

And because state is standardized and executors are swappable, recall policy stops being folklore: two executors with different view() strategies, same repo, A/B'd on branches, judged by their eval outcomes.