Agent Loops Are Hot, but the Foundation Is Key: A 14-Step Roadmap from Single Agent to Self-Evolving System

Everyone’s talking about loops. Almost no one’s talking about what the loop runs on.

Nine out of ten developers use Claude Code without ever changing the default settings — no rules files, no sub-agents, no hooks, no memory.

Then they wonder why their loops produce nothing but garbage.

The truth is simple: A loop is only as good as the foundation it sits on.

This is the 14-step roadmap for foundation engineering — from a single agent to a self-evolving system.

Loops Are Trending, But Don’t Forget the Foundation

“Loop engineering” — building a system that wakes up an agent on a timer — has captured all the attention this month. But in his long post about loops, Addy Osmani specifically pointed out the layer below:

Loop engineering is one layer above foundation engineering. The foundation is the environment a single agent runs in. A loop is just a foundation, except with a timer, with the ability to spawn helpers, and to feed itself.

Foundation engineering is designing that environment: the model, the tools, the permissions, the context, the memory.

It’s the invisible layer — and yet the one that determines whether everything above it works at all. A brilliant loop on a rotten foundation has only one skill: mass-producing garbage.

14 Steps, Three Layers. The Bedrock of Everything.

Part 1 · What Is a Foundation

01 · A foundation is just the environment an agent runs in

Stripped of jargon, a foundation is four things: the model that does the work, the tools it can call, the permissions on those tools, and the context it reads when it starts.

That’s it. Everything else — sub-agents, hooks, memory — is just some shape you give to these four things.

02 · Same model, different foundations = completely different agents

The foundation defines what tools are available, what the agent can do, and what it knows at startup. Same model, different foundations = completely different agents.

Everything that shapes your agent lives in a single folder in your project root. Remember this structure, and you’ll be able to read anyone’s foundation at a glance:

03 · The line between a good foundation and a bad one

The dividing line between a good foundation and a bad one is one rule: Keep it lean enough that you can explain why every file exists. If you can’t explain why a rule, a hook, or a sub-agent is there, delete it.

Most problems that look like “my agent config is a mess” come from mixing up the three layers. Remember:

Practical version: Constants go in context, enforced rules go in hooks, operational flows go in skills, isolated tasks go in sub-agents.

Mix these up — shoving enforced rules into CLAUDE.md, letting operational flows bloat the context — and you get unstable agent behavior and sky-high costs.

04 · The default foundation: an empty shell

Install Claude Code, open a folder — you already have a foundation, just an empty shell. The defaults give you a capable model, built-in tools (read, write, bash, search), and manual confirmation for anything risky. No project context, no custom sub-agents, no memory.

For one-off tasks, the defaults are fine. But for anything you do repeatedly, the defaults mean the agent has to reverse-engineer your project from scratch every session, you have to approve safe operations, and it forgets everything the moment you close the terminal.

The next ten steps are about plugging those holes.

Part 2 · Building the Foundation

05 · CLAUDE.md: the agent’s permanent memory

CLAUDE.md is read at the start of every session. It’s the agent’s permanent knowledge of your project — conventions, architecture, the “we don’t do it this way because something blew up last time” stuff.

The most common mistake: turning it into a giant process document that drags a ton of context into every session.

The consensus among practitioners who run this daily: Keep the main memory file under 500 tokens. Fixed facts go here.

Multi-step flows go in skills (Step 8). Path-specific behavior goes in rules/, scoped to where it applies. If a paragraph in CLAUDE.md has moved from “fact” to “process,” it needs to move out.

Read your CLAUDE.md out loud. Each line should be a fact that the agent needs in every session (e.g., “We use pnpm, not npm”). If a line is a process (e.g., “To add a feature, first…”), move it to a skill.

If it’s a rule for a specific folder, move it to rules/.

06 · settings.json: permissions and model

The default foundation asks you about every risky operation. That’s fine while you’re watching, bad when you’re not. settings.json is where you pre-approve safe operations, block dangerous ones, and choose which model to run.

The criterion for deciding what to auto-approve: How hard is it to roll back if this goes wrong? Low rollback cost → auto-approve.

High rollback cost (force push, delete files, touch secrets) → always reject or at least prompt for confirmation. The middle ground can be auto-approve with logging.

07 · Sub-agents: isolate noise, protect the main context

Sub-agents are independent Claude sessions launched from your main session — with their own context window, their own tool list. The point isn’t parallelism itself; the point is keeping noise out of the main context.

A research task that needs to read 40 files, a review that needs a fresh perspective, an evaluation run that spews logs — these all belong in a sub-agent, not polluting the main thread.

The single most valuable sub-agent in any foundation is the one that checks the main agent’s work quality. A model reviewing its own output is far too forgiving.

An independent reviewer with a fresh context window catches blind spots the writer has convinced themselves of. This is the writer-reviewer split, making every loop on top of the foundation trustworthy.

