← Blog

From In the Loop to On the Loop: Two Real Changes to My Second Brain

15 June 2026

Geoffrey Huntley has a line about Loom that has been rattling around my head for weeks. The job of a software engineer, he argues, is changing from being in the loop — manually carrying every implementation task — to being on the loop. You stop hauling the cargo by hand. You define the goal, maintain the spec, set the constraints, review the output, and engineer the back-pressure that keeps the autonomous system on the rails. He compares it to a locomotive engineer: the point was never to carry the freight on your back. The point is to keep the machine on the track.

That framing is easy to nod along to and hard to actually do. So instead of theorizing, here are two concrete changes I made to my own repo — the “second brain” that runs my work at Bellaventure — that moved a real workflow from in-the-loop to on-the-loop. One is about how email gets into the system. The other is about how my weekly review gets written. Neither is glamorous. That’s the point.

The locomotive metaphor, made literal

When you are in the loop, you are the load-bearing component. Nothing moves unless you move it. Every email gets read by you, sorted by you, filed by you. Every weekly review gets typed by you, from a blank page, on a Friday afternoon when you are already tired.

When you are on the loop, the machine moves on its own and your job changes shape entirely. You are no longer the thing that does the work. You are the thing that:

  1. Defines what “good” looks like (the spec).
  2. Sets the rails the system can’t leave (the constraints).
  3. Reviews what came out the other end (the gate).
  4. Builds the back-pressure that catches the system before it goes off the track (the safety).

The trap is thinking “on the loop” means “walk away.” It doesn’t. It means you move up the stack — from operator to engineer of the operator. The two changes below are exactly that move.

Change 1: The greg+brain alias — turning email into an ingestion pipeline

The problem with being in the loop

For a long time, getting something into my second brain meant me doing it. If I wanted a document, a note, or a stray thought captured and filed, I had to forward it with the right magic word in the subject line. The original setup filtered on sender plus a subject containing “brain”:

FILTER_FROM_ADDRESSES = [
    "gregory.hills@gmail.com",
    "greg@1sphere.ai",
    "greg@bellaventure.co",
]
FILTER_SUBJECT = "brain"

This is the load-bearing-human pattern in miniature. It was fragile in exactly the ways humans are fragile: I had to remember the convention. Forget the subject word and the email vanished into the general inbox. Conflate work and personal sender addresses and the filter caught the wrong things. The system only worked when I behaved.

The change: an address, not a ritual

I switched the whole thing to a plus-addressed alias:

DEFAULT_BV_BRAIN_FORWARD_ADDRESS = "greg+brain@bellaventure.co"

Now anything sent or forwarded to greg+brain@bellaventure.co gets labeled and pulled in. The Gmail filter routes on delivery, not on me remembering a password-word:

criteria={"query": f"deliveredto:{config.bv_brain_forward_address}"},

That looks like a trivial config swap. It isn’t. It is the moment the ingestion contract stopped depending on my behavior and started depending on an address. An address is infrastructure. A subject-line convention is a habit. You can build a machine on top of an address. You cannot build a reliable machine on top of a habit.

Wiring it onto the loop

Once ingestion is an address, automation can sit on top of it without me in the path:

I am no longer the thing that reads, sorts, and files. The machine does that on a schedule. I read the summary.

The back-pressure that keeps it on the rails

This is where “on the loop” earns its keep, because an autonomous email processor that can file and delete things is also an autonomous email processor that can file and delete the wrong things. So the rails are explicit:

That list is the loop I sit on. I didn’t make the system safe by watching it. I made it safe by engineering what it is and isn’t allowed to do, and then letting it run.

Change 2: The end-of-week review — agent drafts, human grades

The old ritual

The end-of-week review was the most in-the-loop thing I did. The /eow command opened a single interactive session, and then I sat there and wrote the whole thing: what I delivered, what slipped, the root causes, the vibes check, next week’s adjustments. The agent fetched data; I produced every sentence. One human, one blank page, every Friday.

It was also the workflow I was most likely to skip when the week had been brutal — which, of course, is exactly the week the review matters most.

The change: retire the command, restructure the work

I retired /eow as a primary command and folded the work into /close week, driven by the runbook at 00_time/00_workflow_runbooks/close_week_RUNBOOK.md. The restructure changed who writes the first draft. The runbook step is now explicit:

Present a draft to the user for review before writing.

That is the whole inversion in one line. The agent now drafts each section of the review — grades each deliverable, summarizes what I delivered grouped by client, summarizes what slipped, proposes the root-cause analysis, gathers the transcripts for the vibes check, drafts next week’s adjustments — and hands me a draft. My job is no longer to compose. It’s to grade: accept, correct, or reject.

This is the locomotive engineer move applied to writing. The freight (the prose, the aggregation, the grouping) rides on the machine. I keep it on the rails by reviewing it.

A queue instead of a session

The other half of the change is that review stopped being a single synchronous event. The close-week flow now opens with a step that didn’t exist before — draining a human-gated review queue:

So all week, the autonomous pieces (the inbox crons, the email-mediated agent runs) deposit decisions that need a human onto a queue. On Friday I work the queue. The system has been running the whole time; the review is where I exercise the judgment it deferred to me — in a batch, against a structured list, instead of as a thousand interruptions.

Chain of custody for autonomous work

The last piece is auditability, because the moment agents do multi-step work on your behalf, “what actually happened?” becomes a real question. So I added a runbook for email-mediated agent runs. When a thread turns into genuine multi-turn agent work — multiple turns, multiple agents, multiple changed artifacts, or a blocked/partial result — it gets a durable run log in 00_time/07_loop_logs/, separate from the email itself. The email is the source evidence. The run log is the control trail: turn-by-turn summaries, source IDs, what changed, where it stopped.

Crucially, not every email gets a log — only the ones that need a chain of custody. That distinction matters. On-the-loop doesn’t mean logging everything into noise. It means logging the things a future you (or a future audit) will need to reconstruct, and letting the trivial stuff stay trivial.

What actually transferred from me to the machine

Lay the two changes side by side and the same shape shows up twice:

In the loop (before) On the loop (after)
Email ingestion I forward with the right subject word; I read, sort, and file each message An alias ingests; crons pull and triage on a schedule; I read a summary
EOW review I write every section from a blank page in one session The agent drafts every section; I grade, correct, and approve
My real job Operator — carrying each task by hand Engineer of the operator — spec, constraints, gate, back-pressure

In both cases I gave up the doing and kept — actually, deepened — the deciding. The alias didn’t remove me from email; it removed me from the mechanical part so my attention lands on the summary and the gated exceptions. The EOW restructure didn’t remove me from the review; it removed me from transcription so my attention lands on the grading and the judgment calls.

The uncomfortable part

Here is what the metaphor doesn’t tell you: being on the loop is harder than being in it, not easier. When you carry the cargo by hand, the failure mode is obvious — you drop it, you feel it, you pick it back up. When you are on the loop, the failure mode is silent. The machine quietly files the wrong email, or drafts a confident-but-wrong root cause, and unless you have engineered the back-pressure — the restricted tools, the human-gated queue, the audit log, the overmatch guards — you won’t notice until it’s three weeks downstream.

So the work didn’t disappear. It moved. It moved from executing the task to designing the system that executes the task and the checks that catch it when it’s wrong. That is the locomotive engineer’s actual job. Not carrying freight. Not even driving fast. Keeping a heavy, fast-moving, mostly-autonomous machine on the rails — and knowing, precisely, where the rails are.

Two small changes. Same direction every time: off the load-bearing path, onto the loop.

← Back to the blog