wtf is Loop Engineer & how to setup for real

At around 1:00 AM yesterday, a bunch of PRs started landing in our codebase. Not because our team was working unusually late.

They came from different agent loops: agents finding issues, picking up work, verifying changes, and opening PRs without someone manually prompting each one.

We also have an SEO loop that produces 20–40 high-quality pages every day at @SuperDesignDev . Those pages are already driving traffic to the company without me looking at it.

This is the shift I want to talk about: loop engineering:

Stop treating agents as something you prompt manually, and start designing systems that can decide what to work on, execute, verify results, and improve over time.

A good loop does not just generate output. It creates a feedback system that gets more useful as it runs.

I want explains how we set things up in a way that compound

An agent harness has two nested layers

The term “agent harness” can feel vague because it covers almost everything that is not the model itself.

But I find it useful to split it into two layers: agent loop + outer loop.

1. The agent loop: help an agent complete a given task well

The inner loop is the familiar agent runtime; Claude code, codex, etc.

You give an agent a task. It reads the relevant context, uses tools, performs work, checks the result, and continues until the task is complete. This is where most agent optimisation happens today: Better context and instructions, Skills and tool definitions, Task decomposition, Tool use

The question this layer tries to answer is:

Given this task, how can we help the agent complete it reliably?

But it still depends on somebody deciding that this is the task worth doing. That is where the outer loop comes in.

2. The outer loop: decide what should happen next

The outer loop sits around the agent runtime. It is responsible for things like:

• What should trigger the agent

• What state should be preserved across sessions

• How different agents share information

• How outcomes are monitored

• How the system gets better over time

The question this layer tries to answer is:

What should the agent work on next, and how can the system learn from the result?

This is the part where we call loop engineering. A loop engineer is not just writing prompts for an agent. They are designing an environment where agents can continuously:

• Notice something worth working on

• Investigate it

• Take action

• Record what happened

• Verify whether it worked

• Use that result to decide what to do next

The agent loop helps an agent execute. The outer loop helps the system decide, learn, and compound.

Loops compound when they share artifacts & logs

One useful loop is great. But the really interesting part starts when multiple loops can learn from each other.

At our company, we have loops across areas like: Support, SEO, Product growth, Ads. Each of these loops has its own trigger, workflow, tools, and goals.

But they write to a shared artifact system.

For example, the support loop might notice that five people have asked how to export something.

It creates a signal: /export-too-hidden.md

At the same time, the SEO loop might notice that a page is getting strong traffic but poor conversion.

It creates another signal: /conversion-gap-ai-wireframe-generator.md

Then the product-growth loop can read both signals alongside product analytics. It might conclude that export is a bigger issue than the original analytics data suggested. Or it might identify that people arriving through a particular SEO page are hitting the same product friction that support is seeing.

The ads loop may discover that a keyword has a strong click-through rate but no supporting organic content. That can feed directly into the SEO loop.

This is what makes the system compound. The loops are no longer isolated automations.

They are operating from a shared Knowledge base of what the business is learning.

The shared log (Brian)

The artifact system is the shared memory layer that makes loops compound. I normally separate it into three parts, For example:

1. Artifacts

Artifacts are durable pieces of work or knowledge. They are the objects that loops read and write. Examples include signals, docs.

Each artifact type should have:

• A clear definition what is and is NOT this type

• Consistent schema

• Lifecycle rules

For example, a signal is not just a random note. It is a structured record of something worth paying attention to.

The useful thing about artifacts is that they are not trapped inside one agent session. Any loop can read, update, link to, or act on them later.

2. Loop contracts

Every loop should have a contract. This is usually a README inside that loop’s domain folder.

For example: support-loop/README.md. The contract explains:

• The goal of the loop

• The workflow it should follow

• Backlog queue

• A timeline of important events

For example:

Every new agent session can read this contract and understand what the loop is trying to achieve.

3. Global logs

Finally, keep a global LOGS.md or work log.

This is useful because work is not always neatly contained within a single loop. You might manually investigate an idea, review an agent’s output, make a decision, and ask another agent to act on it. The global log captures that cross-domain context.

A simple pattern works well:

• Before major work, agents read the latest five to ten entries.

• After major work, agents add a concise summary.

• Entries should link to relevant artifacts.

For example:

This gives every loop a lightweight way to understand what has been happening across the business.

Let AI run business

At @SuperDesignDev our team is setting up a network of loops to scale the business in full AI native way. Together, they form an operating system for continuous improvement.

That is loop engineering.

And the teams that get good at it will not just move faster because they use agents. They will compound faster because their systems learn while they sleep.

I have put together a Loop Engineer Setup template that captures many of the practices we tried: artifact structures, loop contracts, logs, skills, and a codebase harness checklist.

You can copy it into your own repository and use Claude Code or Codex to scaffold your first loop: https://github.com/JayZeeDesign/loop-engineer-template

We will continusly share our experiments on running @SuperDesignDev AI natively, follow up if you interested