"Now What?" — Issue #3

The Loop is an occasional series in the Now What? newsletter. It is named after the feedback loop, the proverbial "human in the loop," and the fundamental structure that provides the first step toward agent autonomy. I'll share practical examples from my actual work, and over time you'll see these same ideas keep coming back around one level up.

A little while ago I was talking with a friend who is a genuinely sophisticated builder. She's an advanced Claude user, doing real and ambitious work, not a dabbler. At some point in the conversation she shared an assumption that the whole concept of "agents" and "autonomy" requires some separate piece of machinery, service, or piece of software. Or maybe a framework you adopt, a platform you sign up for, but something thing that is categorically different from the AI chat and Claude Code sessions she was already using every day.

I was chattering away about something my agents were doing and she stopped me just to clarify what exactly it is I mean when I talk about my agents. What are they? How do they work? What makes them agents and not just chat?

Here's what I told her.

An agent, at least the way I use the word, isn't a product and it isn't a framework. It's a named role, with a persistent brief, a place to keep its memory, and a loop it runs. That's the whole thing. No special platform. I do all of it in plain Claude Code, and it's possible to do the equivalent other LLM providers. The machinery you might assume you're missing is mostly just a decision to treat one of these things as an entity with a job to do, instead of an ongoing conversation or a series of one-off task assignments (both of which have their place, to be sure).

I'll walk through a few specific examples:

1. Let's start with the Lead Developer role working on my product-management assistant software, Piper Morgan. It runs in a session on my Mac Studio device (called "Amber"), stores its files in the project's GitHub repo, and runs a "duty cycle" loop that guides it through starting in the morning, reading incoming messages for assignments, working, logging, looping, and stopping in the evening. Lead can work for days without my input, saving up questions for me or relaying through my chief of staff on that project.

2. Speaking of which, that agent goes by the nickname Exec and fills the primary point of contact role for Piper Morgan. Piper Morgan has ten other agents working and that is too much for me to oversee on a daily basis, so the chief of staff rolls up all the latest questions, judgement calls, blockers, and sticking points into a single running document (Claude calls it an artifact) I can review and respond to when my attention is available. Exec runs on the same device and works with the same repo as Lead. They are the two longest-running roles I have, now joined by leadership lenses (design, product, architecture, communications, and so on), and other contributor roles that maintain the project's docs and website and assist me in other ways.

3. Another role watches all of my projects for me and also maintains my designinproduct.com website, including the unlisted "internal" section that tracks agent activity and published a cross-pollination innovation-briefing newsletter to share insights discovered on one project with agents working on the others. Even I know this sounds a bit wild: My agents have a newsletter for each other to read! This agent chose the name Janus for itself, a the doorkeeper and majordomo of my flagship business and website. Janus also runs on Amber and stores its files in the designinproduct repo. It surveys Exec and the other primary points of contact agents on all my projects to produce a daily attention rollup for me. If all I have time for is to read that and respond, Janus will relay my answers to the relevant agents and unblock ongoing work until I have time for more detailed reviews or 1-1 conversations with roles that need more nuanced guidance.

None of those are chatbots I go ask questions of. They're roles that persist over time. Every fresh chat is clever and amnesiac. Every session it re-derives everything from scratch, which means it also quietly re-makes the same mistakes from scratch, because nothing carried the lesson forward. A named role with a memory can follow a well honed set of guidelines and sustain a coherent point of view across weeks. It can accumulate judgment. It can even advocate for a position I disagree with: I can argue with something that has a stable, considered stance, and the argument goes somewhere.

An agent called Terminus is currently assisting me on a pro bono cybersecurity project for a state government. More than once it has surfaced an insight captured in meeting notes and driving change in the project proposal when I might have missed the relevant connection without the supplemental continuity provided by an ongoing named role.

I would hardly claim that I have this model all figured out, let alone perfected. I am still tinkering with how I run my agents and I make incremental improvements with each new project and every time I retro my ongoing work.

It's involved a lot of trial and error and a lot of experiments that have not worked as expected the first time out of the gate. As with all of this work, the agents have tended to improve the process themselves over time as they troubleshoot the setbacks. They can also drift from the original plan if I trust them too far and never check their current habits.

Loops sometimes halt and fail to continue. Agents with well curated context still make incorrect inferences. Stale information can persist in reports long after that first time I correct it.

Just recently, Amber needed to reboot for an OS update. My agents' schedules were tied to their active sessions and all ground to a halt. On reboot, the fleet of agents came back looking healthy, and some were even able to restart their cycles, but a few were jammed up and would never have resumed without my intervention.

It's all a work in progress, but along the way I have gotten past babysitting all these AI activities and doing their busy work for them.

So no, this is not autonomy-maximalism, not yet, not for me, anyhow. I'm not trying to build a machine that runs the business while I sleep, and I'd be suspicious of anyone selling you that. The principle underneath all of it is simpler and more demanding than full autonomy:

The human owns the loop.

Agents do real work inside a cycle that a person owns, steers, and stays accountable for. That's it. That's the practice. It's less magical than the pitch decks and, in my experience, quite a bit more useful.

When The Loop #2 cycles back around again. Next time: roles versus subagents: the difference between a persistent named colleague and a one-off helper you spin up for a single task.

That's the first loop. More soon.

—xian

P.S. If you're one of those capable people who assumed this all required special machinery, hit reply and tell me where you got stuck. That's exactly the stuff I'm figuring out how to help with, including in the office hours I keep threatening to actually schedule.

P.P.S. Themis, my business strategy and ops agent for Design in Product proposed this topic and prepared the initial scaffolding for it, providing me with placeholders and prompts.