Thinking in Loops

One way to identify where agentic AI can help a business is to look for the loops in its work. A decision leads to action, the action produces new information, and that information shapes the next decision. I have been applying this lens to our weekly product planning.

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.

The feedback available in a loop helps determine what we can ask an agent to do. In a bug fix, a failing test gives it a specific reason to try again. In product planning, finishing a project tells us that we delivered something, but learning whether it helped a customer takes longer. Designing the loop means deciding what evidence would justify the next action and where a person needs to exercise judgment.

In weekly product planning, the feedback takes the form of customer requests and evidence from ongoing work. My preparation starts with asking what that evidence changes 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. Bringing those relationships into view gives us something concrete to discuss.

What the agent needs to know

An agent needs to understand how we make product decisions to help with the work. I keep that context in two canonical documents alongside our work in Linear. Our product model describes who we are building for and the boundaries of the product. Our roadmap operating model describes how an observation or idea moves towards a commitment. Together, they help the agent interpret new feedback against what we are trying to achieve.

Every product team should have a clear product model. At CodeLantern, for example, our product model consists of the following elements:

Our roadmap operating model distinguishes keeping an idea from committing to build it. An idea can remain an idea, and 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.

The agent needs to examine whose problem a request would solve and what evidence supports it. A buyer may want something that adds work for the practitioner. A promising idea may need discovery before it deserves engineering time. Our product model helps frame those questions, but each request still needs evidence from the people affected.

The agent can help bring the decisions that need attention into focus before Monday's meeting. It can connect feedback to an existing project or identify missing evidence for a proposed initiative. That gives us a clearer basis for discussing what should happen next.

Making the loop repeatable

A repeatable loop needs a trigger as well as instructions and context. Linear is building those triggers into the product, so changes in the work can start agentic work. A project's target date changing, for example, can prompt an agent to update the launch plan and explain the change to the people affected. Teams can build on that machinery instead of having to assemble it themselves.

I capture the instructions in skills that run through Linear Loops, alongside our product context and the work itself. That lets me focus on what the agent should do, what evidence it needs, and when it should bring a decision back to me.

Part of our weekly planning preparation happens as requests arrive. My triage loop helps assess them before we consider them alongside the rest of our product work. When an issue enters the triage queue, the agent runs a skill using our product and roadmap models as context. It checks the evidence and possible duplicates, separates the underlying problem from the proposed solution, and recommends the smallest defensible next step.

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.

Recording why we made a decision gives the next pass through the loop something to build on. A parked request has a reason to return. An accepted idea still has questions to answer. The record helps both the agent and the team recognize when new evidence warrants revisiting an earlier decision.

The instructions improve as I use the loop. When I find something missing in the agent's approach, I update the skill so the correction is available on the next run. This connects with what I wrote 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

As we improve how the loop carries out the work, we also need to ask whether the work still deserves doing. A team can become very efficient at advancing a project whose premise needs another look. An agent working from our existing plans may get good at fitting new evidence into them. The loop needs to bring forward feedback that challenges the direction of the work, so we can decide whether that direction still makes sense.

Monday's meeting is where we decide what should change. The loop brings together evidence for that discussion, including reasons to stop something. Some weeks we will continue as planned. Other weeks, new evidence may lead us to change the scope or make room for a different idea.

The same pattern applies wherever a team returns to a decision with new evidence. A sales team revisits an opportunity as it learns more about a buyer. An operations team adjusts a process as it sees where delays recur. In each case, identifying the loop gives us a way to examine where an agent could help: what starts the work, what context it needs, and what evidence should guide the next decision.

I am still learning how much of our product preparation an agent can carry well. But looking for loops has given me a practical starting point for finding useful work for AI. Find a decision the business keeps returning to, then examine the work required to make that decision better.