In this article, you will learn what loop engineering is, where it came from, and how to design autonomous AI agent cycles that run reliably without constant human supervision. Topics we will cover include: The origin and definition of loop engineering, and how it fits into the broader progression from prompt engineering to context engineering to harness engineering. The anatomy of a reliable loop, including its essential components, common patterns, and the pseudocode skeleton that underlies nearly every production implementation today. The three hardest problems in loop engineering — context management, termination, and verification — and the failure modes that result from getting any one of them wrong. Introduction A few months ago, a developer’s evening looked like this: open the coding agent, type an instruction, wait, read what came back, paste the error into the chat, wait again, nudge it in a slightly different direction, and repeat until the feature actually worked or until it was time to sleep. The agent was doing real work, but the human was still holding it the entire time, one turn after another, like driving a car that needs a hand on the wheel every three seconds. That evening looks different now for a growing number of engineers. They write one instruction, close the laptop, and come back the next morning to a draft pull request, a triaged issue list, or a green CI build, along with a readable trail of what the agent tried and why. Nobody stood over it, typing the next prompt. What changed wasn’t the model. It was what got built around the model. The name that stuck for that shift is loop engineering, and it went from a niche phrase to something people were debating on every timeline within about a week in June 2026. This article walks through where the term came from, the research it actually descends from, what a loop is made of, and how to build a small one of your own. What Loop Engineering Actually Means Loop engineering is the practice of designing the system that prompts, checks, remembers, and re-runs an AI agent, instead of a person doing all of that by hand, turn by turn. The unit of work stops being a single prompt or even a single conversation. It becomes a loop: a repeating cycle where the model takes an action, gets feedback from its environment, uses that feedback to decide what to do next, and keeps going until a real, checkable condition is met. It helps to hold this next to the thing it’s replacing. A chain runs in a fixed order: step A leads to step B, which leads to step C, and that’s it. A loop is dynamic. The agent might go from A to B, discover B didn’t work, revise its approach, and only then move to C, or it might loop back to A entirely. MindStudio’s breakdown of the concept puts it plainly: a loop continues until a task is genuinely complete, a stopping condition triggers, or the agent determines it can’t go any further. That’s a fundamentally different shape of work than “ask once, get an answer, copy it out.” The other framing worth sitting with is the “recursive goal” idea. Instead of typing each next step, you define a purpose — something like “make the test suite pass” or “triage every open issue and draft fixes for the straightforward ones” — and the agent iterates on its own toward that purpose: inspect the code, make a change, run a check, read the outcome, decide the next move. The skill shifts from writing one very good sentence to designing a cycle you trust enough to walk away from. How This Became a Term Almost Overnight It’s worth being specific about the timeline here, because the speed is part of the story. On June 7, 2026, developer Peter Steinberger, known for the OpenClaw agent project, posted on X that the relevant skill had already changed: you shouldn’t be prompting coding agents anymore, you should be designing the loops that prompt them for you. That post reportedly crossed 6.5 million views within days and dominated agent-focused conversation for the following week. The very next day, Google engineer and author Addy Osmani published an essay titled simply “Loop Engineering” that took Steinberger’s claim and gave it an actual anatomy: automations, worktrees, skills, connectors, and sub-agents, plus a sixth piece underneath all of it — external memory. That essay is what turned a viral take into a vocabulary that other people could build on and argue about. It wasn’t only outsiders making this case. Boris Cherny, who leads Claude Code at Anthropic, is quoted by Osmani as saying, “I don’t prompt Claude anymore. I have loops running that prompt Claude, and figuring out what to do. My job is to write loops.” When the person building one of the most-used coding agents on the market says he’s stopped prompting it directly, the idea has clearly moved past a fringe opinion. The timing makes sense once you look at what changed underneath it. By mid-2026, coding agents had gotten good enough to run unattended for genuinely long stretches, recovering from their own mistakes along the way, rather than needing correction every second or third step. Once a single agent run can last an hour and touch dozens of files, the bottleneck isn’t the sharpness of your prompt anymore. It’s whether you’ve built a cycle that keeps the agent productive, checked, and pointed at the right goal for the whole hour — including the part where nobody’s watching. Where It Fits: Prompt, Context, Harness, Loop Loop engineering didn’t appear out of nowhere, and it helps to see it as the newest layer in a steady progression outward, each one wrapping the previous layer rather than replacing it. Prompt engineering came first, roughly 2022 through 2024. The skill was wording: giving the model a role, breaking a task into steps, providing examples, and asking it to reason step by step.

