Give AI Work / builder guide / 10 progressive labs

Loop Engineering

Stop being the person who repeatedly types “continue.” Engineer when the work starts, how it knows progress is real, when it retries, when it stops and when it asks for help.

Give AI WorkLoop EngineeringBuilder guide

Hands-on Give AI Work builder guide

What you'll learn

Turn one reliable delegated AI responsibility into a controlled loop with explicit triggers, persistent state, verification, stop rules, recovery and budgets.

Bring / required

One workflow that already works reasonably well as a single run. Harness Engineering is strongly recommended first.

What you'll do

Map where you are still manually prompting the next step, then remove only the human repetition that can be encoded safely.

Take away

A loop contract, work queue, maker-checker flow, recovery policy, isolation plan, budget and an autonomous capstone you can stop and explain.

Use the shared Field Guide Lab Method. Loop autonomy should be measured by evidence, human intervention and safe stopping—not by how long it runs.

The uncomfortable first question

You may be thinking: “My agent is already autonomous because it can call tools and complete a multi-step task.”

Now watch what happens after it finishes. If you read the result, decide what comes next and type the next instruction, you are still the loop.

Aha

Loop Engineering is not “make the agent run forever.” It is moving repeated orchestration decisions out of your head and into an explicit runtime contract: trigger → state → act → verify → continue / stop / escalate.

Common traps

“Keep going until done.” No machine-checkable definition of done, budget or blocker state.
Timer abuse. A cumulative task is restarted every 10 minutes even though each run needs the previous run’s state.
Retry theatre. The same instruction is run again without changing evidence, input, state or strategy.
Self-feeding chaos. The loop discovers its own tasks but has no priority, claim/lease or scope boundary.
Infinite helpfulness. The agent keeps doing “useful” work after the requested responsibility is already complete.

Look out for

You are still manually pressing Continue or choosing the next item.
The loop cannot explain why it is allowed another retry.
Two workers can claim the same task.
Parallel workers share files or external state with no isolation.
Cost, token use or human review grows faster than useful completed work.
The loop can stop on success but not on uncertainty, budget exhaustion or authority boundary.

Prove the first lesson

Take one current workflow and mark every place where a human starts, selects, verifies, retries, stops or escalates the work. Your loop design is not ready until you can say which of those decisions remains human intentionally and which becomes an explicit system rule.

Four trigger types people mix up

Type	Use it when	Common mistake
Finite goal	There is a finish line and progress accumulates.	Running it on a timer and restarting from scratch.
Scheduled	A bounded check/action repeats independently.	Letting state leak between runs accidentally.
Event-driven	An external event should start bounded work.	Accepting every event without dedupe or authority checks.
Work queue	The system should discover and consume durable tasks.	No claim/lease, priority or blocked state.

Aha

“Repeats” does not tell you what kind of loop you have. The time model and state model do.

Inside the loop vs. outside the loop

Usually inside the loop	Usually outside the loop
Choose an eligible queue item	Change the goal
Take a bounded action already authorised	Increase its own authority
Retry within an explicit policy	Redefine what counts as success
Stop on verified completion	Increase retry/time/cost budgets
Escalate with evidence	Approve high-impact or irreversible actions

Aha

Autonomy means the loop controls execution inside a contract. It does not get to rewrite the contract.

Progressive labs

REMOVE YOURSELF ONE DECISION AT A TIME.

Do not automate the whole workflow in one jump. Encode one repeated human decision, observe it, then earn the next layer.

L01FIND THE LOOP

Find where you are still the runtime

Record every manual start, next-step choice, verification and retry decision.

Aha: tool use is not autonomy.

Keep: manual-intervention map

L02STOP

Goal + verify + stop

Define end state, proof, blocker, budget and escalation before letting the system continue itself.

Trap: “until done.”

Keep: loop contract

L03TRIGGER

Choose the right trigger

Finite goal, schedule, event or queue. Match the trigger to the work’s time and state model.

Trap: timer abuse.

Keep: trigger decision table

L04QUEUE

Externalise the next work item

Use durable queue/state so the next run discovers work without chat history.

Look out: duplicate claims.

Keep: loop work queue

L05CHECK

Make maker-checker a real loop

Connect maker → verifier → accept / repair / escalate with actual checker authority.

Trap: reviewer gives advice but cannot reject.

Keep: maker-checker state machine

L06RECOVER

Retry only when something changes

Require new evidence, changed state/strategy and a retry budget.

Aha: retry is not recovery.

Keep: retry/recovery policy

L07ISOLATE

Make parallel work physically safer

Use worktrees, branches, sandboxes, leases or separate records when workers can collide.

Look out: shared writes.

Keep: isolation policy

L08CAPABILITIES

Add skills, connectors and sub-agents deliberately

Only add a capability when it has a distinct responsibility, context or external-system boundary.

Trap: agent multiplication.

Keep: loop capability map

L09BUDGET

Budget the silent costs

Watch verification debt, comprehension rot, cognitive surrender, token/tool-cost blowout, review bandwidth and low-value retries.

Aha: automation often moves the bottleneck from generation into judgment.

Keep: loop budget + review thresholds

Loop maturity ladder

This is a progression of coordination complexity, not a badge system. Do not jump upward to hide a broken lower layer.

Manual repeated run — human starts and steers every cycle.
Goal loop — one verifiable finish line.
Scheduled / event loop — bounded repeated trigger.
Maker-checker loop — independent verification and repair.
Self-feeding queue — durable work discovery.
Multiple isolated workers — concurrency with separation.
Graph/system coordination — several responsibilities with routing, shared state and authority relationships.

Rule

If one delegated run is unreliable, more autonomous workers usually multiply the failure rather than fix it.

L10CAPSTONE

Leave the keyboard

Run success, missing-information, repeated-failure and budget-exhaustion cases without manually steering each iteration.

Prove: every stop or escalation is explainable.

Keep: loop starter pack

A minimal loop contract

Trigger:
  new eligible item appears in queue

Goal:
  produce one verified response draft

Continue only if:
  required context is present
  authority remains within contract
  retry budget remains

Verify:
  schema valid
  source facts present
  policy checks pass

Stop:
  verified output produced

Escalate:
  missing authority
  conflicting source
  repeated verification failure
  budget exhausted

Next tension

You can now run one responsibility without manually prompting every step. The next problem is not “how do I add more agents?” It is what happens when several loops share state, compete for goals, need to veto each other or must be operated as one system. That is where Run AI and Graph Engineering begin.

Back to Give AI Work → · Continue to Run AI →