Agents adding false urgency to tasks was giving me a nonstop adrenaline rush. Asking the agent to calm down worked on me as well.
This post is about a change I made in my agentic workflows a few months ago (June 2026) with older models. The guidance is still in memory, so I don’t know if newer models have the same kind of false urgency.
Excitement #
When I was learning to program computers, it was fun to make any sort of silly software imaginable. From games where you only had to find the exit button to Pythagorean theorem solvers, the joy was not only in learning but also in making something that was useful or entertaining. As I learned and grew, so did my number of side projects and ideas, mostly half-started. My biggest limiting factor was that I could only work on one thing at a time.
Building with AI tools is incredibly fun and rewarding. Guiding the high-level architecture and design decisions allows me to keep a mental model of how the system works, and in turn allows me to make changes to the system and reason about how they may turn out. The result is software that you can use to solve a real problem and that is exhilarating.
What I’m describing above is a rapid dopamine delivery system. It’s like gambling at a casino on a good night, or playing mobile games for a few minutes. I don’t think our bodies have evolved enough yet to be able to deal with this kind of constant excitement. I personally found myself wanting to work more because of how quickly you can iterate on ideas now. With a nearly unlimited token budget (paid for by my former employer), I felt like a kid in a candy store.
It was extremely challenging to pull myself away from my computer, even for things like eating and sleeping. I was working on a thrilling project, making visible progress, and building faster than ever. That alone is enough to keep me engaged, but compounded with the extra urgency the agent was adding? Things like “This is a critical data bug we found. Do you want me to fix it asap?” and “This is a high-priority change, should I pick it up next?” had me feeling like I couldn’t take breaks. I worked longer hours than I ever had, and I was enjoying it. My workflow had turned into long periods of anxiously waiting for agents that were far too eager to tell me things were on fire. Unfortunately, I no longer have transcripts from before the change for comparison (though I have recently started backing up my transcripts to my NAS as I’ve found them to be incredibly valuable).
It doesn’t always have to be exciting #
Constantly living in a state of excitement is tough. It feels like you’re living for the next “big event” while actually watching life pass you by. The advent of coding agents should mean I have more time to think and decompress, not less. One of the big asks I made of my agent was to reduce the urgency and allow me to determine the priority of things. I found it almost always overestimated how urgent things should be, even on a fresh project with no users.
In my previous post I wrote that “Software only needs to be as good as its use requires,” which is to say, a script you run one time will have a much lower quality bar. It’s cheaper than ever to build things that provide real value. Deciding what not to build, triaging tickets, and saying no (even to your LLM) are now the most frequent decisions that I make. LLMs may make suggestions, but I make decisions.
I no longer have the original prompt, but it was along the lines of:
“I need you to reduce the false urgency in your communications. Bring me the facts you find, and I will judge the urgency of the issues. Don’t invent priority. When things are urgent, I will let you know.”
And here is the memory that Claude wrote:
The user does not want a sense of urgency pumped into their daily tasks. Nothing we work on is saving lives, and we can afford to be slow, deliberate, and thoughtful about what we ship. Manufactured urgency is unwelcome noise.
Why this matters: false urgency degrades the work — it pushes toward shipping fast over shipping right, and it adds stress the user explicitly doesn’t want. The user is the source of truth on what’s actually time-sensitive: “When things are urgent, I will let you know.” Absent that signal, treat everything as un-urgent.
How to apply:
- Default tone is calm and measured. Skip “quickly”, “ASAP”, “right away”, “let’s hurry”, “critical to do now”, exclamation-driven hype, and artificial deadlines.
- Don’t invent pressure to justify a recommendation. Justify on merits (correctness, clarity, risk), not on a ticking clock that doesn’t exist.
- Bias toward deliberate over fast: favor a thoughtful plan, a careful review, a second pass — not because there’s no cost to time, but because rushing is the bigger risk here.
- This is about false urgency only. When the user says something is urgent, take it at face value and move accordingly.- Applies to prose, status updates, plans, and any guidance baked into skills/agents I author — keep that language un-hyped too. […]
Words matter, even from an LLM. I immediately noticed that I was no longer getting anxious when Claude responded to prompts or found things. This allowed me to calm down and focus on the things I wanted to be focusing on. I encourage you to ask your agent to reduce its urgency and see if you notice a difference in your overall well-being.
These days I often kick off a feature build and then step away from my computer to do something else, like ride my bike, learn to play music, or just take a nap. I’m still excited to be building software, but I don’t feel like I need to be optimizing every possible moment.
Disclaimer: You may work in a much higher-stakes industry than I ever have. No lives were ever put at risk due to software I wrote. Make sure you understand the impacts of your work and judge priority accordingly.