In this article, you will learn how Ollama, LM Studio, and llama.cpp differ across the dimensions that matter most to practitioners, and how to choose the right one for your workflow. Topics we will cover include: How the three runtimes compare across five key axes: interface, API compatibility, quantization control, model discovery, and update cadence. How to match your working style to the right tool using three practitioner personas. The natural progression most practitioners follow as their needs grow more demanding. Introduction In our Introduction to Small Language Models, we covered why local, small-footprint AI is changing the development stack. We followed that up with a look at the most capable hardware-friendly models in our Top 7 Small Language Models You Can Run on a Laptop. Then we walked through the fastest way to get inference running locally in Run a Local AI Model in 15 Minutes: Your First Ollama Setup. By now, you probably have a 3B or 8B parameter model running quietly in your terminal. Spend enough time in the local AI ecosystem, though, and you’ll notice Ollama isn’t the only option competing for your hard drive. Three tools dominate the local AI runtime landscape: Ollama, LM Studio, and llama.cpp. Choosing between them can feel like guesswork, but all three are running the same core inference engine under the hood. What actually differs is developer experience, abstraction level, and how much control you want over the process. To make that concrete, let’s start by looking at each tool doing the exact same job. The Code Contrast: One Task, Three Abstractions The fastest way to understand how these tools differ in philosophy is to see them side by side. Here’s the exact same task — asking a local Llama 3.2 model to say “Hello” — across all three runtimes. # ————————————————————— # The Same Task: Asking a local Llama 3.2 3B model to say “Hello” # ————————————————————— # 1. LM Studio (Assuming the GUI is open and the local server is toggled ON) curl http://localhost:1234/v1/chat/completions \ -H “Content-Type: application/json” \ -d ‘{“model”: “llama-3.2-3b”, “messages”: [{“role”: “user”, “content”: “Hello”}]}’ # 2. Ollama (Via its dedicated, background-daemon CLI) ollama run llama3.2 “Hello” # 3. llama.cpp (Via the raw, compiled C++ binary in your terminal) ./llama-cli -m ./models/llama-3.2-3b-q4_k_m.gguf -p “Hello” -n 50 -c 2048 -ngl 33 # ————————————————————— # The Same Task: Asking a local Llama 3.2 3B model to say “Hello” # —————————————————————   # 1. LM Studio (Assuming the GUI is open and the local server is toggled ON) curl http://localhost:1234/v1/chat/completions \   –H “Content-Type: application/json” \   –d ‘{“model”: “llama-3.2-3b”, “messages”: [{“role”: “user”, “content”: “Hello”}]}’   # 2. Ollama (Via its dedicated, background-daemon CLI) ollama run llama3.2 “Hello”   # 3. llama.cpp (Via the raw, compiled C++ binary in your terminal) ./llama–cli –m ./models/llama–3.2–3b–q4_k_m.gguf –p “Hello” –n 50 –c 2048 –ngl 33 Notice the progression. LM Studio wraps everything in a graphical interface and exposes a friendly API endpoint. Ollama tucks the complex parameters behind a single CLI command. And llama.cpp puts everything on the table: model file path, token prediction limit (-n), context window size (-c), and how many neural network layers to offload to your GPU (-ngl), all of which you define explicitly. That spectrum from “managed” to “manual” runs through every dimension of how these tools work. Let’s break each one down. The 5 Axes of Practitioner Comparison Marketing bullet points don’t tell you much about how a tool actually feels when you’re deep in a development cycle. Here’s how the three runtimes compare across the dimensions practitioners actually notice. 1. GUI vs. CLI (The Interface Layer) LM Studio is a full desktop application built on Electron/React. It includes a ChatGPT-style chat interface, a visual model browser, and sliders for adjusting inference parameters. Ollama runs as a silent background service. You interact with it through the command line or HTTP requests. It’s designed to stay out of your way. llama.cpp is a raw CLI. There’s no background service unless you explicitly compile and run the llama-server binary, and every action requires typing out execution flags by hand. 2. OpenAI API Compatibility (The Integration Layer) The interface layer matters for day-to-day use, but the integration layer determines whether a tool fits into your existing codebase. When you’re building applications, you want local models to drop in as a replacement for OpenAI’s cloud API without rewriting your existing logic. Both Ollama (port 11434) and LM Studio (port 1234) expose /v1/chat/completions endpoints out of the box. Change the base URL in your Python or Node.js SDK and your app thinks it’s talking to GPT-4. llama.cpp also provides an OpenAI-compatible server, but getting it running requires manual shell scripting and a solid grasp of the available parameters. 3. Quantization Control (The Hardware Layer) Once you’ve sorted out how you’ll connect to the model, the next question is how well it fits on your machine. Quantization shrinks large models to laptop-friendly sizes by reducing the precision of their internal weights, and the three runtimes handle this very differently. Ollama manages quantization for you. Pull a model and it defaults to a well-tuned 4-bit quantization. If you want something different, you append a specific tag via the CLI (e.g. :8b-instruct-q8_0). LM Studio stands out here: it shows a visual list of every available quantization for a given model, with a color-coded indicator telling you whether it’ll fit in your RAM before you commit to the download. llama.cpp gives you full control. You download the exact .gguf file you want, and you have access to the underlying Python scripts to quantize raw PyTorch tensors into custom formats yourself. 4. Model Library Breadth (The Discovery Layer) Control over quantization is only useful if you can find the models you want to run. Here’s how each tool handles discovery. Ollama maintains a curated central registry, similar in feel to Docker Hub. It’s clean and reliable, but it can lag a few days behind major model releases. LM Studio has a built-in Hugging Face

