You re-explain decisions, constraints, and half-done work every session. The graph takes that job.
The agent writes decisions, open questions, and boundaries as it works — and finds them next session without you.
▸ task · add retry handling to the client
↵ found · decision · backoff, limits per-token
● raised · asking before coding over it
Months back, the call was backoff over a retry queue — rate limits are per-token. New work starts drifting toward a rewrite and runs into the standing decision, its why still attached. The agent asks before coding over it.
Solves /
Re-defending decisions you already made
✓ partition key chosen
? ordering kept across partitions? OPEN
↳ took the safe path; question stays raised
✓ consumer idempotent
The agent assumes ordering holds across partitions and takes the safe path. That assumption is now a live open question in the graph. When new code lands beside it, the question speaks up.
Solves /
Seeing every place the agent guessed
◉ resume here
session died
next session: orient & continue
Mid-refactor, the window runs out. The next session reads the graph: half the refactor done, two decisions made, one question open. It continues from the node — not from the diff.
Solves /
No re-deriving the plan from diffs
agent A · migration
agent B · risks
one graph, not two transcripts
One agent works the schema migration. A second, building nearby, reads the same graph and raises the index risk on /search before the change lands. You follow the whole effort as a single thread of reasoning.
Solves /
Steering parallel agents as one effort
task · extract billing into its own module
decided · keep the ledger append-only
decided · backoff over queue for retries
open · ordering across partitions?
refactor · invoice.calc → billing/
context window exhausted
orient · reading the graph
found · half-finished refactor, 2 decisions, 1 open question
agent · Resuming billing extraction. Two decisions on record, one question open.
Nobody wrote a recap. The next run reads the graph.
Memory stores what your agent knows.
verstak gives the gaps a lifecycle.
As you build, the graph builds with you: the actions, the decisions, the why behind them. Your agent reasons over that structure, and you can read it back.
Questions and risks become entries that hold their place until someone closes them. The agent raises them, parks them, brings them back — and when it hits broken wiring, it says so.
Several agents work the same graph at once — one coding, one logging decisions, one triaging risks — while you set direction. Each reads what the others put down, and builds on it.
One graph, one train of thought — however many agents are working it.
Each comes from a tradition that spent centuries on it. Each leaves a mark you can point to.
正名
Your agent reads what the function does, then renames it to match, so the name stops lying to the next person who opens the file.
Paste one prompt into the agent you already run.
It installs and connects; you confirm each step.
Install
Set up verstak: install the skills from github.com/verstak-ai/skills and connect the graph MCP server with my token.
The verstak skill set lands in the agent's toolkit, pulled from the public repo.
Your token wires the graph MCP server into the agent's config.
Restart the session.
Your agent brings the repo to the verstak standard — AGENTS.md, working rituals — and seeds the graph with the structure of your codebase. Every session after that starts inside it.
First session
verstakify
Prefer to do it by hand? Step-by-step setup per agent lives in the repo README.
FAQ
No. Memory recalls what the agent knew. The graph holds how the thing is built: decisions with their why, questions still open, boundaries. The agent reasons over that structure instead of a pile of facts.
In your repo. The graph holds what the agent writes about it, not the source.
The nodes the agent writes: decisions, questions, boundaries, and their links. Whatever text your agent puts into a node travels with it — keep secrets out of the reasoning the same way you keep them out of commit messages.
One call your agent makes to the graph. Orienting at the start of a session, reading a node before it edits, writing a decision — each is one operation.
Writes and reads have separate counters, and each stops on its own. Out of writes, the agent keeps reading and reasoning over the graph; out of reads, it works without the graph until the counter resets. The graph itself stays intact through both.
If your agent loads skills and connects over MCP, it works. Setup is the same flow everywhere: one prompt to install and connect, one restart so the connection loads, then "verstakify" in your repo.
You drop to the Bench allowance. The graph you built stays; your agent just makes fewer calls per month.
Writes and reads meter separately.
Both tiers carry the whole method.
Bench
First sessions
Forge
for daily drivingEvery session
A write is a node or edge your agent creates or changes.
Reads — orienting, browsing, search — are metered on their own line.
Set up verstak: install the skills from github.com/verstak-ai/skills, connect the verstak graph MCP server, then orient in this repo. Bench is free — 1,000 writes, 10,000 reads a month. The skills are public — read them before you install.