Prompt engineering was the primitive of 2023, context engineering owned 2024–2025, and 2026 is settling on a new one: loop engineering — the discipline of designing the feedback loops that surround an agent, not just the agent itself. Sydney Runkle (PM on LangChain’s open-source team) makes the case in this webinar that the durable advantage is never the agent, it’s the loops built around it.

Why loops, not agents

Runkle opens with a simple framing: a model has some fixed level of intelligence; a harness wrapped around it converts that intelligence into useful work on a specific problem. Loops are what make the harness robust. Every time the agent runs, a well-designed system should be able to improve from that run — not just complete the task.

She stacks four loops from most familiar to most speculative. Each loop composes with the one below it.

Loop 1 — the core agent loop

The core agent loop — model calls tools until done

This is the loop LangChain has been talking about since ReAct: the model calls a tool, observes the result, decides what to do next, iterates until it thinks the task is done. Nothing new here, but Runkle’s point is that the shape of this loop constrains everything else — if your inner loop is fragile, no outer loop saves you.

Loop 2 — the slash-goal / verification loop

The second loop wraps the core loop with a grader. The agent produces a candidate result, a separate grader (rubric-driven, often another LLM) scores it against explicit criteria, and if the score is below threshold the whole inner loop runs again with the grader’s feedback as additional context.

Verification loop: core loop + grader for reliability

Runkle demos LangChain’s Dcode terminal coding agent (built on Deep Agents) doing this against a /goal command: the goal spec becomes the rubric, and the agent won’t return until it self-verifies. This is the loop that pushed reliability numbers up meaningfully on coding agents in the past year.

Loop 3 — the event-driven loop

Event-driven loops connect agents to Slack, GitHub, email

The third loop is what she credits for making her “actually use agents”: wiring them into the systems where work already happens. Slack messages, GitHub issues, calendar invites, inbound emails — the agent isn’t a chat window you visit, it’s a subscriber to your event streams. This is where human-in-the-loop gates matter most: for sensitive actions (sending an email to a customer, merging a PR), the agent stops and requests approval.

The interesting design tension Runkle flags: too many approval prompts and humans stop reading them; too few and the agent takes destructive actions. Her rule of thumb is to gate on irreversibility, not sensitivity.

Loop 4 — the hill-climbing / self-improvement loop

Hill-climbing loop: production traces feed proposed patches back into the agent

This is the loop she calls her favorite, and it’s the one still being invented. Production traces + evals + human labels feed a second agent whose job is to propose edits to the first agent — prompt tweaks, new skills, new eval cases, sometimes small code changes. Runkle is careful: modifying the source code of an agent still requires human review before merge. The bot is a very productive junior engineer, not an autonomous merger.

The key takeaway she frames explicitly: the advantage is not in the agent you build, it’s in the loops you build around it. Loops amplify impact — an agent without loops is a party trick; an agent with all four loops is a system that gets better while you sleep.

Where LangSmith fits

LangSmith positioned as the loop-engineering platform

The webinar is unabashedly a product pitch — LangSmith Fleet for build, LangSmith Deployment for one-click ship, LangSmith Engine as the “agent for agent improvement” that drives the hill-climbing loop. Cut through the marketing and the underlying claim is defensible: shipping serious agents requires infra for all four loops, and most teams are still hand-rolling three of them.

Key takeaways

  1. Loop engineering is the new primitive after prompt and context engineering — design the feedback loops, not just the prompts.
  2. Four loops compose: core action loop → verification/grader loop → event-driven loop (Slack/GitHub/email) → hill-climbing/self-improvement loop.
  3. The grader is a separate concern from the actor. Don’t ask the same LLM call to both do the work and judge whether it succeeded.
  4. Event-driven integration is where agents earn their keep — a chatbot is a demo, a Slack-native agent is a coworker.
  5. Gate human review on irreversibility, not sensitivity. Approval fatigue kills the loop.
  6. The self-improvement loop needs a memory system — Runkle points to the new Deep Agents memory docs as prerequisite reading; without persistent memory, the hill-climbing loop can’t accumulate.
  7. The agent isn’t the moat, the loops are. A commodity model inside a well-engineered loop beats a frontier model inside a bare wrapper.

Source

  • Title: The Art of Loop Engineering: How to Build Agents That Improve Over Time
  • Speaker: Sydney Runkle (Product Manager, Open Source, LangChain)
  • Venue: LangChain webinar, July 2026
  • Duration: 46 min
  • URL: https://www.youtube.com/watch?v=jPPiZ22DY3g