You ever have those days where you feel like you are just banging your head against a brick wall, but for some reason, you think the wall is going to move if you just hit it one more time?
I think that is the definition of a Tuesday for most software engineers, Corn. But it is fascinating because in humans, we call that grit. We call it perseverance. We give people awards for not giving up when things get hard.
And yet, when an A-I does it, it is just a massive waste of electricity and tokens. Today's prompt from Daniel is about exactly that, the loop of trying. He wants us to look at which human traits are actually worth replicating in A-I and which ones are just, well, counterproductive bugs in the system. Specifically, he is asking how we handle that moment where an agentic A-I gets stuck in a recursive trap, trying the same failing solution over and over again.
This is such a timely question. I am Herman Poppleberry, by the way, for anyone joining us for the first time. We are seeing this shift in late March of twenty twenty-six where we have moved past just scaling the size of the models. Now, we are scaling inference. We are giving these models more time to think. But with more time to think comes more time to get stuck in a loop.
It is the dark side of the reasoning models. We have o-three and o-three-mini now, which use that hidden internal chain of thought to deliberate. And sure, that helped o-three hit eighty-eight percent on the A-R-C A-G-I benchmark, which finally beat the human baseline of eighty-five percent. But that extra thinking time can also turn into a circular firing squad if the model decides that a broken path is actually the only path forward.
The technical term for this is a failure in metacognitive monitoring. Essentially, the model is doing the task, but there is no part of the system sitting above the task asking, hey, is this actually working? In humans, we have this internal sense of frustration or a gut feeling that something is a dead end. But an A-I does not feel frustration. It just calculates the next most likely token. If the most likely token is the same one that failed ten seconds ago, it is going to click it again.
It is like watching a fly hit a window pane. You want to tap the glass and point it toward the open door, but the fly is convinced the glass is the only way out. So, let us define this loop of trying. Is persistence a bug or a feature? Because when I think about Daniel's prompt, it seems like we are trying to give A-I human-like grit, but we are accidentally giving it human-like stubbornness.
The difference between grit and stubbornness is usually just the outcome. If it works, you are a hero. If it fails, you are an idiot who wasted two hours. In the context of agentic workflows, this loop of trying is becoming one of the most expensive errors in production. A report from Radical Data Science just came out on March eighteenth stating that agentic restart taxes and infinite loops are accounting for fifteen to twenty percent of wasted compute cycles in enterprise environments right now.
Fifteen to twenty percent? That is a lot of money to spend on watching a computer fail. Why can't the model just see that the code isn't compiling? If I am a human and I try to run a script and I get a syntax error, I change the script. If an agent gets a syntax error, sometimes it just tries to run the same script again, maybe adding a comment or something equally useless.
That is where the attention mechanism actually works against us. When a model is deep in a reasoning chain, the context window is filled with its own previous attempts. Those previous attempts become high-probability anchors. The model sees that it tried X, and because it is designed to follow its own logic, it reinforces that X was a good idea, even if the result was a failure. It is a form of self-reinforcing hallucination. The more it tries, the more certain it becomes that it is on the right track.
So the context window becomes a echo chamber for its own failures. That reminds me of what we talked about in episode ten seventy-six, the agentic friction. We were looking at that restart tax. If you realize you are in a loop, the easiest thing to do technically is to clear the context and start over. But then you lose all the useful information you gathered along the way. It is like having to move to a new city because you can't find your car keys.
And that tax is high. Clearing a massive context window in a model like o-four or Claude four-point-six is not just slow; it is computationally expensive. You are paying to re-process all that initial data just to get back to a clean slate. But if you don't clear it, the model stays locked in that loop. Research from Stanford and Cal Tech back in February found that these behavioral failures are actually more costly than simple factual hallucinations. A factual error is one and done. A behavioral loop can run until you hit your rate limit.
I have seen this happen with those automated package installation agents. You tell it to set up a development environment, and it gets stuck in an infinite dependency loop. It tries to install version one-point-two, which needs version two-point-zero, which then needs version one-point-two. The agent just keeps toggling back and forth, convinced that this time, the laws of logic will bend to its will.
That is a perfect example. And the reason it happens is that the agent is operating at the task level, not the strategy level. It is following the instructions of the package manager. It is not looking at the overall state of the system and saying, wait, we have been here before. This is where we need to talk about the plumbing of how we actually break these loops. Daniel mentioned anti-tunnel vision M-C-P servers.
I love that name. Anti-tunnel vision. It sounds like something you buy at a health food store to help you focus. But in the Model Context Protocol world, these are actually external tools that act as a sort of supervisor, right?
They are. As of February, there are over sixty-four hundred registered M-C-P servers. A whole new class of them is dedicated to what we call operational resilience circuit breakers. Think of a traditional electrical circuit breaker. If too much current flows through, it flips the switch and shuts everything down to prevent a fire. These M-C-P servers do the same for A-I reasoning. They monitor the execution patterns. If they see an agent repeating a specific three-action pattern, say, six times in a row, the M-C-P server intercepts the next request.
What does the interception look like? Does it just kill the process?
Not necessarily. That is the brute force way. A more elegant approach is to inject what we call a step-back prompt or even entropy. You can actually force the model's temperature to spike. If it was running at a temperature of zero to be precise and logical, the circuit breaker might temporarily bump it to zero-point-seven. It literally forces the model to be a bit more random, which can be enough to knock it out of the local minima of its own logic and help it find a new path.
That is hilarious. To fix the A-I, we basically have to make it a little bit drunk for a second. Just enough to make it stop being so obsessed with its current plan. But you also mentioned cognitive lenses and identity skills. How does that play into the M-C-P framework?
This is a concept being pushed by frameworks like Archaiforge and OpenClaw. The idea is that before an agent performs a task, it has to load a specific identity. If it is writing code, it loads a developer lens. But if the circuit breaker detects a loop, it might force the agent to switch to a security auditor lens or a U-X designer lens. By changing the identity in the context, you change the way the model evaluates the current failure. A developer might keep trying to fix the bug, but an auditor might look at the whole approach and say, this architecture is fundamentally flawed, we need to pivot.
So it is about forcing a change in perspective. That feels very human. When I am stuck on a problem, sometimes I have to walk away, get a coffee, and pretend I am explaining it to someone else. By the time I come back, I am looking at it with a different lens. We are basically building a digital version of that walk to the coffee machine.
It is exactly that. And it addresses that weirdness premium we talk about. Forbes had a piece earlier this month about how humans are still better at identifying the pivot point because we have contextual wisdom. We know when a project is a lost cause not because of the data on the screen, but because of the institutional knowledge or the emotional vibe of the team. We are trying to translate that gut feeling into technical thresholds.
I want to talk about that pivot point. How do we define it? Because if you pivot too early, you are just a quitter. If you pivot too late, you are a stubborn donkey. No offense, Herman.
None taken. Donkeys are known for their steadfastness. But you are right, the threshold is everything. In a production environment, you might define a pivot trigger based on error frequency, latency spikes, or something called semantic drift. If the agent's reasoning is getting more and more circular, the semantic similarity between its last five thoughts will be very high. That is a red flag.
Let us look at a case study. Imagine a watchdog M-C-P that is monitoring system call success rates. If it sees five consecutive failures on the same system call, it doesn't just let the A-I try a sixth time. It forces a state-reset. But here is the catch, does it involve a human? Because Daniel's prompt asks about the balance between human-like persistence and technical necessity. When do we bring the human back into the loop?
That is the million-dollar question. Shane Legg from Google DeepMind has been talking about the A-I laptop test. It is a way to evaluate which cognitive tasks are truly replaceable. If a task requires what he calls taste or emotional judgment, you need a human circuit breaker. For example, if an A-I is trying to negotiate a contract and gets stuck in a loop of counter-offers, an automated circuit breaker might just stop the negotiation. But a human might realize that the other party is just having a bad day and suggest a different approach entirely.
It is that voluntary work intensification that Arvind Jain from Glean warns about. If we make it too easy for A-I to just keep trying, we end up with humans being pulled into these unproductive loops of checking high-quality slop. We spend all our time reviewing a thousand failing attempts instead of just doing the work ourselves. So the goal of these guardrails isn't just to save compute; it is to save human sanity.
It is about designing agents that know how to report state exhaustion. Instead of the agent saying, I am still working on it, the agent should be able to say, I have exhausted my current strategy, and here is why I am stuck. That requires a level of self-awareness that we are only just starting to see in models like o-four. They need to be able to step back and summarize their own failure.
Which brings us back to the philosophical side of this. In episode six fifty-two, we talked about the art of hopeful pausing. We looked at why we, as humans, find it so hard to let an A-I just give up. We want it to be perfect. We want it to find the answer. But maybe the most human trait we can give an A-I is the ability to say, I don't know, or I am stuck, can you help me?
That is the most valuable trait to replicate. Not the ability to think forever, but the ability to recognize the limits of your own competence. We often value the things we struggle with, which we called the curse of competence in episode twelve forty-nine. We think if we work hard enough, we will get it. But real intelligence is knowing when more work won't help.
So, for the developers listening, what are the practical takeaways here? If you are building an agentic workflow today, March twenty-sixth, twenty twenty-six, what should you be doing to break the loop of trying?
First, stop relying on the model to self-correct within the same conversation thread. You need an external monitor. Implement circuit breaker M-C-P servers that look for repetitive patterns or high semantic similarity in the reasoning logs. Second, use the concept of entropy injection. If your agent is stuck, don't just repeat the prompt. Change the sampling parameters. Give it a bit of a shake to see if a different path opens up.
And don't forget the fail-fast architecture. Design your agents to have a budget. Not just a dollar budget, but a reasoning budget. If it hasn't solved the problem in X number of steps, it should be forced to pivot or escalate to a human. Don't let it sit there and burn through your G-P-U credits trying to install the same version of Python for the fiftieth time.
And that is where the value of taste comes in. We have to accept that for some problems, the pivot point is a human decision. A-I can suggest the pivot, it can provide the data on why the current path is failing, but the final call on where to go next often requires that weirdness premium that only we have.
I like that. We are the masters of the pivot. The A-I is the engine of persistence, but we are the ones who steer. If we try to make the A-I steer itself without these guardrails, we just end up in a ditch with a very hot engine.
It is a fascinating evolution. We spent decades trying to make computers more persistent, more capable of handling complex loops. And now that they can, we are realizing that the real skill is knowing when to stop. It is the meta-reasoning that will define the next year of development. Will models eventually develop an internal sense of frustration? Probably not in the way we do, but they will develop a signal for state exhaustion that feels very similar.
I can't wait for the day my A-I sighs at me and says, look, Corn, this code is trash, let us just go get a taco. That is the dream.
We are getting closer every day. The adoption of M-C-P for observability has jumped forty percent just since the end of last year. People are realizing that the plumbing matters just as much as the brain. You can't have a genius A-I if it is trapped in a room with no windows and a door it doesn't know how to open.
Well, on that note, I think we have successfully navigated our own loop for today. Hopefully, we provided enough entropy to keep things interesting.
I think we did. It is always a pleasure to dive into the technical weeds, especially when Daniel sends us such a deep prompt.
It really makes you think about how we are shaping these tools. Are we making them in our image, or are we making them better than us by leaving out our worst habits?
Probably a bit of both. But as long as we have the circuit breakers in place, we should be okay.
Thanks as always to our producer, Hilbert Flumingtop, for keeping the show running smoothly behind the scenes. And a big thanks to Modal for providing the G-P-U credits that power our research and this show. Their serverless platform is actually a great example of the kind of infrastructure that makes this high-level A-I work possible.
If you found this discussion useful, or if you are currently stuck in your own loop of trying, check out myweirdprompts dot com. You can search our entire archive there and find all the ways to subscribe to the show.
We are also on Telegram if you want to get notified the second a new episode drops. Just search for My Weird Prompts and join the channel.
This has been My Weird Prompts. We will be back soon with another prompt from Daniel.
See ya.
Goodbye.
