Thinking in Loops

At work, we plan in weekly iterations. At the end of each week, I look at what has been done and help prepare for our Monday product meeting. There are ongoing projects to consider, customer feedback to work through, and decisions about the mix of work ahead. Sometimes a new initiative starts to emerge.

I have been thinking about this as a loop. We decide where to put our effort, do the work, and return to the decision with more information. Loop engineering gives me a way to be deliberate about that process: what starts it, what an agent needs to know, and how the result informs the next decision.

From bug fixes to product direction

Anish Acharya's conversation with Lenny Rachitsky helped give this thinking a shape. He describes loops at different levels of a company, with the work of individuals feeding into teams and larger business decisions.

As a developer, the smaller loops are familiar. We reproduce a bug, make a change, and test it. A failing test sends us back with more information. After releasing the fix, we can find out whether it resolved the customer's problem.

Those smaller loops sit inside the weekly planning loop, which in turn feeds our longer-term product direction. The evidence gets less tidy as the questions get broader. Finishing a project tells us something about delivery. It may take longer to learn whether it helped the people we built it for. An investigation might give us a good reason to stop.

When I look back over the week, I need to understand what has changed about the decisions in front of us. A new request may belong inside an existing project. Several separate requests may point towards a larger theme, though recognizing a theme is still some distance from deciding to fund it.

Much of the preparation is in bringing those relationships into view so that we can discuss them.

What the agent needs to know

I keep our product model and roadmap operating model as documents in Linear, alongside the work. The product model describes who we are building for and the boundaries of the product. The roadmap model describes how an observation or idea moves towards a commitment. They give both me and the agent a basis for interpreting the week's activity.

They also make some of our judgment explicit. An idea can remain an idea. Accepting something into the backlog does not commit us to doing it next week. Work that helps close a sale has to be weighed alongside reliability and longer-term product work.

A customer request arrives with a person and a situation behind it. A buyer may want something that adds work for the practitioner. A promising idea may need discovery before it deserves engineering time. A neatly written plan still needs to account for those questions.

This gives the agent a basis for helping me reason about the week's material. It can help relate feedback to an existing project or find a gap in the evidence for a proposed initiative. I want to arrive at Monday's meeting with the decisions that need attention in focus, and enough history to understand why they matter now.

Making the loop repeatable

I have skills embedded in Linear that run through Loops. Of the delivery management tools I have used, I think Linear is getting this shift most right. The product context, instructions, and work can live together.

My triage loop picks up an issue from the triage queue and runs a skill against it, with our product and roadmap models as context. The skill asks the agent to make the smallest defensible decision about an incoming issue. The agent checks the evidence and possible duplicates, separates the underlying problem from the proposed solution, and recommends what should happen next. Accepting an issue means it is worth retaining. It carries no promise to build it.

The recommendation comes back to me before anything changes. It includes the reason for the decision and the evidence or event that should cause us to revisit it. Once I approve, the skill applies the agreed changes and records the decision.

That last part matters to me. A parked request has a reason to return. An accepted idea still has questions to answer. The record gives the next pass something to work from, including a condition under which the earlier decision should change.

The recurring runs use the same skills, which give me a place to record how I want the work approached, and to preserve corrections when I find something missing. This connects with what I wrote earlier about agent memory. An explanation becomes useful beyond one conversation when it is available the next time the work comes around.

Monday comes around again

Acharya observes that agents can help improve an approach until it reaches a plateau, while people remain important in finding a new direction. I recognize that problem in product planning. A team can become very efficient at advancing a project whose premise needs another look.

There is a risk in giving an agent our existing plans: it may get good at fitting new evidence into them. The preparation can shape what we even think to discuss. I need to see the feedback that challenges a project's premise, too.

The loops help get me to the point where I can make those decisions. The Monday meeting is a place to consider what should change, including whether to stop something. Some weeks the right decision will be to continue. Other weeks, new evidence may lead us to change the scope or leave room for a different idea.

Thinking in loops gives me a way to see where AI can help within a process I understand. I am still working out how much of the preparation an agent can carry well. What I want is fairly plain: to arrive on Monday with a clearer understanding of what happened, and a better basis for deciding what comes next.

Loops in your own work

I'm genuinely curious: are agentic practices changing the way you work? Is your organization also thinking of AI use in loops? If you'd like to compare notes or learn more about my approach, get in touch. Always happy to chat.