Here is the line I keep coming back to: loop engineering without a platform is just automation with better branding.

Every few months the AI world adopts a new phrase and asks it to carry more weight than any phrase should. Prompt engineering. Context engineering. Harness engineering. Agentic engineering. Now loop engineering. Most of them are annoying before they are useful, and a few of them turn out to name something real.

Loop engineering is one of the real ones. Not because it is clever, but because it is boring in the right way. It names the cycle around agentic work: intent, context, action, observation, correction, and knowing when to stop. A prompt asks once. A loop keeps working against evidence.

That word, evidence, is the whole game. A loop without evidence is not engineering. It is motion. And motion is exactly what you get when you point an agent at your data platform and hope for the best.

The prompt was too small

The first wave of AI-assisted work made the prompt feel like the control surface. Write a better instruction, get a better answer. Add examples, paste the error, ask again. That worked because the unit of work was small: a function, a query, a single transformation. A human still held the thread and decided what happened next.

Agents changed the shape of the interaction. A data agent does not just answer a question. It reads your warehouse, writes a model, runs the transformation, updates tests, and opens a pull request against your dbt project. OpenAI's Codex Goals frame this well: a goal is a persistent objective with completion conditions and success checks, not a bigger prompt. The point is a target that can be checked against evidence over many turns.

So a prompt says: build this table. A loop says: keep working until this table is correct, documented, and safe to publish, or until the system can explain why it cannot be.

Which raises the obvious question. Who decides that the table is correct and safe? Not the agent. At least, not on its own.

The platform closes the loop

A loop needs somewhere to send that question: is this work complete enough to continue? For a data product, the answer almost never lives inside the model. It lives in the platform.

The pull request is where the loop meets reality. The agent can write the SQL, add the tests, update the contract, and open the PR.

The moment that PR exists, the platform starts producing signals.

  1. dbt build passes or fails.
  2. Data tests pass or fail.
  3. The data contract holds or breaks.
  4. Source freshness and volume checks flag an upstream source that went stale overnight.
  5. A column classifier notices a new field that looks like PII with no masking policy attached.
  6. Lineage analysis shows the change will silently break three downstream dashboards.
  7. Policy-as-code decides whether any of this is allowed in production.

The agent runs the loop. The platform closes it.

That is the part most loop-engineering conversations skip, and it is the part that actually matters.

The platform's job here is not to write the model -> It is to define what "done" means.
flowchart TD A[Agent receives goal] --> B[Reads warehouse and models] B --> C[Writes model, tests, and contract] C --> D[Opens pull request] D --> E[Platform runs checks] E --> F[dbt build and data tests] E --> G[Data contract validation] E --> H[Freshness and volume] E --> I[PII classification and masking] E --> J[Lineage and downstream impact] E --> K[Policy-as-code] F --> L{Completion condition met?} G --> L H --> L I --> L J --> L K --> L L -->|Yes| M[Ready for review or publish] L -->|No, fixable| N[Agent gets structured feedback] --> C L -->|No, blocked| O[Escalate to engineer with evidence]

One loop, start to finish

Abstract principles are easy to nod along to and hard to use, so here is a concrete one.

An analyst asks the agent to build a customer_revenue mart. The agent reads the existing staging models, writes the SQL, adds a handful of dbt tests, and opens a PR. The platform runs. dbt build is green and the tests pass, so far so good.

But the contract check fails: the agent added a customer_email column, and the classifier flags it as PII with no masking policy. Freshness also fails, because the upstream orders source has not refreshed in eighteen hours.

Two problems, two different kinds. The PII one may be fixable inside the loop. The agent removes the raw email from the published mart and uses the platform-approved customer identifier instead. If the business really needs contact-level analysis, the loop has to attach the approved masking policy or escalate for an exception. It does not invent its own hashing scheme and call it governance. That check goes green.

The freshness one is different. A stale upstream source is not a code problem. So the loop stops and escalates, with the evidence attached: here is the model, here are the passing tests, here is the source that is stale and the owner who needs to refresh it.

Nobody had to babysit that. The agent did the work it could verify, and handed back the one decision it could not. That is the difference a platform makes.

Signals beat opinions

The weakest version of loop engineering is an agent asking itself whether it is finished. That is fine for a toy. It falls apart the moment the output feeds a finance dashboard.

A serious loop needs signals that live outside the agent's own confidence. A failed data test is a signal. A broken contract is a signal. A stale source, an unclassified column, a downstream dashboard that will break, a policy violation on regulated data: all signals. The agent should not receive these as bare errors. It should receive them as instructions it can act on.

Compare "the contract check failed" with something the agent can actually use: "the PR adds customer_email, classified as PII, with no approved handling policy. Continue only by removing the column, replacing it with an approved identifier, applying the approved masking policy, or attaching an approved exception." The first is a shrug. The second tells the loop what it is allowed to do next. That is the line between a check and a guardrail.

A check reports.

A guardrail changes the loop's options.

Guardrails are executable judgment

