The Full Anatomy of a Loop, and How to Build One in Under Ten Minutes

By John O'Connell Article, Peaks Perspective Agentic AI, AI, Practice Management

A loop has five parts. Skip one and you do not get a slower loop. You get a system that burns tokens on a dead end, or one that silently produces the wrong answer with total confidence. Understanding what each part does, and then building one yourself, takes less time than most firms spend debating whether to start.

The Five Parts

A testable goal. Every loop starts here, and most bad loops start here too. “Improve the client review process” is not a goal an agent can act on, because nothing tells it when the improvement is sufficient. “Flag every client account with a stale risk questionnaire and draft an outreach email for advisor review” is a goal, because it has a condition the system can check: either every stale account has been flagged with a drafted email, or it has not.¹ Vague goals produce loops that either stop too early or run indefinitely, guessing at what “done” means. Specific goals give the loop something to test itself against.

Tools that touch the real environment. A loop that can only describe what it would do is not a loop, it is a suggestion. For a wealth management firm, tools mean the systems your agent can actually reach: the CRM, the portfolio management platform, the document repository, a connector into your compliance archive. Without that access, the loop can identify a problem but cannot act on it, and every action still routes back through a human doing the actual work by hand.²

A spine. This is the part firms skip most often, and it is the part that prevents the loop from repeating its own mistakes. A spine is persistent state, something outside the single conversation that records what has been tried, what worked, and what is still open. It can be as simple as a markdown file or a shared tracker.³ The model forgets what happened between runs; the record does not. Without a spine, a loop that runs overnight wakes up every cycle with no memory of what it already attempted, which means it can retry the same failed approach indefinitely without ever recognizing the pattern.

Termination logic. Without an explicit stopping condition, a loop either runs forever or stops at an arbitrary point that has nothing to do with whether the work is actually done.⁴ Termination logic needs layers: a verifier that confirms the actual goal has been met, a hard cap on the number of cycles regardless of outcome, and a budget on tokens or time. Worth building alongside those layers: a check for stalled progress. If the last several cycles produced the same result or left the state unchanged, the loop should stop and escalate to a person rather than continue consuming resources chasing a dead end.

Verification that separates the maker from the checker. The agent that produced a result is a poor judge of whether that result is correct, for the same reason a person is a poor editor of their own first draft. The strongest loops assign a separate step, sometimes a separate model, to check the work against the original goal before the loop calls itself done.⁵ For anything touching a client account, a disclosure, or a supervisory record, that checking step is not optional. It is where your firm’s human-in-the-loop obligation actually lives inside the architecture, rather than existing only as a policy document nobody consults.

Why the Order Matters

These five parts are not independent settings you configure once. They depend on each other. A precise goal is worthless without a spine to track progress against it. A spine is worthless without termination logic to know when the tracked progress is sufficient. Termination logic is worthless without a verification step that confirms the tracked progress is actually correct and not merely present. Build the parts in this order, and each one gives the next something real to check against. Build them out of order, and you end up with a system that runs, produces output, and cannot tell you whether that output is right.

Building One in Under Ten Minutes

Pick a task narrow enough to finish reading about before you lose patience. A useful first loop for a wealth management back office: reconcile new account documents against a checklist and flag exceptions.

Minute one: write the goal. Not “review new accounts,” but “confirm every new account opened this week has a complete document set against the firm’s checklist, and produce a list of accounts with missing items.” That sentence alone is most of the design work. If you cannot state a condition that tells the loop it is finished, stop and rewrite the goal before touching anything else.

Minutes two through four: connect the tools. Give the agent read access to the document repository and the account-opening checklist. Nothing more. A narrow tool set is a feature in a first loop, not a limitation. The fewer systems the loop can touch, the easier it is to trust what it did.

Minutes five and six: set up the spine. A single shared document or tracker where the loop logs each account it checked, what it found, and what remains open. This is also where a human picks up the thread the next morning without re-reading every account from scratch.

Minutes seven and eight: define termination. The loop stops when every account opened in the target window has been checked and logged, full stop. Add a hard cap, say fifty accounts per run, so a data problem elsewhere cannot turn a reconciliation task into a runaway process.

Minutes nine and ten: add the check. A second pass, ideally a separate step in the loop, confirms that every account marked complete actually has every required document present, rather than trusting the first pass’s own report. Route anything flagged as an exception to a person. Nothing gets marked resolved without a human confirming it.

Ten minutes produces a working loop, not a finished one. You will tighten the goal wording after the first run surfaces an edge case you did not anticipate, and you should expect to. The point of building fast is that the first version teaches you exactly where your real requirements live, which is faster than trying to anticipate every one of them before you have run anything at all.

What This Replaces

Before this loop existed, reconciling new account documents meant an operations analyst working through a list by hand, checking each file against a checklist, and flagging gaps as they found them. That work still happens. What changes is who does the checking on the first pass, and where the analyst’s time goes: reviewing the flagged exceptions the loop surfaced, rather than reading every complete file to confirm it was, in fact, complete.

That reallocation is the actual value of loop engineering for a wealth management operation. It is not that the loop replaces judgment. It is that the loop absorbs the repetitive verification work that consumed the time judgment needed, and hands back exactly the cases where judgment is the scarce resource worth spending.