A normal prompt is linear: you ask a model a question and it produces an answer. That is useful for summarisation, drafting and many knowledge tasks. But an enterprise agent often has to do more. It may need to inspect data, call a tool, compare several sources, notice that evidence is missing, try a different action and decide whether the final result is good enough to return.

This is where loop engineering begins. Instead of treating the model response as the end of the workflow, we treat it as one step inside a controlled system. The system keeps state, observes what happened, evaluates progress and decides what should happen next.

The difference can be summarised as: Prompt engineering improves an individual response; agent engineering gives the model tools and actions; loop engineering designs the repeated decision process around those actions.

Figure . Anatomy of an agentic loop: goal, plan, act, observe, evaluate and reflect - surrounded by guardrails.

The core loop: Plan -> Act -> Observe -> Evaluate

A useful beginner model has six steps. The goal defines the business outcome. The agent then plans the next step, acts by calling a model, tool or data source, and observes the result. An evaluation checks whether the result is useful, grounded and safe. If it is not, the agent reflects or replans and takes another action.

The most important design decision is often not the model itself, but the control logic around the model: How many retries are allowed? What counts as enough evidence? What should happen when two data sources disagree? When should the system stop? When should a human approve the next step?

Figure - Different loops solve different reliability problems: execution, quality, control, memory and production learning.

Five loop patterns worth knowing

1. Execution loop (The Doer) - the agent repeatedly chooses the next tool or action until the task is complete.
2. Retrieval and evidence loop (The Researcher) - the agent searches again when the available context is incomplete or contradictory.
3. Quality or reflection loop (The Editor) - an answer is judged for grounding, completeness, relevance or safety, then revised if needed.
4. Human-control loop (The Guardrail) - the agent pauses for approval or escalates when confidence is low, risk is high, or policy requires oversight.
5. Production learning loop (The Flywheel) - failures, traces and user feedback become new test cases that improve the next version of the system.

These loops can be combined. A production agent may have an execution loop inside a quality loop, with a human gate around high-risk actions and a production feedback loop operating over time.

The Wanderbricks demo: seeing the loop happen

The notebook uses Databricks' built-in Wanderbricks sample data to create a small travel-support investigation agent. Imagine a booking where the booking status and payment status need investigation. Instead of joining every table up front and asking the model for one answer, the agent works incrementally.

Figure . The notebook demo makes the loop explicit: choose an action, query evidence, observe, evaluate and continue only when needed.

The first iteration may inspect the booking. The evidence gate says that this is not enough, so the loop continues to the payment record. It can then inspect booking updates and customer-support history. Only when the evidence gate is satisfied does the agent generate an answer. A second quality loop judges that answer and either passes it, retries it with a critique, or sends the case to human review after the retry limit is reached.

Reliable loops need boundaries

A loop without controls can become expensive, slow or unpredictable. Production loop engineering therefore needs explicit boundaries: maximum iterations, time and cost budgets, permitted tools, evidence requirements, confidence thresholds, auditability and human escalation. Observability matters because when an agent fails, teams need to know which action, retrieval result or decision caused the failure.

This is why loop engineering is closely connected with evaluation. A system cannot decide whether to continue or stop unless it has a way to measure progress. Some checks can be deterministic rules; others may use model-based judges or domain-expert review. The right combination depends on business risk.

FDE: taking the loop from prototype to production

Figure - Production AI connects governed data, agent logic, evaluation, serving and control - the environment in which FDEs operate.

A Forward Deployed Engineer (FDE) works close to the customer's business problem, data and users. The role is not simply to build a model in isolation; it is to turn an outcome into a working system, connect it to real workflows, learn from production behaviour and keep improving it after deployment.

That makes loop engineering directly relevant to FDE work. The FDE helps define what the agent should do when evidence is incomplete, which tools it may call, how success is measured, where a human should intervene, and how production feedback becomes the next improvement. The FDE therefore engineers not only the AI capability, but also the operational loop around it.

Code Implementation

Notebook: Loop_Engineering_Wanderbricks_Databricks_Free_Edition.ipynb

The implementation turns a travel-support investigation into two controlled loops. The first loop gathers evidence one source at a time; the second evaluates the generated answer and either accepts it, retries it, or escalates. The important design choice is that state, tool use, quality gates and stop conditions are explicit in code rather than left entirely to the model.

1 | Four table-backed tools: controlled actions, not one giant query

The agent exposes four small tools backed by the Wanderbricks tables: booking, payment, booking_updates, support. Each tool represents a distinct action the controller can choose. This is intentionally different from joining every table first: the agent sees the result of one action, stores it in state, and then decides what evidence it needs next.

Figure - The four Wanderbricks tools and the two-loop control pattern used in the notebook.

2 | Evidence collection loop + answer-quality loop

Note: the evidence loop makes retrieval adaptive, while the quality loop prevents the first plausible answer from automatically becoming the final answer. Both loops are bounded by explicit retry limits and a human-review path.

3 | Running the loop: execution history makes the control logic visible

The `run_loop()` call executes the complete controller. After each action, the notebook appends a record to `history` containing the iteration, action, rows observed, decision and reason. Converting that history to a Spark DataFrame gives a simple audit trail for the audience: you can see when the controller continued gathering evidence and when it finally moved to answer generation.

Figure - The notebook executes the loop and renders the iteration history before showing the final status and answer.

4 | Evidence is retained as inspectable state

A key loop-engineering principle is that observations should not disappear inside a prompt. The notebook stores results under `result["evidence"]`, grouped by source. The final answer can therefore be checked against the booking record, payment events, booking updates and support context. In the example run, the booking is cancelled and the payment history includes both the completed charge and a matching refund, allowing the agent to recommend a safe, evidence-based next action.

Final status and answer

Evidence memory

Figure 3. The loop stops on PASS, while the evidence remains visible for audit, explanation and human review.

The takeaway

Start small: give the agent a goal, a few tools, explicit state, clear quality checks, capped retries and a human handoff. Once that loop is visible and testable, it can grow into a production system with richer memory, tracing, governance and continuous learning.

A practical next step is to explore the FDE Track from ADaSci. The track offers certification in Forward Deployed Engineering, a discipline closely aligned with loop engineering because it focuses on building, deploying, evaluating, and improving AI systems in real-world environments.

More details here - https://adasci.org/certifications/cfde-pro