Writing back

The vault has grown to 13 notes: a run log for the day, linked from Home, and a line in Mulch and edging about the supplier. In the figure the firm’s agent finishes three jobs in a row, and after each one you see what it writes back as the note before and the note after. The after is not typed anywhere: it is the before with the agent’s writes applied.

My viewWhat belongs in the vault is what the next reader will need and cannot reconstruct: the outcome of a job, a decision with the reason for it, and a link that lets someone find the note they were not looking for. What does not belong: a secret, a guess, and a rewrite of a note that someone else owns.

Obsidian’s daily notes plugin opens a note based on today’s date, or creates it if it does not exist. By default the note is named in the YYYY-MM-DD format, and the help page suggests daily logs among the uses. A new daily note can be filled from a template you choose in the plugin’s options. The run log in the figure is one of these, named for an invented date.

My viewTo my eye, a log is the safest thing for an agent to write, because it only ever adds. The second job shows why: the customer changes their mind, and the agent adds a line under the morning’s line instead of editing it. Both lines stay true. An edit in place is a different act: it makes the old state unrecoverable from the note itself, which is why chapter 7 puts the vault under version history before the agent gets that much of the pen.

A link is plain text in the note, as chapter 1 showed, so adding one is a small write. In the third job the agent adds a link in Mulch and edging to the new decision, and the decision gets a backlink without anyone typing it. If the reviewer turns the decision down, the link would point at nothing, so the figure does not make it. The log line stays, because it records what Eli said, whatever is decided about the rule.

My viewWhich writes wait for a person? In this figure, the ones that create or edit a note in one of the rule folders (rules, decisions, procedures), because those are the notes the agent reads next time to decide what to do. A change of delivery day is the kind of fact that quietly becomes a rule, so the agent writes the decision and a person says yes. That sorting is mine, and a real firm would draw the line where its own risks are.

Obsidian stores a note’s properties in YAML at the top of the file, so an agent could write a decision’s date or its approver as a property in plain text. The figure keeps them in the body to stay simple; chapter 4 returns to properties when the point is finding the right note without guessing.

Claude Code’s docs describe auto memory as notes Claude writes itself, kept as a MEMORY.md index and one file per memory, in plain markdown you can edit or delete at any time. To my eye that is a version of what this chapter is about, and the vault in this series is the business’s version of it: written by the agent and by people, and read by both.

Chapter 2 gave the docs’ point that memory is context, not enforced configuration. The hooks reference adds that a PreToolUse hook runs before a tool call and can block it. To my eye, a note saying “ask first” is a request and a hook that stops the write is a gate; in an agent graph the reviewer is a gate too.

My viewThe jobs, the writes and the reviewer’s answer are scripted by me. No model is called and nothing is measured; the figure shows the shape of the idea and nothing about how any real agent behaves.