Field Notes
Loop engineering is the rung people reach after the other AI engineering layers start working.
Prompt engineering turns a vague request into a clear job.
Meta-prompting helps you discover the job when the request is still messy.
Context engineering gives the agent the right sources, examples, decisions, constraints, and current state.
Harness engineering gives the agent its operating environment: identity, tools, memory, permissions, routes, approval gates, and receipts.
Loop engineering takes all of that and turns it into repeatable motion.
The agent stops waiting for you to manually restart the work every time.
It can monitor a trigger, pull the right context, follow the right process, produce the output, check the output, escalate when needed, document what happened, and then do it again.
That is the part I care about.
Not AI as a one-off answer machine.
AI as a workflow engine that can serve the business while you are not sitting there manually pushing every step forward.
Take customer feedback.
In PricePulse, a customer can submit feedback. That feedback lands in an inbox.
The old version of that workflow is familiar: someone checks the inbox, opens the message, figures out who the customer is, decides whether it is a bug, feature request, billing issue, onboarding question, or support problem, then starts the next workflow by hand.
That works until the business gets busy.
Then the inbox becomes a waiting room for work that already has a defined path.
The loop version looks different.
A scheduled agent checks the inbox on a cadence.
It finds the feedback.
It pulls the contact and account context.
It classifies the issue.
Then, because the context layer is engineered, it knows where to look: product notes, customer history, known issues, pricing rules, support policies, current project state, and any source-of-truth files that matter.
Because the prompt and skills are packaged, it knows the process for that kind of issue.
Because the harness is engineered, it knows what tools it can use, what it can change, what it can only draft, what requires review, and what proof it owes back.
Then the loop runs.
It gathers the context.
It writes the receipt.
It drafts the response or prepares the fix.
It checks the work.
It decides whether this is safe to resolve automatically or whether it needs a human gate.
If the issue touches money, production behavior, customer-facing claims, or anything with real business risk, it brings the work back for review.
If the issue is inside the agent's approved lane, it can keep moving.
Then it closes the loop with the customer, updates the record, and saves the lesson so the next run gets better.
That is loop engineering.
It is process design for agents.
The point is to chain the right workflows together end to end, with the pathways and instructions defined before the agent starts improvising.
The more complete the pathway, the more useful the loop becomes.
You see it in customer service, inbox monitoring, onboarding, reporting, pricing recommendations, and QA.
The QA version is the one I ran into this week.
We were working through a PricePulse money-and-access update. The first AI pass made fixes. A review pass looked at the fixes. The system verified the work.
Then the loop kept going.
The next pass caught seven more real defects inside work that already looked done:
- a zero-dollar billing edge,
- an approval-flow break,
- a test-suite break,
- and four subscription / plan-state problems.
That is a review loop doing its job.
The goal was not "make one fix."
The goal was "keep reviewing and refining until the output reaches the bar."
That is a different operating model.
A weak AI workflow ends when the model gives you something that sounds good.
A stronger AI workflow ends when the loop produces evidence that the work is good enough to trust, or stops and tells you exactly why it is not ready.
That is the difference between using AI and operating agents.
Playbook
Here is the practical version.
If you want to engineer a loop, stop starting with the tool.
Start with the workflow.
1. Name the trigger
Every loop starts somewhere.
A customer submits feedback.
An email lands in a specific inbox.
A booking changes.
A pricing recommendation is due.
A test fails.
A draft needs review.
A transcript arrives.
A dashboard metric crosses a threshold.
The trigger matters because it decides when the agent wakes up.
If the trigger is fuzzy, the loop will be fuzzy.
2. Map the full path
Do not map only the AI task.
Map the business process.
For a support loop, the path might be:
- monitor inbox,
- identify customer,
- classify issue,
- pull account and product context,
- check known issues,
- decide the response lane,
- draft or prepare the fix,
- review for risk,
- escalate if needed,
- send or queue the customer response,
- update the record,
- save the lesson.
That is more than a prompt.
That is a workflow.
Once the workflow is visible, the agent can be assigned to specific parts of it.
3. Define the source route
The agent needs to know where truth lives.
For PricePulse feedback, it may need the email thread, the customer account, the support policy, the product roadmap, the known-issues list, the relevant code or product notes, and the current state of the release.
For QA, it may need the diff, the test output, the acceptance criteria, the prior bug report, the implementation notes, and the risk list.
Context engineering makes the sources usable.
Loop engineering tells the agent when to retrieve them and what to do with them.
4. Package the decision rules
A loop needs judgment boundaries.
Some work can be automatic.
Draft-only work needs approval.
A few categories should stop immediately.
Write those lanes down.
For example:
- Safe to auto-handle: acknowledge receipt, collect missing information, tag the issue, update an internal tracker.
- Needs review: customer-facing promises, refunds, production fixes, pricing recommendations, public claims.
- Stop immediately: conflicting source material, missing customer identity, unclear legal or financial impact, unknown data state.
Autonomy without lanes is just speed with a blindfold.
5. Build receipts into the loop
The loop should leave a trail.
The useful questions are plain:
- What triggered the loop?
- Which sources did the agent read?
- How did it classify the work?
- What changed?
- What stayed untouched?
- Which test or review passed?
- What still needs a human?
This is how you keep agents useful without turning them into mystery boxes.
The receipt is also how the next run gets smarter.
If the same issue shows up again, the system should not start from zero.
6. Add the review loop
Some loops are about execution.
Other loops are about refinement.
QA is the clean example.
The agent makes a change.
Another agent or model reviews it.
The system tests it.
The reviewer attacks the fix and the original bug.
Then the work goes back through the loop until it meets the standard or hits a stop sign.
That is how you turn AI speed into reliable output.
One pass gives you a draft.
A loop gives you a chance at quality.
7. Decide what closes the loop
A loop needs an ending condition.
"Looks good" is too weak.
Try stronger endings:
- customer response sent and logged,
- human approved the production change,
- all required tests passed,
- risk checklist cleared,
- no unresolved source conflicts,
- issue documented and routed,
- lesson added to the next run.
The ending condition is what keeps the loop from becoming noise.
It also tells the agent when to stop working.
Orientation
Loop engineering is how agent work becomes operational.
It takes the prompt, the context, the harness, the tools, the permissions, the sources, the review gates, and the receipts, then turns them into a repeatable cycle.
That is why it belongs after the earlier layers.
Bad prompts make bad loops.
Missing context makes confused loops.
A weak harness makes risky loops.
But once those layers are in place, the loop becomes the asset.
With those layers in place, an agent can check the inbox every few hours, route the right issue, draft the right response, prepare the right fix, stop at the right gate, and come back with evidence.
A QA process can run until the output improves instead of stopping at the first polished answer.
A customer journey can become something an agent helps operate end to end.
This is the part of AI that feels boring until it starts giving you time back.
Then it feels like the whole point.
Completing one AI task is useful.
A workflow that keeps serving the business is better.
The trigger stays clear.
The source route stays clear.
The decision lanes stay clear.
The proof standard stays clear.
The receipts improve each time.
That is how you get to useful 24/7 support from agents.
Start with one workflow you already understand.
Then you engineer the loop.
— Brian