In this article, you will learn how an agent’s approach to managing state — stateless or stateful — shapes both its implementation and the deployment architecture built around it. Topics we will cover include: What separates stateless from stateful agents, and the tradeoffs each design imposes on scaling. How to implement a stateless agent that depends entirely on the client to supply conversation history. How to implement a stateful agent that manages its own memory through a database layer. Introduction A previous article laid out a comprehensive architectural roadmap for AI agent deployment, examining the infrastructure needed to bring agents into production settings. As a follow-up, we now turn to a fundamental, practical question that has to be answered before any load balancer is configured: where does the agent’s memory reside? Agents may handle their state (the context gained so far and the conversation history) in different ways, and this code-level decision can significantly impact the entire deployment architecture. This article breaks down the two primary paradigms for handling an agent’s state: stateless and stateful design. A simplified version of a real-world implementation, using open language models served through the fast Groq API, will illustrate these ideas in practice. Initial Setup If this is the first time you are using language models from Groq in a Python program, you’ll need to install the required library: pip install groq. After that, we import it and set our Groq API key in the code below: import os from groq import Groq # Get an API key in https://console.groq.com/keys and set it here os.environ[“GROQ_API_KEY”] = “PASTE_YOUR_GROQ_API_KEY_HERE” # Initializing the client client = Groq() # Using an efficient model from Groq: Llama 3.1 8B Instant MODEL_ID = “llama-3.1-8b-instant” import os from groq import Groq   # Get an API key in https://console.groq.com/keys and set it here os.environ[“GROQ_API_KEY”] = “PASTE_YOUR_GROQ_API_KEY_HERE”   # Initializing the client client = Groq()   # Using an efficient model from Groq: Llama 3.1 8B Instant MODEL_ID = “llama-3.1-8b-instant” An important setup decision here is the choice of a specific model. llama-3.1-8b-instant is a highly cost-efficient model that is, at the time of writing, generously supported on Groq’s 2026 free tier: it allows up to 14,400 requests per day. That makes it an ideal choice for illustrating the stateless and stateful agent paradigms below. Stateless Agents: Fire and Forget Stateless agents treat each request as completely isolated and independent. The agent reads the user prompt, invokes the LLM inference engine, and delivers the output. Once that execution cycle ends, everything is forgotten. The Tradeoff Architectures based on stateless agents can be scaled horizontally with remarkable ease. Since no user memory is stored on a backend server, incoming requests can be forwarded to any available instance. There is, however, an important limitation in multi-turn conversations: the frontend must re-send the whole conversation history alongside every new request. As a result, the context window grows with a snowballing effect, quickly driving up token usage. Illustrative Example This runnable code illustrates, through a basic scenario, how a stateless agent typically interacts with a Groq language model. First, we define a stateless_agent function that emulates an agent’s interaction with our chosen model. Importantly, no state or memory of the conversation is kept internally. Instead, the previous conversation history can optionally be passed in as a parameter and appended to the current prompt. The API call to the Groq model takes place in client.chat.completions.create(). def stateless_agent(prompt: str, provided_history: list = None) -> str: “”” The agent relies completely on the client to provide context. It retains no information from past interactions in local memory. “”” # Initializing with a system prompt messages = [{“role”: “system”, “content”: “You are a helpful, concise assistant.”}] # Appending whatever history the client provided if provided_history: messages.extend(provided_history) # Appending the new prompt messages.append({“role”: “user”, “content”: prompt}) # The LLM processes the entire chain of messages response = client.chat.completions.create( model=MODEL_ID, messages=messages, max_tokens=100 ) return response.choices[0].message.content.strip() 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 def stateless_agent(prompt: str, provided_history: list = None) -> str:     “”“     The agent relies completely on the client to provide context.     It retains no information from past interactions in local memory.     ““”     # Initializing with a system prompt     messages = [{“role”: “system”, “content”: “You are a helpful, concise assistant.”}]          # Appending whatever history the client provided     if provided_history:         messages.extend(provided_history)              # Appending the new prompt     messages.append({“role”: “user”, “content”: prompt})          # The LLM processes the entire chain of messages     response = client.chat.completions.create(         model=MODEL_ID,         messages=messages,         max_tokens=100     )          return response.choices[0].message.content.strip() To understand the limitations of a stateless agent, we simulate a simple user-model conversation through it: # — Testing the Stateless Agent — print(“— Turn 1 —“) prompt_1 = “Hi, my name is Alice and I am learning about API infrastructure.” response_1 = stateless_agent(prompt_1) print(f”Agent: {response_1}”) print(“\n— Turn 2 (Without Client Context) —“) # The agent fails here because it retained no memory of Turn 1 prompt_2 = “What is my name and what am I learning about?” response_2 = stateless_agent(prompt_2) print(f”Agent: {response_2}”) print(“\n— Turn 2 (With Client Context) —“) # The frontend MUST inject the history into the payload for the agent to succeed frontend_payload = [ {“role”: “user”, “content”: prompt_1}, {“role”: “assistant”, “content”: response_1} ] response_3 = stateless_agent(prompt_2, provided_history=frontend_payload) print(f”Agent: {response_3}”) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # — Testing the Stateless Agent —   print(“— Turn 1 —“) prompt_1 = “Hi, my name is Alice and I am learning about API infrastructure.” response_1 = stateless_agent(prompt_1) print(f“Agent: {response_1}”)   print(“\n— Turn 2 (Without Client Context) —“) # The agent fails here because it retained no memory of Turn 1 prompt_2 = “What is my name and what am I learning about?” response_2 = stateless_agent(prompt_2) print(f“Agent: {response_2}”)   print(“\n— Turn 2 (With Client Context) —“) # The frontend