Nestor G Pestelos Jr · Writing

The Ledger That Stayed Empty

Published August 14, 2026

Part three of a three-part set on how I work with agents day to day. Part one: Nine Security Issues, Zero Lines I Wrote. Part two: The Scanner That Feeds the Pipeline.

The file that isn't a to-do list

I keep a single ledger of open commitments: things I've said I'd do, for someone, by some point. It's not a task manager. Task managers fill up with things that would be mildly nice to finish. This file holds only the things where, if a week from now the thing just hadn't happened, an actual person would notice a dropped ball. That's the literal test I use: if this session ended right now and the thing never happened, would a ball drop for somebody? If yes, it goes in the ledger. If no, it's just a task, and tasks don't belong there.

In practice that line falls in one place: deciding to do something is the promise; doing it, once decided, usually isn't.

Every agent working in this system carries the same standing instruction: apply that test the moment a commitment gets made, in the same turn, without waiting to be asked. The ledger is the one place I've decided is the source of truth for what I owe people and by when. I retired a reminders app that used to also claim that job, because having two systems both claiming to be authoritative about deadlines is worse than having one that's occasionally incomplete.

Running the test on today

Nine security issues got triaged, planned, red-teamed, implemented, and turned into pull requests. All nine merged today. Along the way the pipeline caught:

• A race condition that could have let an attacker rebind a network listener.
• An IPv6 address trick that would have slipped past an address blocklist.
• A redirect check that validated the host but not the scheme.

None of that fixing went into the commitments ledger, except in one place I'll get to. Run the test on any single piece of it: if I'd walked away and none of those nine issues got fixed today, would a ball have dropped for someone? For seven of the nine, no. Nobody was expecting a PR by end of day, and nothing was promised to a person on a deadline. It was backlog: real, worth doing, but not a commitment in the sense the ledger cares about, the same category as the scan flagging a stale pull request so it can be closed. The other two are different, and the next section is why.

The lines that do belong

The ledger touches today's work in two batches:

• Building the system. Five line items opened the day before the pipeline ran, for portfolio-ops, the scanning-and-dispatch system described in part two: three closed same-day, two still open behind a separate scheduling decision. This was a commitment I'd made to myself. It still clears the ledger's own bar: if a week had gone by and it hadn't happened, I would have been the person who noticed the dropped ball.
• Testing the system. Two more lines landed the day the pipeline actually ran. One re-bound how the scanning gets scheduled. The other committed to testing the dispatch runbook, naming two of the nine issues as the first wave to run it against. The promise there was about the routing working, discharged only once those two bugs actually got fixed and merged. For those two issues, walking away really would have dropped a ball.

The tool running today needed one hand on the wheel. A nested review agent's verdict got lost mid-run and sat blocked until I caught it and relayed the verdict by hand myself, the failure mode part one covers in full. That nudge was upkeep on infrastructure I'd already decided to build, not a new promise to anyone. Having decided to build it, and to test it, was the promise.

That's the whole design behind the catalog of repos, the security backlog, the pull requests: none of that becomes a ledger entry just because it exists or gets acted on. Once built, the system's ordinary operation stays outside the ledger's scope.

Why the empty file is the correct output

If every automated pull request, every closed stale PR, every routine security fix became its own ledger line, the ledger would stop being useful for the one thing it's for: telling me, at a glance, what I still owe somebody. It would become an activity log: accurate, useless, a list you stop reading because it's mostly noise. The same instinct shows up elsewhere in how this system is built: no scoring, no streaks, no volume targets in this file.

So the correct outcome of today, from the ledger's point of view, is mostly silence. Nine issues fixed, nine PRs merged, real security bugs caught before they shipped. The file that tracks what I owe people moved once, on the decision to test the system, and stayed silent on the fixing itself. Three systems did three jobs today: one decided what needed fixing, one did the fixing, and the third wrote down only the decision to build and test the second one.