Structured working memory for iterative work
Logbooks are shared working state: structured entries that agents and humans can append, patch, annotate, query, visualise, validate, and assess over time. An open concept, not a product — bring your own storage.
Why logbooks?
Agents produce partial work — findings, draft tasks, review notes, risk flags — one piece at a time. A logbook is the surface where those pieces accumulate as structured rows, so they stay scannable, filterable, and usable as work grows. Agents and humans add to the same logbook, whether the next reader is another step in this run, a reviewer, another agent, or a later session.
What can logbooks enable?
Deep research and review
Build multi-phase work from structured intermediate results.
Draft and staging workflows
Shape work before committing it to Jira, docs, or reports.
Background agent supervision
Inspect progress without reading full transcripts.
Cross-agent reuse
Let each pass leave behind work the next pass can use.
Controlled execution
Turn selected entries into tickets, reports, boards, or new agent runs.
Flexible by design
A logbook can live in a CSV, spreadsheet, JSONL file, SQLite database, or a purpose-built tool. What matters is not the backend. What matters is that the work is structured enough to query, update, and carry forward.
Get started
What are logbooks?
Learn what logbooks are, how they work, and where they fit between docs, trackers, and logs.
When should I use one?
Use a simple test to tell whether you need a logbook or just a doc, chat state, or a tracker.
Examples
See logbooks for deep research, backlog shaping, eval workspaces, and background agent monitoring.
Storage and actions
Pick a backend, define a stable entry contract, and connect the logbook to reports, trackers, or downstream agent runs.