8/8/2026↻ Updated 10/6/2026

Loop engineering: your AI agent needs a safe loop, not another prompt

Vývojář pracující s AI agentem vedle tabule se smyčkou objevování, provedení, ověření a review

Update October 6, 2026: evaluate the agent that builds other agents

Anthropic’s October 5 case study describes Cresta Conductor on the Claude Agent SDK. Cresta evaluates the artifact, execution path, quality and resource use. The product was announced on June 11; the new development is this case study, not an October product launch.

For a business team, I would turn that into a concrete review process. When an agent modifies a support classifier, it must supply evidence that existing cases still work. One successful demonstration is insufficient.

Give the builder four tasks: create a classifier, add a test, change an escalation rule and diagnose a misclassification. Define the expected result, allowed sources and verification for each. Compare model or skill changes on that same task set.

In n8n, I would separate proposing a workflow change from deploying it. The agent can prepare changes and candidate tests; evaluation must also include human-approved cases that the agent cannot rewrite simply to pass. A reviewer checks the diff and results before activation.

Track repair cost and reviewer interventions too. An agent that produces working code while exceeding its permissions or deleting an inconvenient test has not completed the job successfully. This is a proposed pilot inspired by the case study, not my own Conductor benchmark or a verified n8n integration.

An AI agent does not become useful because you add another prompt. It becomes useful when you build a loop around it: where work comes from, what the agent may do, how the result is checked, what is retained for the next run, and when a human must take over.

That operating layer is increasingly called loop engineering. It is neither a new model nor a magic autonomy switch. IBM describes it as designing agentic workflows that repeatedly guide agents toward a goal; in practice, the developer moves from writing isolated prompts to building the system that triggers, checks and corrects the agent.

A prompt handles a step. A loop runs the work.

A prompt can say: “Review new support tickets and draft replies.” A loop supplies the operational decisions that make it safe to run daily:

  • a ticket enters from Help Scout or the CRM,
  • a cheap classifier routes it and strips sensitive data,
  • a primary agent drafts only from approved knowledge,
  • a separate check verifies citations, tone and escalation rules,
  • the reply is sent only after human approval—or for tightly bounded low-risk cases,
  • the run stores inputs, sources, output, cost and decision reason.

That is the difference between an automation demo and a working process. The agent gets a bounded job, a verifiable output and a clear stop condition.

Five parts of a first useful loop

1. A clear source of work

Use a specific trigger: a new email in a queue, an unresolved ticket, a PR with failing CI, a row change or a batch of invoices. Do not start with “find whatever needs doing”. A narrow backlog with an owner and priority is much safer.

2. Bounded execution

Give the agent explicit tools, permissions and budget. For coding, that is an isolated Git worktree, branch, approved commands and a time/token limit. For CRM enrichment, it is read-only queries, an expected JSON schema and no production write without a follow-on workflow action.

3. Independent verification

Do not ask the agent to grade its own work. Code changes need CI, tests or a second reviewer with a different instruction. Document extraction needs required-field, total and source-page checks. Support replies need source, policy and sensitive-category checks.

Independent does not have to mean expensive. JSON Schema validation, accounting totals, a test, a diff, source whitelists or “no evidence, no action” are often stronger and cheaper than another large-model call.

4. State and evidence

Every run needs a trace: input ID, prompt or skill version, tools used, output, cost, validation result and artifact link. Without this, you cannot tell whether the agent completed the work, merely claimed it did, or should retry differently.

In a small n8n or Make workflow this can be a table or database record. In engineering it can be an issue, PR, test run and a short memory.md for the next attempt. State is the memory of the loop, not paperwork.

5. Stop condition and human gate

Autonomy needs a boundary. Stop after a passing test, three failed attempts, a budget breach, low confidence or before an irreversible action. A human then approves a meaningful transition: merging to main, issuing an invoice, changing CRM data or responding in a sensitive case.

Where to start

