Addy Osmani's 5 Building Blocks of Loops

When a new practice goes mainstream, it usually arrives as a pile of clever tricks before anyone organizes it into a framework. Loop engineering followed that exact arc through the first half of 2026. One of the contributions that gave the discourse a backbone came from Addy Osmani, who wrote about self-improving agents in terms of a small set of composable building blocks plus memory — a structure rather than a grab-bag.

The value of his framing is not that any single block is novel. It is that laying the blocks out side by side makes it obvious what most people's loops are missing. The majority of failed agent loops fail because a builder implemented two or three of the blocks and assumed the rest would take care of themselves. This article walks through the building-blocks-plus-memory model and maps each piece to something you can actually wire up.

This piece reflects public discussion across X and engineering blogs as of June 2026; verify primary sources before relying on specifics.

Key Takeaways

• Osmani frames self-improving agents as a handful of building blocks plus memory — see his write-ups on self-improving agents and loop engineering for the canonical versions.
• The blocks are composable, not optional — most broken loops implement some of them and skip the rest, which is why they loop forever or stall.
• Memory is the block that turns a loop into a learning loop — without it, every iteration repeats the last one's mistakes.
• The framework is tool-agnostic — it maps cleanly onto Claude Code's /loop, /goal, /schedule primitives or a plain Ralph loop.
• A complete loop has all the blocks wired together — the gaps between them are where agents go wrong.

Why a framework beat a list of tricks

Before Osmani's framing, advice about agent loops tended to read like a tips column: "use a max-iterations cap," "check the tests between runs," "give it a clear goal." All true, all useful, and all impossible to reason about as a system because they were listed rather than related.

A framework does something a list cannot: it tells you when you are done. Once the building blocks are named and you can see how they connect, an incomplete loop becomes visibly incomplete. You can point at the missing block. That diagnostic power is the whole reason frameworks matter, and it is why this framing spread alongside the June 2026 loop-engineering discourse.

The building blocks, mapped to practice

Osmani's model centers on a set of capabilities an agent needs to improve itself over iterations, with memory tying them together. Here is how the pieces map to concrete loop components. (The exact taxonomy is his; the practical mapping below is ours — read the source for his precise framing.)

Those five blocks are the loop itself. The first three describe an ordinary loop: set a goal, act, observe. That is enough to make an agent iterate. It is not enough to make it improve — that comes from the last two, reflection and adjustment. Tying all five together is the sixth piece Osmani calls out separately: memory. Memory is the line between a loop that retries and a loop that learns, and we go deep on that distinction in Self-Improving Agents: Loops That Learn.

What is the role of memory specifically?

Memory is the block people skip most often, and skipping it is precisely why their agents feel like they have goldfish brains.

Without memory, every iteration is a fresh attempt that knows nothing about the previous one's failure. The agent tries approach A, it fails, the loop restarts, and the agent — having forgotten — tries approach A again. This is the classic infinite loop failure mode, and it is maddening because the agent is not stupid; it is amnesiac.

Memory breaks the cycle by carrying lessons forward. The form it takes varies: it might be a LEARNINGS.md file the agent appends to and re-reads, an amendment written into the spec ("note: approach A does not work because X"), or a structured scratchpad. What matters is that the next iteration starts knowing something the previous one had to discover the hard way.

There is a subtlety here that connects to the Ralph technique. Ralph deliberately throws away the conversation context each iteration — but it keeps the repo and the spec. Memory in Osmani's sense lives in those durable artifacts, not in the chat history. Fresh context plus persistent memory is the sweet spot: the agent forgets the noise but remembers the lessons.

Wiring the blocks together

A complete loop connects every block into a cycle. In a Claude Code workflow that might look like:

/goal  -> spec.md defines the objective and success check
/loop  -> agent reads spec + LEARNINGS.md (memory)
       -> agent acts (edits, commits)
       -> check command runs (observation)
       -> if fail: agent reflects, appends a lesson to LEARNINGS.md
       -> next iteration starts with the lesson in context
       -> stop when check passes OR max iterations hit

The build-until-green and coverage-until-threshold skills are good examples of loops where the observation block (does it build? is coverage above the threshold?) is unambiguous and machine-checkable. That is what makes them safe to automate — there is no fuzzy human judgment in the observe step.

The blocks where loops most commonly break are observation and reflection. A weak observation block — an exit condition the agent can game — lets a broken loop declare victory, which we cover in Exit Conditions: The Heart of Every Loop. A missing reflection block leaves the agent unable to learn from feedback even when it gets clear signal.

Frequently Asked Questions

What are Addy Osmani's building blocks of self-improving agents?

He frames self-improving agents as a small set of composable building blocks plus memory — broadly: a goal, an action, an observation/feedback step, reflection, adjustment, and persistent memory tying them together. Read his self-improving agents post for his exact framing rather than relying on summaries.

Why is memory called out separately from the other blocks?

Because it is what turns iteration into improvement. The other blocks let an agent retry; memory lets the next attempt know what the last one learned. Without it, the agent repeats the same failure indefinitely.

Does this framework require a specific tool?

No. It is tool-agnostic. The blocks map onto Claude Code's /loop, /goal, /schedule primitives, a plain Ralph loop, or any agent runner. The framework describes the shape of a good loop, not the implementation.

How is this different from just running an agent in a loop?

A plain loop covers goal, action, and observation. Osmani's full model adds reflection, adjustment, and memory — the blocks that make the loop self-improving rather than merely repetitive. Most failed loops stop at the first three.

Where do loops most commonly break in this framework?

In the observation block (a weak, gameable exit condition) and the reflection block (the agent gets feedback but never reasons about it). Strengthen those two and most loop problems disappear.

Browse 150+ ready-to-run agent loops in the Loops channel, or explore the full skill catalog at aiskill.market.