AI LABS · 34.5K views · 13 min

Don't prompt your agents — design loops that prompt themselves

Loop engineering shifts the focus from crafting instructions to designing self-driving systems where the agent prompts itself, corrects its own work, and runs autonomously. The real unlock: running those loops on an always-on agent like Hermes.

youtube.com/watch?v=AQRDjI5owZI

LOOP.
CTX
FB
CHK
FIX
01 · The shift

From prompt engineering to loop engineering

Instead of crafting instructions yourself, you design a system that does the prompt engineering for you. The agent defines its own steps, checks its own output, and iterates until complete.

0
Manual prompts needed
Self-correction iterations
10×
Agent productivity multiplier

Peter Steinberger (OpenClaw) and Boris (Claude Code) both made the same claim — they don't prompt Claude anymore. Loops do it for them. The human sets the goal and the constraints; the loop handles the iteration.

02 · Loop anatomy

Five parts every loop needs

A loop without these components will either spin forever, quit prematurely, or degrade under its own context weight. Here's the minimum viable loop.

🧠

Context Management

Keep important instructions from getting buried under tool outputs.

📊

Feedback Quality

Test runs, screenshots as signal — garbage in, garbage out.

🚧

Verification Gates

Clear checkpoints that must pass before the loop proceeds.

🏁

Termination Condition

Explicit rules so the agent doesn't quit too early or loop forever.

💾

State Across Turns

External files to track progress as context grows beyond limits.

03 · Two types of loops

Deterministic vs. non-deterministic

Not all loops are created equal. The loop design depends entirely on whether "done" is a binary state or a subjective judgment.

Deterministic

Clear "done" condition

For tasks where success is objectively measurable.

  • Tests passing — all green, loop exits
  • Code compiling — zero errors, loop exits
  • Type checks clean — no violations
  • Lint passing — no warnings

Simple, cheap, and reliable. Point the agent at your test suite and let it fix failures.

Non-deterministic

Subjective judgment calls

For tasks where "good" is in the eye of the beholder.

  • Building a UI — aesthetics aren't binary
  • Feature design — multiple valid approaches
  • Architecture decisions — tradeoffs, not pass/fail
  • Creative work — requires a separate verifier

Needs a separate verifier model to judge quality. More expensive but unlocks subjective autonomy.

04 · The killer pattern

Non-deterministic adversarial loops

The most powerful loop design uses two different models in an adversarial setup. One builds, one verifies, and the loop runs until the verifier is satisfied.

Builder Claude models
output
Verifier GPT models
feedback

The builder's outputs get checked by the verifier. The loop runs until the verifier is satisfied. Hermes self-evolving skills let the verifier get stronger every time you spot something it missed.

Why different models?

Using the same model to build and verify creates blind spots. Cross-model verification catches failures that the builder's own biases would miss. Claude is great at generation; GPT is great at evaluation. Using both exploits their complementary strengths.

05 · Why Hermes

The right host for always-on loops

Loops need a host that never sleeps. Hermes is always-on — it can watch your deployed app, catch commits that break production, and fix issues without you stepping in.

How it works in practice

  1. Point Hermes at a deployed app
  2. It catches commits that break production
  3. Launches Claude Code in non-interactive mode
  4. Fixes issues in a loop until every test passes
  5. Zero human intervention required

Always-on advantage

Unlike a human who sleeps, Hermes runs loops 24/7. Production incidents at 3 AM? The loop is already fixing them before you wake up.

Self-evolving skills

Every time you spot something the verifier missed, you update the skill. The verifier gets stronger over time, reducing the need for human oversight.

06 · Notable points

What else stood out

07 · Takeaway

Design loops, not prompts

For deterministic work, point an always-on agent at your tests and let it fix failures autonomously. For subjective work, pair a builder model with a separate verifier model in an adversarial loop and let the verifier evolve over time.