Loop Engineering: Designing Agents That Run Themselves

Loop Engineering: Designing Agents That Run Themselves

Summary

Everyone obsesses over which model to use. Almost nobody engineers the fifty lines of code wrapped around it, the loop that decides what the model sees, when it gets to act, when it's allowed to stop, and what happens when it does something dumb. That loop is the agent. The model is just an expensive function you call from inside it.

This is a build-along field guide to loop engineering: the discipline of designing, hardening, and shipping the control loop that turns a language model into an agent you can trust to run unattended. We start with the naive loop, the one that works in a demo and falls over in production, and harden it chapter by chapter into a small TypeScript runtime, with an on-call triage agent as the running example. Along the way: context budgeting, stopping conditions, retries and idempotency, the approval boundary, self-verification (the DOER/CHECKER split), observability, cost control, resumability, and composing loops out of sub-loops. The model is the easy part. The loop is the craft, and it's where reliability is won or lost.

Loading Why the Loop Is the Real Program…
Loading Anatomy of a Loop: Building v0…
Loading Tools Are the Loop's Hands…
Loading Context Engineering Inside the Loop…
Loading Stopping Conditions and Turn Budgets…
Loading Retries, Idempotency, and Error Recovery…
Loading Guardrails and the Approval Boundary…
Loading Verification Inside the Loop…
Loading Observability: Making the Loop Legible…
Loading Cost and Token Control…
Loading Compaction and Long-Running Loops…
Loading Composing Loops…
Loading Shipping a Loop to Production…
Loading About Roger…

Do you like my content?

Sponsor Me On Github

Keep reading

GTM Engineering with Agents: A Field Guide to Automating the Funnel

GTM Engineering with Agents: A Field Guide to Automating the Funnel

Every go-to-market team is really running a handful of pipelines. Leads come in, get cleaned up, get scored, get worked, and either turn into revenue or quietly rot. Most of that work is mechanical, and most of it gets done by hand or by a tangle of point-to-point integrations that break the moment a vendor changes an endpoint. This guide takes the agentic approach the rest of the series is built on and points it straight at the funnel. The idea is simple: wrap every source you care about (your CRM, your enrichment providers, your email, your product analytics) as an MCP tool, then let small agents orchestrate the motions on top of them. Capture, enrichment, scoring, outbound, nurture, hygiene, forecasting, churn signals. One tool surface, many agents, each running on a schedule. It's hands-on. We build each motion as a small agent loop over MCP tools, wire them together with a cron, and put guardrails around the parts that can email a customer or overwrite a record. By the end you'll have a mental model for GTM as a system of agents, plus enough concrete patterns to start replacing the manual busywork on your own stack. It pairs with [MCP from Scratch](/guides/mcp-from-scratch) for the protocol and [Running the Fleet](/guides/running-the-fleet) for orchestration. This one is about pointing all of that at pipeline. _This is a living document and will be updated as the tools and patterns evolve._

Read guide
AI Project Management: Shipping Software When Agents Write the Code

AI Project Management: Shipping Software When Agents Write the Code

Something strange happened to my job this year. The typing got cheap. An agent can turn a paragraph of intent into a working pull request while I refill my coffee, and yet the projects did not get faster. Not really. More code shipped, more PRs merged, and somehow the same features took roughly the same number of weeks to actually land. That gap is what this guide is about. When machines write the code, the scarce thing is no longer the writing. It's the specifying, the slicing-up, and the reviewing. Project management stopped being about handing out work and started being about feeding agents instructions clear enough that their output is worth keeping, then catching the parts that aren't. I've been running this way for a while now: specs before code, work cut into agent-sized pieces, a small fleet on separate worktrees, and a review loop that assumes the machine got something subtly wrong. This is the playbook I wish someone had handed me. It covers spec-driven development, decomposition, acceptance criteria an agent can test against, parallelism without chaos, the review loop, governance for code you didn't write, and the handful of metrics that tell you whether any of it is actually working. It's written for engineers and tech leads who already use agents to write code and want to run real projects with them, not demos. _This is a living document and will be updated as the tools and the workflows keep evolving._

Read guide
Mastering Hermes

Mastering Hermes

Most of this series treats Hermes as the place its ideas land. Building Your Agentic OS pivots to it, Running the Fleet orchestrates on it, Self-Hosting the Agentic Stack deploys it. What none of them do is sit down and cover Hermes itself, the whole thing, every feature, the way I'd walk a competent developer through a tool they've never run in anger. That's this guide. Hermes is Nous Research's open-source, self-hosted agent, the one with a built-in learning loop: it writes its own skills from experience, curates its own memory, searches its own past conversations, and builds a deepening model of who you are across sessions. It installs with one command, runs on a five-dollar box or a GPU cluster, talks to whatever model you point it at, and you can message it from Telegram while it works on a cloud VM. That surface is a lot bigger than the rest of the series has needed to show. So here we go wide instead of deep: install and first contact, the model layer and Nous Portal, the terminal interface, the messaging gateway across six platforms, the six places it can run, the learning loop, context files and personality, tools and toolsets, MCP, scheduled automations, delegation and subagents, the security model, day-two operations, and migrating in from OpenClaw. Where a topic has its own field guide in this series, I point you there instead of repeating it. This is the manual that ties the rest together. _This is a living document and will be updated as Hermes updates._

Read guide