Start designing operating loops.

Open my "AI Brain" repo and you will find prompts. You will also find meeting transcripts, memory files, session logs, scripts, skills, scheduled jobs, evals, and several artifacts that began life as “I wonder if AI could do this” and somehow acquired infrastructure.

My inner librarian shines through when I work with AI. First I made a filing system. Then I made a filing system for the filing system. Then I taught it to send me a morning briefing.

As AI has changed so have I. I no longer ask, “What can I get AI to produce?” and now ask, “How should this work keep moving?”

If you want AI to help with real work, stop collecting prompts and start designing operating loops.

A prompt gives you an answer. A loop gives you a way of working.

Prompts are useful. I still write them all the time especially with smaller models. But a prompt assumes I will remember to use it.

I will remember where I saved it. I will know what context to paste in. I will notice when the answer is wrong. I will carry the useful parts into whatever happens next. And then I will do the whole thing again next Tuesday.

That is not a system. That is me serving as the system.

The useful things in my repo started to emerge when I wrapped prompts in a repeatable shape. The details vary, but the loops tend to have five parts:

1. A trigger that decides when the work should start.

2. The context the AI needs to do the work well.

3. An action that produces or changes something useful.

4. A check that catches weak, unsafe, or made-up output.

5. A memory that makes the next run better or easier.

What the loop looks like in practice

Take meeting transcripts. Saving them is not especially useful on its own. It gives me an impressive pile of text and the vague comfort that Future Lauren will know what to do with it. Future Lauren has asked me to stop assigning her projects.

The loop is more useful than the archive.

A meeting ends. That is the trigger. The transcript and its metadata become the context. A process saves it in a predictable place and extracts decisions or open questions. That is the action. I review anything that will be posted or treated as a decision record. That is the check. The result becomes searchable context for a morning brief, a product update, or the next time I need to remember why we made a call. That is the memory.

The same shape appears in my AI coding work. A session is about to end. The AI writes a narrative log of what we tried, what worked, what we rejected, and what is still open. The next session reads the latest log before touching the code. The work no longer disappears because I closed a terminal window.

Not everything needs to become an agent

This is where I have to fight my own tendency to build a tiny machine because I had one interesting thought before breakfast. Some tasks should stay prompts. If I do something rarely, the stakes are low, and I expect to change my mind halfway through, a conversation is probably the right interface.

When I repeat a task and the judgment starts to settle, I turn the prompt into a skill. A skill is a set of instructions the AI can load when that kind of work appears. The skill captures more than the wording of a request. It can include what context to look for, what good output looks like, what not to do, and when to stop and ask me.

When part of the task needs to behave the same way every time, I move that part into code. A language model can decide what a meeting means. It should not improvise how a filename is formatted, where a file gets saved, or whether an API call is allowed. Those are jobs for scripts, schemas, and rules.

Only then do I think about scheduling or autonomy. If the work has a clear trigger, enough context, a useful destination, and a way to catch mistakes, it may be ready to run without me starting every step.

So the progression in my repo usually looks like this:

Conversation → saved prompt → skill → tool → operating loop

It is not a maturity model. Moving to the right is not automatically better. It is a cost curve. Every step trades flexibility for repeatability, and every step creates something new that can fail while I am making coffee.

The question is not “Could I make this an agent?” Of course I could. Given enough time, I could make an agent whose main job is judging whether another agent deserved to exist. (Please do not give me the weekend.)

The better question is, “Which parts of this work have become stable enough that I should not have to rethink them every time?”

That is how my morning briefing became more than a summary prompt. It has sources it knows to check, a structure for separating new information from old noise, rules about what belongs at the top, and a delivery schedule. My role moved from assembling the briefing to checking whether the loop was still paying attention to the right things.

It is also how I learned that checks are part of the product. An AI system that drafts a customer communication and an AI system that drafts one while separating evidence from assumptions are different systems. A workflow that can post somewhere is not finished because the post request returned 200. I need to know what it posted, what facts it used, and where a human should still be part of it.

When I find a prompt I have used three or four times, I do not immediately polish the wording. I draw the loop around it. What starts the work? What does it need to know? What should happen next? How will I catch a bad answer? What should survive for the next run?

So ask yourself where you can start drawing your loops and put your AI to work.