CLI primitives for agent state
Give your agents state that survives the session.
Four standalone CLIs — tasks, operational state, knowledge, and queues — each persisting to its own SQLite file. Install once, call from any shell or agent loop. No Postgres, no Redis, no daemon.
Why agents lose the plot
The agent resets. The work shouldn't.
Every new session starts from zero unless something durable lives outside the model. Markdown notes rot under concurrent writes, and a hosted memory server is another service to run, secure, and babysit. primkit answers each question below with a small CLI your agent calls from the shell — four binaries, four SQLite files, composable like any Unix tool.
taskprim
“What was I doing?”
Open work, dependencies, and a frontier of what is unblocked.
stateprim
“Did we already do this?”
Key-value state, dedup checks, and append-only audit logs.
knowledgeprim
“What did we learn last week?”
Entities, relationships, and hybrid full-text + vector search.
queueprim
“What still needs to run?”
Prioritized jobs, retries, and a dead-letter path.
Composable by design
Four tools, one agent loop.
The primitives aren't a menu you pick from — an agent uses them together every turn: pull the next task, check what's already done, record what it learned, queue the follow-up. Plain shell commands, piped and chained like any Unix tool.
Each line is one binary writing to its own SQLite file. Use them in any order, from any shell, agent loop, or cron job — there is nothing to wire together first.
Why primkit
Explicit, not automatic. A file, not a fleet.
Every other way to give an agent memory is something you run — a hosted service, an SDK to wire in, a framework to adopt, an auto-capture pipeline to trust. primkit is the durable layer underneath. This is what you get instead.
Structured, not scraped
You decide what gets stored — tasks, keys, entities, jobs — instead of hoping an auto-capture pipeline grabbed the right snippet.
Honest scope
Not a full agent runtime. The persistence layer underneath the agents you already run.
No daemon
Nothing to keep running between agent turns. State is a .db file on disk — not a service to host, secure, and babysit.
CLI-native
The command line is the product, not an afterthought — agents call it like any Unix tool, scriptable and pipeable, --format json. MCP ships for IDE agents, but it isn’t the main interface.
What you can build
Agents that investigate, not just react.
Point an agent at a knowledge graph it can grow and a task frontier it can pull from, and it stops being a one-shot responder. It investigates open questions across days, connects what it learns, and keeps the thread between sessions.
Read Building Curious AgentsAccumulate, don’t reset
knowledgeprim turns scattered observations into a graph the agent can traverse and extend.
Coordinate across handoffs
taskprim seen-tracking and queueprim atomic claims let many agents share one source of truth.
Run long-horizon work
Durable tasks, queues, and state survive crashes and restarts so an effort spans days, not turns.
The docs
Start where your problem is.
Start in 60 seconds
Install a binary, run three commands, and inspect JSON output an agent can use.
OpenAgent reference
Command tables, flags, and JSON schemas for programmatic and MCP callers.
OpenArchitecture
How the four modules share SQLite, CLI, HTTP, and MCP surfaces.
OpenBuild curious agents
Use knowledge and state to investigate and learn across sessions.
OpenStart here
Stop re-explaining your project every session.
Install a primitive, run one command, and let your agent write state that outlives the terminal. Databases auto-create on first use — no config required.
Not sure it fits? Let your agent decide.
Paste this into Claude Code, Cursor, or any agent with web access — it maps primkit to what you are actually building.
Read https://github.com/propifly/primkit/blob/main/docs/agent-reference.md then tell me which primkit primitives would help with what we're doing.