Loop Engineering Is Just Software Engineering

TL;DR

An agent loop is a repeating job that waits for a kickoff, does the work, and comes around again. Write the steps and who does each. Name what starts it. Name one thing it will break downstream. Write a check you can finish in a few minutes. Software people call that process design, event-driven architecture, systems thinking, and debugging. The new label is loop engineering. You don't need to write code to do it.

A new name for a repeating job

A new inquiry lands in the form while you are on a call. By the time you hang up you have forgotten it. Tonight you will rebuild the proposal from a blank page, the way you did last time. You want the first draft waiting.

That repeating cycle is an agent loop. An agent loop is software, often with AI, that waits for a kickoff, does a job, and comes around again. Loop engineering is the work of designing it.

On June 26, 2026 I wrote that loop engineering is just software engineering: process design, event-driven architecture, systems thinking, and debugging. It feels different because AI can do more without a human in the middle. Take a 50-foot view of the job: look at it from far enough away that the new label falls off. Those four skills are still what you are doing.

You don't need to write code to use those four skills. You need a page, a trigger you can name, a sense of what else in the week the loop will touch, and a check you can finish in a few minutes.

Write the steps down

Open a page and write the job in the order you actually do it. Process design, here, means those steps plus a name next to each one: you, the assistant, or a tool you already pay for. An agent loop without that page is a habit. Habits don't survive a week you are on a plane.

The page is the same work as writing a recipe before you hand a task to AI. If you can't write the steps, you are not ready to hand the job off. Keep doing it yourself until the page exists.

Who does each step matters as much as the order. "The assistant drafts. I read it against the page. I send." is a design. "The assistant handles proposals" is a wish.

Name what starts it

Write down what kicks the job off. In software, event-driven architecture means work starts when something happens, rather than when a person remembers to run it. The slice you need this week is that kickoff. A new email in a labeled inbox can start it. So can a form submission, or Friday at 4pm.

Put the kickoff on the same page as the steps. "A new form" is a kickoff. The point of an agent loop is that the job starts without you watching the clock.

A weekly report that waits for Friday at 4pm has the same shape as a proposal that waits for a form. You still have to name the trigger.

Trace what else it hits

Ask what else in the week this loop will touch, and what breaks if a step is wrong. Systems thinking is that question with a longer name. A draft proposal that invents a start date does not stay a draft problem. It hits the calendar and the call where you walk it back.

Before you let a loop run, name one downstream thing that would go wrong. The tracker might get a second proposal for the same person. The rate might not match the one-pager you send everyone. If you can't name one, you have not looked yet.

A chat thread is a bad place to leave a proposal loop. The thread does not have the calendar or the rate card. The rest of the business still does. I walked through that split in Be Careful How Much Business You Leave to Your AI Assistant.

Notice when it's wrong

Name the question you will ask to see if the loop failed. The check is that question, answered in a few minutes without redoing the job. Debugging is what you do next: find which step on the page produced the bad output, then change that step.

"The start date is a week we can actually begin" is a check. "It sounds like us" only works if you also have two examples you treat as the standard.

When the check fails, you fix the page, not only the one PDF. A loop you only correct by hand every time still needs you on every run.

The check is the same test as whether you can tell the result is right without redoing the job.

A proposal loop, walked once

Say you run a small consultancy, you and one other person. A form on the site collects a new inquiry. You want an assistant to draft the first proposal so you are not starting from a blank page every time.

Write the steps and who does them. The form arrives. The assistant pulls the notes, matches them against the services you actually sell, and drafts the scope. You read it against the page. You send.

If the rate, the services you sell, and the next open week are not on the page, stop. The assistant will invent them. Write those down first. If the scope still changes on every inquiry, leave this loop alone.

The kickoff is the form. A new email in a labeled inbox would work the same way.

The draft has to carry the current rate, the calendar for when you can start, and the tracker so the same person does not get two proposals. If the assistant invents a start date you cannot keep, the rest of the week breaks. If it writes a scope you do not sell, you spend the call walking it back.

You notice it is wrong when a draft promises a start next week and you are already booked, when the price does not match the one-pager, or when a line is a service you do not sell. The check is three questions. Is the start date a week you actually have? Does the price match the one-pager? Is every line a service you sell? If any answer is no, find the step that produced it and change the page.

Your week may be status notes, onboarding, or follow-ups after calls. The shape is the same. Write the steps, name the trigger, trace what else it hits, and write the check.

Where it really is different

AI models did change what a computer can draft without you. A machine that can read an inquiry and write a proposal is doing more than filling a name into a template. That leap is real, and it is why the work feels new.

Deciding what happens, when it starts, what else it hits, and how you know it failed did not get easier. Those were the software skills before the models jumped. They are still the skills. The new label should not lock you out of a job you already do on Fridays.

The 50-foot view is that design work. You can learn it from the week you already run. Writing code is a later step, if you need it.

Takeaway

Pick one repeating job this week, the one you already rebuild by hand.

Write the steps and who or what does each. Name the trigger. Name one thing downstream that would break. Write the check. Run it once from that page, by hand. Use the assistant inside a step if you want a first draft. Do not skip the check.

If the page exists and you want a second reader on what the loop will hit in the rest of the week, that is a 20-minute conversation. We look at the recurring job and the tools you already use. I'll tell you if AI won't help. Simple conversation. No pitch, no commitment.

If you cannot write the steps yet, skip the call. Write the page first.

Book a discovery call