Do not start with an “autonomous company”. Choose repeatable work with a clear input and cheap verification:

  • Lead triage: enrich the company, propose a segment and reason; write to the CRM only after required-data checks.
  • Invoices and documents: OCR plus LLM extracts structure; rules verify VAT ID, totals and duplicates; exceptions go to accounting.
  • Support: classification and reply drafts run automatically, while refunds, security and legal topics wait for a human.
  • CI maintenance: an agent takes one failing test, works in a worktree, runs tests and opens a PR; it never merges itself.
  • Content pipeline: research, outline and variants can be automated, but factual claims and publishing stop at review.

In n8n or Make, the loop is typically a trigger, queue, agent step, validator, persistent state and escalation branch. The model is one component—not the whole system. Cheap classifications and checks can run on smaller models or deterministic rules; reserve costly reasoning for work where it helps.

Permissions are not a gate on every step. They are another layer of the loop.

Approving every command looks safe, but long sessions quickly create approval fatigue. People stop reading and click allow. The opposite extreme is bypass or full access with the assumption that the agent understood every boundary correctly.

Claude Code's new Auto mode sends each action through a separate safety classifier before execution. It is designed to block actions that exceed the request, target unfamiliar infrastructure, appear to be driven by hostile content, or are irreversible. This is not bypassPermissions: explicit ask and deny rules still apply, protected paths are not silently approved, and repeated blocks make the agent fall back to manual approval.

Starting on August 14, 2026, Auto is scheduled to become the default for new Pro, Max and Team sessions. You can set it explicitly in your user-level ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "auto"
  }
}

A project-level settings file cannot enable Auto by itself. That boundary matters: a repository must not be able to grant itself broader permissions by embedding configuration. Teams should also manage the default centrally and use disableAutoMode where a classifier does not fit the organisation's risk model.

The operating rule is simple: automate routine steps, not high-impact decisions. An agent can install lockfile dependencies, edit code and run tests inside an isolated worktree. Production deploys, IAM changes, secret handling, mass deletion, sensitive-data transfer or an unreviewed merge should remain explicit gates. Auto mode reduces interruptions; it does not replace a sandbox, an audit trail or accountability for the outcome.

Measure evidence, not the feeling that it works

Start with five numbers: completed-run rate, human-intervention rate, retries, cost per completed output and post-validation error rate. For coding agents, add time to green CI and reviewer rework. For operational workflows, track the worst failure—not only the average.

This is why loop engineering matters more than endlessly refining a prompt. A prompt can improve one run. The loop determines whether the same work works tomorrow, next month and after a model change—and whether you have enough evidence to trust it.

October 2, 2026 update: the agent is running, but is work advancing?

In a new episode, Jirka Herník describes five days of agent work on DigiReality, planned Grafana monitoring and subscription limits. This is the creator's experience, not independent proof of a self-sustaining business. The useful operational question is how to detect a loop that has quietly stopped making progress.

For a small pilot, I would separate three signals. Liveness: are the scheduler and worker running? Progress: when was the last verified result recorded? Blocked work: is the task waiting for a person, a quota reset or a tool? A healthy process can repeat the same error for hours without completing anything.

For invoice processing in n8n, store the document ID, last verified step, attempt count, waiting state and next retry time in a state table. A separate monitor reads that state. “There is queued work, but no verified result for 30 minutes” is more useful than another agent message saying it is working. Thirty minutes is an illustrative threshold; overnight batches and live support need different values.

Monitor the monitoring as well. Grafana distinguishes missing data from missing series. An empty query is not automatically zero errors. Prometheus offers absent_over_time for a known expected metric; stale progress needs a separate check. The mere presence of a metric proves little.

When a quota is exhausted, save a checkpoint and schedule a delayed retry. Recovery must not send the same email or record the same invoice twice: check the outcome using a stable operation ID before repeating the write. If an external write has an uncertain outcome, inspect the destination first.

Before leaving a workflow running for days, simulate a dead worker, an unavailable model and missing telemetry. Verify that an alert reaches a named person and that recovery produces no duplicate action. This is a proposed operating procedure, not a claim that the video demonstrated those tests.

Sources