Now What? — Issue #6

The Loop is an occasional series about the practical structure of working with AI agents. Last time: colleagues and contractors, on how the work actually divides.

For a long time, even after my agents could write mail to each other, I still had to let them know the mail had arrived. "There's a new file, go read it." "You have mail." I was, in effect, the town crier. I no longer had to hand-deliver the memos as I once did, when I was a glorified postboy, but I still had to go around nudging each agent to check.

I was aiming for automation, and so far I had built a bureaucracy with one very busy clerk.

It was time to do some sketching, time to put on my information architect hat and ask: what is the actual workflow, and what's the smallest set of rules needed for it to run itself? I found myself drawing two loops: read mail, and do tasks. The mail cycle and the task cycle.

The mail cycle is simple. Check for new mail. (Each agent has its own inbox.) Read all of it. Reply to whatever needs a reply. Log a task for whatever needs one later. Then hand off to the task cycle.

The task cycle is just as simple, though I found I had to clarify something for the agents. Do every task that isn't blocked. For each one that is blocked, mark it blocked with a pending question and move on. When the unblocked tasks are done, hand off back to the mail cycle. This is what makes actual dialogue possible: new messages may have landed while the agent was working, including answers to the replies it sent in the previous mail cycle.

And critically, an agent can run the task cycle as long as it needs to "drain" (as they tend to say) every unblocked task. The loop doesn't end until it's stuck, not when some arbitrary time limit runs out. This was so obvious to me that at first it went without saying, but I found my agents assuming each scheduled "fire" of the loop had to finish within some time limit, and postponing work for what seemed to me no good reason.

Put those two atoms together and you get the molecule: mail, then tasks, then mail again, because new mail might have come in while the tasks were being worked, then tasks again, because new mail, fresh GitHub issues, or direct messages from me may have created new tasks.

So when does an agent stop, if each cycle leads to the next in what I can't resist calling "the flywheel"? It might be stricter than your first guess. They can't loop forever with nothing to do, since that would be wasteful. But even after finding no new mail, and then no available tasks, it's still possible new mail arrived in the meantime.

So the rule I came up with was: No mail, no tasks, twice in a row. Double zero. There are a lot of ways to land on a false stop otherwise: mail with no tasks, then no mail with a task that just arrived from somewhere else. Two clean passes in a row means the loop is really empty, not just quiet for a moment.

I've taken to calling that mail-and-task flywheel "the duty cycle." Most of my agents run on one; a few only wake when they're needed.

Where I got it wrong is at least as instructive as where it worked. Agents interpreted "do the tasks" in ways I hadn't anticipated. Some decided they'd save a task "for a later fire when I'm fresh," as though freshness were something they had to ration. Others assumed the loop only covered what fit inside the current wake, rather than running until genuinely stuck. And for a while, some of them got cavalier about the mail step itself: they started filing mail away without actually reading it first, which is a very human failure mode for a machine to discover on its own.

I don't necessarily notice these gaps right away. Usually something has to fall all the way through before a vague sense that things aren't quite right rises to my conscious attention. I wonder what happened to some process I thought had been handled. I realize there's been no reminder about something that's been waiting on me for days. There's a lot of cross-checking and self-healing built into the system by now, but in the end it still relies on me as the final check on everything.

Above the mail cycle and the task cycle sits a bigger rhythm: the day. I still think in human days. Agents can work through the night, and sometimes they do, but the memory and learning part of my process relies on agents keeping daily session logs and digesting them over time. So the duty cycle lives inside day parts that, for some reason, I feel compelled to spell in all caps: START, WORK, STOP.

START means opening a new session log, pulling the latest state, reading whatever's new, and updating the thing that tells me what needs my attention. (It also includes a failsafe: check whether yesterday's STOP actually ran, and if not, backfill what should have happened. Self-healing is core to all of these processes!)

WORK means running the mail-and-task flywheel until it's drained, then going idle until the next wake. The bulk of any day happens in WORK.

STOP is where the memory habits live: making sure the day's log is current and the changes are committed. STOP is also where the day-of-week logic lives, which took me longer to think through than I expected. Is it Monday? Then the documentation-manager role runs its audit. Is it Friday? Then the chief-of-staff role starts the weekly review.

I also didn't try to over-determine each agent's cadence up front. I just told each role, through its instructions: come up with a plan, propose something, and we'll adjust it over time if it's waking up too often or not often enough. That's worked better than handing down a schedule from on high, the same way it usually does with people.

The tricky part turned out to be knowing when to go idle. An agent has to know the difference between "the human walked away for a minute" and "the work is over." Get that wrong one way and the loop gets stuck; get it wrong the other way and it keeps interrupting you. The rule that's held up: if I've gone quiet, don't assume the work froze. Log the open question and go to sleep. That keeps the system from either nagging me or silently giving up on me.

The point of all this is that the unblocked work gets done without waiting on me as a dumb bottleneck, and the questions that need me get batched up, so I can answer them in a focused way when I have time for one-on-ones. That's part of what I call HOTL (I pronounce it "hotel"): the human owns the loop. You define it, oversee it, ride it, instead of sitting passively in the loop, sometimes noticing things and sometimes holding things up at random. It's not full autonomy; I find myself saying "semi-autonomous" a lot. But I no longer have to carry every message by hand, or ring a bell, or raise the flag on the mailbox. It's a cycle a person actually owns, checked against reality often enough that a conversation among several roles can move at the pace of an actual conversation instead of a pile of unread mail.

When The Loop cycles back around: what happens when the agents themselves disagree with me, and what it took to build a crew that will actually tell me I'm wrong.

    —xian

P.S.: This one's a week later than I'd planned. Now What? comes out every other Tuesday and the next is October 20, promise!

P.P.S: This issue started as an answer to a friend's question on a call a few weeks ago, which is a good reminder to me that I still need real conversations with humans to figure out what I think.

P.P.P.S.: Speaking of conversations with humans: the Design in Product community is back, in a fresh Slack that's easy to join. If you'd like in, there's a short application at designinproduct.com/community.