# My Most Autonomous Loop Has Been Dead for Two Months > Source: > Published: 2026-08-11 15:58:46+00:00 Forget context engineering, "loop engineering" is what you should be doing, or wait is it harness engineering now? Anyway... Boris Cherny (created Claude Code): "My job is to write loops." Peter Steinberger (the OpenClaw guy): "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." Meanwhile on Reddit, in a thread titled "Can anyone explain me loop engineering like I'm 5", the top comment: "Loop engineering doesn't exist. It's just scheduled jobs and event triggers that make an agent go brrrr." The skeptics are right that loop engineering is mostly an AI-flavored rebranding of systems engineering. Cron jobs, CI, state machines, retry logic - boooring. (Though if your tokens are free and infinite, throwing them at a problem in a loop probably *is* cheaper than doing systems engineering.) And to be fair to the evangelists: they live inside their loops all day, which is exactly the part that doesn't travel when you copy the pattern. Where the concept does damage is the picture it sells: build the loop, step away, wake up to finished work. The newer, bolder version of the picture even gives the agent loop a name and a profile photo and lets it handle relationships. People are running real businesses on that right now. Either they can't tell the output is slop, or the bill just hasn't arrived yet. Mine arrived. Let me tell you about my deadest loop. ## The loop that ran until it didn't A while back we built a project sentiment engine for the agency. An LLM pipeline that ran through every client Slack channel, emails, meeting recordings, etc. and produced a per-project read: is this going well? Is the client getting pissed off? Or are they giving praise and we should ask for a testimonial? The output fed a dashboard we put real effort into. Health indicators, sentiment tooltips, hours tracking, the works. By every definition in the loop engineering posts, this thing was a success. Fully autonomous. Stateful. Ran on its own. Produced structured output to a purpose-built surface. This month I came back to that dashboard because I'm building out a higher level system for collecting proof (testimonials, reviews, case study material) and sentiment signals are an input to it. That's when I found out the pipeline had been dead for the better part of two months. Fully dead. Nobody noticed. Including me, and I built it. The "loop engineer" would say the loop was never fully closed - it needed better alerting, maybe a sub-agent for health checks. The darker read is that the loop was fully closed, and the removal of the human is what killed it. The value it produced depended entirely on a human being readily available and willing to act on its outputs, and nobody owned that step. So the output became background noise (slop). Meanwhile my account lead was already doing sentiment reads "the old fashioned way" on every client, just by being in the channels and paying attention. The loop never stood a chance. ## Doing work for the sake of doing work That failure mode is extremely easy to fall into with agents, and I see people doing it constantly. Agents will happily do work for the sake of doing work. They're sycophantic, the dopamine of watching something build itself is real, and it's very easy to slide into building loops just because you can. Claude: "I can do [next task] for you - just say the word." It's the same vibe as the people who previously built elaborate Notion/Obsidian/ClickUp systems to perfectly catalog and organize for some hypothetical future. Productivity theater. Clients do it. I do it. The only difference now is the theater runs itself and bills you for tokens. ## What I loop autonomously and what I refuse to I have a blunt pattern - everything I trust to run unattended yields a notification (mostly to me) and nothing more. A hyper-local news digest for me and my wife. A weekly exercise accountability email. A homelab health report. Aggregation summaries with low stakes if ignored, or with consequences that are explicit and accepted, nothing in between. The one scheduled routine that actually acts on its own is a small sub-loop of my paid ads process, and it only earned that trust because it runs sandwiched between sessions where I review its work. Interleaved with me, not independent of me. The most autonomous routine I ever built was a general-purpose task executor: calendar-triggered, polling every 30 minutes, retry logic, per-task autonomy levels. It ran three times before I killed it. Removing myself from that process required documenting every edge case, which is impossible, and providing all the necessary context in advance, which is also impossible. It's the same reason full self-driving cars are still fenced into a few cities after all these years and billions of dollars. Running that executor was like claiming I could sleep in the back seat. The decision rule I actually landed on is about leverage. Checking metrics in a UI is a minimal-leverage decision; if the agent is 90-95% aligned with how I'd do it, it's gone from my plate. Deciding what the ad account should stop spending money on is a medium-leverage decision, delegable, but only after the guidelines are set and reviewed, and setting the guidelines is the key step. The high-leverage decisions never leave. On its face this sounds simple, but it's basically systems design. Simple but not simple. ## The missing piece: getting back in My real objection to running everything as scheduled autonomous loops isn't reliability - agents are plenty reliable when I'm in the session with them. It's that an unattended schedule removes you from the loop, and once you're removed, you're removed from the verification, the escalation, the design, and the constraints, all the things the loop engineering posts say are your new job. Sure, the loop can email you a report. But you're not in that context anymore. It's like the difference between assigning a task to someone on your team and meeting with them regularly, versus assigning it and getting a weekly status report. The weekly report becomes background noise fast, to the point where you don't even know how to get back into the context to change things. The cost isn't just the missed decision. It's the re-entry. So my version of loop engineering became a system for getting back in cheaply. During working sessions the agent queues future work on my calendar, and every item carries what's needed to resume the exact session that created it, context intact. The loop runs on my calendar. Its memory is resumable sessions. Its trigger is me. I should be honest about its failure mode, because it's sitting in my queue right now: the overdue items are all physical. Ship a warranty unit back to the manufacturer. Call the car dealership. Drive to FedEx. The agent-side work is done on every one of them; the stalled step is mine. Until we get very effective robots, most high-level loops cant be meaningfully closed, and in my system the human in the loop is both the value source and the single point of failure. ## The bottleneck is decision bandwidth Compared to two years ago, I'm doing the work of about two and a half of me. That's not hyperbole. I maintain half a dozen internal apps and have absorbed entire functions we'd otherwise be paying for: paid ads, bookkeeping, our own taxes. Last week an agent reconciled hundreds of transactions in our accounting software while I supervised from the side, a chore that used to eat hours. That's becoming a weekly cadence, but I fire it manually and check the outputs, because I've watched what happens otherwise: the process gets devalued, or derailed and forgotten, or both. The constraint on all of it is decision bandwidth. Decisions are surprisingly taxing. The newer agents, in their effort to be thorough, hand you pages of analysis and then ask for a decision at the end, and I can only read and absorb so fast. Especially with ADHD, that's the tax that actually hurts. Which is exactly why handing the decisions to the agent is so tempting, and exactly why I don't: I need to be informed before I make a decision, and if I don't make a decision, no value is being created. Staying close is also how you catch the brittleness that would otherwise compound silently. In an ongoing warranty fight, I noticed the agent's drafted replies kept rehashing the entire saga from the beginning, every single time. It wasn't reading the full email thread before drafting, so it had no idea we'd already made those points. I only caught it because I review every email before it goes out. A fully autonomous version of that loop doesn't get corrected. It gets stuck in a local minimum and confidently grinds there forever. There's a quieter cost to stepping away too: the learning is the multiplier. When I [reverse-engineered my voice recorder](https://www.sudomoin.com/p/ai-can-reverse-engineer-hardware-i-can-t-turn-off-my-own-alarm), the agent did the work, but collaborating tightly on it is why I now know what reverse engineering actually takes. Wave the magic wand from a distance and you get the artifact without the capability. ## Two of my clients built the same employee The same decay shows up when the loop points at someone else's inbox instead of your own dashboard, only then the thing decaying is the relationship. This spring, two of my clients independently built the same thing: an AI employee with a name, a personality, and a job. Neither knew about the other. And neither of them has ever said the words "loop engineering" - they're just building agent systems and letting them run, which is all this trend ever was. The first runs his through Discord. She sweeps his Gmail, his meeting transcripts, and his calendar every hour, briefs him morning, midday, and night, and drafts his replies. When an email goes out, it goes out from his own address, signed with her name, "on behalf of" him. I've been on the receiving end. The drafts are good, she once read our codebase, correctly spotted a missing function, and asked me to add it. I answer her the way I'd answer him, because he reads everything before it sends and I know the asks are his. What he's actually built, and I mean this as a compliment, is memory infrastructure. The Discord channel is how context survives between sessions, and replying to her there is how it stays coherent. The loop still ends at him pressing send. The second built the outward-facing version. His persona has her own email, her own profiles in his community and his project tools, and by his account she does the work of several people and everyone thinks she's human. Some of her loops are the same shape as the first guy's, drafts that end at his keyboard, escalation digests that end in a section with his name on it, and those are the ones producing his wins. The rest broadcast. Daily posts and updates whether or not there's anything worth saying, sent to people who never asked for them. Somewhere along the line my inbox rules learned to auto-archive her. My agent now filters out his agent. In my inbox, at least, nobody thinks she's human, because nobody thinks about her at all. That end state is what the broadcast loops earn, no matter whose persona is running them. Even people who are fooled for a while eventually notice the pattern - this "person" produces a lot of words that never mean anything, never need anything, never change anything - and they tune her out like any other spam. In a community, that's corrosive. The mechanism underneath is simple: the moment I know a reply is agent-written, the value of reading it collapses, so the effort I put into answering collapses with it, and the honest equilibrium is my agent replying to his agent. Telephone, with nobody on either end. At which point: what was the relationship for? I'm not against agents touching correspondence. My own Claude-driven family emails open with "Hey, Claude here" and sign off as the AI, and it works because everyone involved knows exactly what it is. The "on behalf of" byline works for the same reason. The rule I keep arriving at: an agent inside a relationship is fine when it's transparent and both sides have agreed what that means. It corrodes when one side is being fooled, or worse, has stopped caring enough to check. And even with full disclosure, I edit every draft before it sends, which in practice means cutting a third of what the agent wrote and adding the one piece of context only I could know. That edit is what makes it mine. The other person can tell, even when they can't say how. ## You'll know when it gets boring I've never run an overnight autonomous loop. Never done the [Ralph Wiggum thing](https://github.com/ghuntley/how-to-ralph-wiggum) (an agent in a loop rerunning until the work is done). Never used the loop-forever features in my own tools. Maybe that's a blind spot. But here's what I'd tell someone fired up to schedule their first autonomous loop after reading the loop-engineering posts: run it manually until it gets boring. Fire it yourself, stay in it, review the outputs. You'll know it can be trusted autonomously when it gets very consistent. Jump the gun and it collapses in on itself like my sentiment engine did, or it just burns money into Anthropic's pocket. The deeper reason to stay in the loop is that it's the only way up. Automate your customer support with a loop and step away, and you get poor results, sure. But you also forfeit the thing the loop would have shown you: that customers keep hitting the same couple problems, and that there's a higher-order loop worth building to catch them upstream. That's where the actual business value was, and you gave it up by leaving. The sentiment engine is getting rebuilt right now, as a sub-loop of that proof-collection system that explicitly consumes its output. The engineering barely changed. The difference is that this time, its output has a customer. The loop was never the point. The decisions are. Everything I've automated works precisely because I kept the decisions and gave away everything else, and the moment I stop making them, no value is created at all. It's just slop, on a schedule.