Every mature data team has rules. Some are written down. Some live in CI. Some live in the head of the one engineer everyone waits for because they know which tables you do not touch without asking.

A human analyst can infer that culture. They learn that "use the standard staging pattern" also means "do not join straight onto the raw source" and "ask the data team before you rebuild that mart." An agent gets none of that for free. It needs the rule to be explicit, which is exactly why guardrails matter.

A guardrail is what you get when a team turns a repeated review comment into something the platform can enforce: do not publish PII without an approved handling policy, do not ship a model that breaks its contract, do not deploy against a stale source, do not create a mart outside the golden path, do not touch regulated data without a policy decision.

This is the thread running through the Arkham pieces on agent-native platforms and golden paths for machines. When the consumer is a machine, the platform can no longer lean on human inference. A golden path built for humans is a recommendation. A golden path built for agents is an API. The more work you hand to agents, the more those guardrails are worth. AI does not reduce the need for platform discipline. It raises the return on it.

The business does not buy loops

Stakeholders do not care that an agent can iterate. They care whether the organisation turns intent into trustworthy data faster and with less risk. That is a different conversation, and it is easy to measure the wrong thing.

"We opened more pull requests" is not an outcome. Sometimes it is a good sign and sometimes it is an expensive one. The metric that matters is the marginal cost of safe change. If contract checks catch breaking schema changes before review, you get fewer 8am dashboard fires. If PII classification runs before merge, you get fewer governance gaps to explain to an auditor. If freshness gates block stale publishes, "ready" starts to mean something concrete. The platform is not just enforcing rules. It is converting agent activity into evidence a business can trust.

So the questions worth asking are not "how much AI are we using?" but "which recurring delivery cost did this loop remove, and which manual judgment did we turn into an executable guardrail?"

Failed loops are free research

Here is the part I find genuinely useful. A failed loop is often a platform discovery, not just an agent failure.

If the agent cannot find the right staging model, your golden path is not machine-readable enough. If it keeps violating a modelling rule, that rule is hidden in review culture instead of encoded in the platform. If it repeatedly trips the same PII check, the classification policy sits too far from where the work happens. A human routes around unclear systems without noticing. An agent walks straight into them and leaves a mark.

That can be frustrating at first, and it is worth it, because every failed loop points to a missing contract, test, template, or ownership signal. The mature team does not just tune the prompt. It fixes the platform.

Engineers design completion

For the engineers, the payoff is not only speed, though the speed is real. The deeper shift is that you stop repeating the same operating instructions in every prompt. Run the tests. Check the contract. Respect the staging pattern. Handle sensitive data correctly. Show the evidence. Those should be properties of the loop and the platform, not things a human retypes all day.

That changes the job. You spend less time writing the model and more time deciding what has to be true before the loop is allowed to stop: which signals count as evidence, which failures the agent can repair, which are hard stops, which need a human. The SQL still matters. But as agents generate more of it, the system around it matters more, and the platform becomes the place where your team's judgment compounds.

Don't trust the loop. Trust the system.

People keep asking whether the agent can be trusted. Wrong question. We do not trust a human analyst in isolation either. We trust them inside version control, review, tests, approvals, and rollback. Treat agents the same way. Do not trust the loop. Trust the loop inside a system that can observe it, constrain it, correct it, and stop it.

LangChain describes verification loops as systems where outputs are checked against a rubric and retried on failure. In data work the verifier is not another model. It is the platform: the memory of your standards and the source of machine-readable consequences. It tells the agent when to continue, when to repair, when to escalate, and when to stop.

Where to start

Most teams will not jump to fully autonomous data engineering, and they do not need to. A rough maturity ladder: the human prompts and reviews; the agent opens a PR; the platform shows signals a human still interprets; the agent consumes those signals and repairs its own PR; guardrails define completion so "done" means the evidence passed; and finally, repeated failures feed back into better contracts, tests, and templates.

That last rung is when it starts to compound, not when the agent can do more, but when the platform gets better because the agent tried.

Pick a first loop that is boring on purpose. A source freshness and contract loop is a good one: the agent proposes a model, the platform blocks publish until freshness and contract checks pass, and it escalates instead of improvising when a source is stale. A test-repair loop is another: the agent fixes failing data tests, and the test suite, not the agent's explanation, decides when it is done.

The real contract underneath all of it is simple.

The agent may act. The platform must observe. The guardrails constrain. The signals teach. The human judges what remains. The business measures the outcome.

When an agent opens a PR, that PR is not an artefact. It is a question submitted to the platform.

Is this correct?

Is this compliant?

Is this safe to publish?

If the answer is no, the loop is not done. Not because the agent failed. Because the organisation has a standard.

That is the point.

Loop engineering is not valuable because the agent keeps going. It is valuable because the system knows when it must stop.

The agent creates motion.

The platform turns motion into evidence.

The standard turns evidence into trust.

Without the platform, there is no loop engineering.

Just a faster way to make uncertainty look productive.