The ledger

Every state change in a Works appends an entry to an automatic record of what changed and who changed it. hm calls it the ledger, and it is the reason a company can hand work to agents and still answer for the result.

It is not a feature you switch on. There is no code path that moves a task from one state to another without writing the transition down, because the write is part of the transition rather than a courtesy performed afterwards.

What an entry says

Each entry carries a sequence number, the kind of thing that happened, the entity it happened to, and the actor — the person or the agent seat responsible. Work you do yourself is recorded as the Principal. Work an agent does under dispatch is recorded as the seat it ran in, so a change is always attributable to something more specific than "the tool did it".

Append-only, on purpose

The record is append-only. A correction is a new entry, not an edit to an old one, so the history of a decision survives the decision being reversed.

That constraint is what makes the record worth reading. A log that can be tidied up is a log you have to trust someone about; a log that can only grow is evidence. It is also what makes a review after the fact cheap — the question "when did this change, and on whose authority" has an answer that nobody had to remember to write down.

What you can do with it

• Tail it live while agents are working, to watch a run rather than wait for it.
• Query it for one task, one initiative, or one window of time.
• Export it, because it is your record and it is on your machine.

What it is not

The ledger is not a chat transcript and not an analytics feed. It records state changes to the work, not every message an agent produced on the way there. Prose that matters — a one-pager, a proposal, a review — is stored as a document with its own revision history, and the ledger records that the document changed rather than swallowing it.