08 · Skills: reusable instruction units

A skill is a SKILL.md file that the agent executes — manually via /skill-name, or automatically triggered when a task description matches.

Unlike sub-agents, skills run inside the same context window. They’re just reusable sets of instructions that become part of the current session.

When to create a skill: When you find yourself pasting the same set of instructions every time you start a new conversation. That’s a skill waiting to be born. PR checklists, evaluation flows, deployment processes — write once, call forever.

And because skills are reusable units, they’re the key to a foundation evolving over time: every time a process fails in a new way, you add the lesson to the skill, and the next run inherits it automatically.

09 · Hooks: enforcement, not suggestions

Everything so far relies on the model understanding your instructions. Hooks don’t.

A hook is a shell command that executes at a fixed point in the agent’s lifecycle — before tool calls, after file changes, at session end — and its exit code can directly block an operation. Hooks are enforcement. CLAUDE.md is just a suggestion.

Almost every foundation should have two hooks:

Hooks are for things that must happen or must never happen — safety, formatting, audit logs.

Don’t use hooks for judgment calls; that’s what the model is for. A good foundation has one or two sharp hooks, not twenty.

10 · Loops: making the foundation run itself

A configured foundation still waits for you to type. A loop makes it run itself. The simplest version is Claude Code’s /loop — a prompt that repeats on a rhythm.

Paired with /goal, the loop keeps running until an objective condition is met — and judged by an independent scorer, not the agent grading itself.

Notice what just happened: the loop didn’t add intelligence out of thin air. It reused everything in the foundation — the rules, the review sub-agent, the safety hooks. A good foundation makes the loop trivial. That’s the whole point of building the foundation first.

11 · Dynamic workflows: orchestrating sub-agents and skills

For tasks a single loop can’t handle — heavy parallelism, high structure, adversarial validation — Claude can write its own JavaScript orchestration on the fly.

This is dynamic workflow: agent() spawns a sub-agent, parallel() fans out, pipeline() chains them. It combines the sub-agents you defined in your foundation into patterns like fan-out-then-aggregate, adversarial validation, etc.

The connection to foundation engineering: A dynamic workflow is only as good as the sub-agents and skills it can call.

If your foundation has a sharp review sub-agent and a well-written evaluation skill, the workflow has good parts to orchestrate. An empty foundation gives the workflow nothing to work with.

The workflow is the conductor. Your foundation is the orchestra.

Part 3 · Self-Evolution

12 · State files: the foundation doesn’t forget

This step turns a configured foundation into a system that truly evolves.

The agent forgets everything between runs. The foundation doesn’t have to.

A state file — a markdown file in agent-memory/, or a Linear kanban — records what was tried, what worked, what broke, and what rules survived testing.

The pattern that makes memory snowball comes from the strongest agent practitioners:

13 · The self-evolution loop

At this point, the three layers finally click together into something that can evolve itself.

Each run produces output. The review sub-agent (Step 7) checks it.

The results — what passed, what failed, what was learned — are written into memory (Step 12). General lessons are distilled into skills (Step 8).

The next run inherits sharper skills and richer memory.

This is the complete self-evolution cycle. Notice that every piece comes from the foundation:

The model never changes. The foundation around it gets sharper. That’s the honest meaning of “self-evolution” — not the model learning, but the foundation accumulating.

14 · Packaging as plugins: from personal config to shared infrastructure

A foundation that works on one project is an asset.

Package your skills, sub-agents, and rules as plugins, and the whole team can install the same config with one step — the same conventions, the same safety hooks, the same reviewer.

The foundation is no longer your personal config. It’s shared infrastructure.

Summary

First, get a single manual run stable on a clean foundation. Add context and permissions. Add a review sub-agent. Add memory. Then, and only then, wrap a loop around it.

A loop on a good foundation snowballs. A loop on a rotten foundation just accelerates the bleeding.

The loop gets the spotlight. The foundation does the work in the background.

Loop engineering is the exciting part — agents waking themselves up, running while you sleep. But a loop is just a foundation with a timer.

Everything that decides whether the output is excellent or garbage lives in the layer below: the model you chose, the tools you approved, the context you wrote, the reviewers you added, the memory you retained.

Build this layer well, and everything above snowballs: loops reuse your sub-agents, workflows orchestrate your skills, memory makes every run sharper than the last.

Self-evolution was never a property of the model. It is a property of the foundation you build around it.

Pick one thing from the list you haven’t done yet — probably the review sub-agent, the safety hooks, or the state file — and add it today. Keep the foundation lean enough that you can explain it. Then wrap a loop around it, and watch the foundation do the work for you.

Original reference: https://movez.substack.com/p/harness-engineering-with-claude-14?utm_source=substack&publication_id=9020837&post_id=202282465&utm_medium=email&utm_content=share&utm_campaign=email-share&triggerShare=true&isFreemail=true&r=7r2akf&triedRedirect=true