Loop Engineering Turns Agents Into Products

Most AI products should not be designed as one big prompt.

They should be designed as loops.

A loop has a goal, reads state, plans the next step, acts through tools, verifies the result, decides what to do next, and either continues or stops.

If you are newer to coding agents, start with From Copilot to Agentic Engineer. This essay is the next step: how to turn that pattern into product architecture.

A prompt gives an answer. A loop pursues an outcome.

A prompt says, “Find tax-loss harvesting opportunities.”

A loop says, “Ingest transactions, rebuild lots, identify losses, check wash-sale risk, estimate usefulness, produce a reviewed report, and stop when confidence is too low.”

That difference matters.

Real products deal with messy data, missing context, user intent, tool failures, permissions, and risk. A single model response cannot responsibly handle all of that. A loop can break the work into steps and check progress along the way.

The smallest useful loop

The basic shape is simple:

Goal → State → Plan → Act → Verify → Decide → Repeat

Goal defines what the system is trying to finish.

State is what the system knows right now.

Plan chooses the next useful step.

Act calls a tool, reads a file, writes data, or asks a question.

Verify checks whether the action worked.

Decide chooses whether to continue, retry, escalate, or stop.

The magic is not in the words. The magic is in making the cycle explicit.

Start with state, not agents

Many teams start by naming agents: intake agent, reviewer agent, planner agent, research agent.

I would start with state.

In a tax-loss harvesting copilot, state includes accounts, transactions, lots, cost basis, acquisition dates, gains, losses, wash-sale windows, recurring buys, dividends, assumptions, recommendations, review flags, and an audit trail.

Without state, every model call starts from scratch. With state, the workflow can know what is missing, what is trusted, and what should happen next.

That is the first product design move.

Let code own the truth

The model should not calculate everything.

For a financial workflow, deterministic code should reconstruct lots, calculate basis, classify holding periods, detect duplicates, fetch prices, and total gains or losses.

The model is better around the edges: interpreting messy exports, explaining ambiguous records, drafting user-facing summaries, and asking review questions.

That division keeps the product sane. The LLM can help with interpretation. The system should own the truth.

This also connects to Your AI Product Needs a Model Exit Plan. If a workflow depends on one model behaving perfectly forever, the architecture is too fragile.

Verification is the product

Most AI demos stop after generation.

Real products need verification.

For a tax-loss harvesting copilot, verification might mean checking totals against source files, flagging incomplete account data, testing wash-sale windows, comparing current holdings to reconstructed lots, and marking low-confidence recommendations for human review.

The product should not pretend uncertainty is confidence. It should expose uncertainty in a useful way.

Good loops do not only produce answers. They produce reviewed decision packets.

Know when to stop

A loop without a stop condition becomes a wandering agent.

Good stop conditions are boring and specific:

• all accounts analyzed
• required data is missing
• confidence is too low
• risk is high
• user approval is needed
• the recommendation is ready for review

Stopping is not failure. Stopping is part of product safety.

Why this matters

Loop engineering is the bridge between “AI can do this once” and “AI can support this workflow repeatedly.”

It is also the technical version of the field learning loop in Forward Deployed Engineering as a GTM Motion: observe reality, act, verify, learn, and productize what repeats.

The future AI product will not be the longest prompt. It will be the clearest loop.