GPT88 / API Docs

What Is Loop Engineering? The Layer After the Harness

A practical explanation of Prompt, Context, Harness, and Loop, with a controlled workflow for turning agent execution into a verifiable recurring system.

Source and scope

The source was extracted from a public X article through its article data rather than guessed from a truncated web view. The article discusses how intensive AI users move from prompt design to context engineering, then to a harness, and finally to a loop that can schedule, verify, and accumulate work.

From prompts to loops

A better prompt improves one execution. A harness gives an agent tools, permissions, files, and a working environment. A loop adds repeated scheduling, external state, checks, progress decisions, and a stop condition. The engineering problem therefore moves from wording one request to designing a system that can continue without silently drifting.

Prompt, Context, Harness, Loop

  1. Prompt: the immediate instruction and expected response.
  2. Context: the evidence, files, decisions, constraints, and current state.
  3. Harness: tools, permissions, runtime, skills, and workflow boundaries.
  4. Loop: triggers, external state, checkers, progress rules, retries, and stopping conditions.

A loop sits above the harness because it decides when to run, what state to read, how to judge the result, and whether another iteration is justified.

Minimum viable loop

  • A concrete goal and an observable completion condition.
  • External state such as a worklog, database row, file, issue, or build artifact.
  • A maker that changes the artifact and a checker that evaluates it.
  • A bounded iteration count, budget, timeout, and no-progress detector.
  • A stop path for success, failure, intervention, and repeated uncertainty.

Designing a controlled loop

  1. Define the state machine before adding a scheduler.
  2. Make each iteration produce a small, inspectable artifact.
  3. Keep maker and checker responsibilities separate.
  4. Record decisions, evidence, errors, and next actions outside the chat context.
  5. Retry only when the failure is actionable; stop on repeated no-progress.
  6. Add triggers last, after completion and checking are reliable.

A trigger without a checker, external state, and a stop condition only turns an unreliable one-shot task into an unreliable recurring task.

Why Skills compound

Repeated directory rules, build order, SEO checks, image naming, and release steps should become Skills, scripts, or fixed workflows. That converts experience into a reusable capability instead of paying the explanation cost again in every session.

The correct adoption order

  1. Stabilise one manual task with a clear acceptance check.
  2. Extract the repeatable instructions into a Skill or template.
  3. Write state and evidence to a durable worklog or artifact.
  4. Add an independent checker and recovery path.
  5. Only then add parallel work, scheduling, and automation.

Real risks

  • The loop can retry forever.
  • Each iteration can make context larger until noise overwhelms signal.
  • A small first-round error can propagate through many later rounds.
  • The checker can become decorative self-evaluation by the same maker.
  • People may stop observing the system because it appears to be running.
  • Repeated agent execution can cost more than the original code or content task.

Implications for Codex users