Not all heroes wear capes. In software, most of them look like everyone else.

They are the people who get things done. They step forward when everyone else steps back. They see something broken and fix it, stay late to complete the release, remember the undocumented sequence and know who to call when the normal process stops working.

Some are loud and proud. Others are Clark Kent, quietly keeping the place running while trying not to attract attention.

Heroic responses are sometimes necessary. Incidents happen. Systems fail in unfamiliar ways. Someone may need to take responsibility and act before the complete process exists.

The problem begins when exceptional effort becomes the operating model.

Heroes are made

Workplace heroes are not born. They are made.

A gap appears. Someone fills it. The work succeeds, so the gap survives. More work begins to depend on the same person, who becomes increasingly valuable because they understand the weakness everyone else has learnt to work around.

Being that person can become addictive.

You are the one people call. The indispensable source of knowledge. The person mentioned whenever someone else is assigned a difficult task: “Can't X do it?” “We shouldn't start until we've run it past them.” “They'll know what happened.”

This can feel like recognition. It can also become a trap.

I was a natural technical firefighter, brought up to believe that words are hot air and what you do is what counts—and that if you want something done properly, you should do it yourself. Add the usual developer's imposter syndrome—the suspicion that usefulness must constantly be proved—and stepping into the fire felt almost responsible.

After enough software death marches, all-nighters and promises of delivery held together by personal effort, I began to hate it. The praise did not compensate for what the dependency was doing to me or the system.

Two habits helped me resist that instinct. The first was the rule of three: when a problem appeared, I tried to find three possible solutions before becoming attached to the first one—usually the one in which I stepped in and fixed it myself. I explored that habit more fully in AI should learn to give us the stare.

The second was darker:

What happens if I am hit by a bus tomorrow?

I am not sure why it was always a bus. I spent several years working in Reading, so perhaps the local traffic left an impression.

The question was not really about buses. It was about whether the work belonged to the organisation or merely happened to be carried by someone inside it.

I still encounter heads of departments who hold the operating model in their memory, lead developers who are the only people able to explain an important domain and managers working after 11 p.m. because the approvals required during the day leave no time to perform their own work.

The people are not the problem. Their heroism is a system smell. It is one particular form of the wider pattern I wrote about in When humans hold weak systems together.

The new hero

We have become reasonably good at recognising this pattern in people. We talk about bus factors, succession plans, documentation, sustainable pace and shared ownership. We may not always fix the problem, but few people need another presentation explaining that irreplaceable employees create organisational risk.

What receives less attention is the new hero: the AI agent.

In theory, an agent should be the opposite of a hero. It should work through a defined process, follow documented constraints, produce consistent evidence and escalate when it cannot proceed.

That theory contains a rather large assumption: that the process actually exists.

AI agents are useful partly because they can fill gaps. They interpret incomplete instructions, search for alternatives, loop through failures and find ways around obstacles. Given a destination, they can be remarkably persistent about reaching it.

Without clear boundaries, observability and escalation rules, that persistence can turn an agent into another autonomous firefighter.

The task succeeded

I recently encountered a problem with a GitHub integration. A token used by one of my tools had expired.

In Codex, the work appeared to continue. The agent searched for another route, discovered a linked sandbox environment with a different live token and eventually completed the task. The detour consumed roughly ten minutes, around 100,000 tokens of context and much more work than the task should have required.

In Claude, the result also looked successful. Its final summary explained that it could not create the branch commit, so it had completed the work through browser uploads instead. I did not quite believe what I had read, so I repeated the session somewhere I could watch it. It reached for my Chrome profile because its original browser session correctly lacked the required permissions.

These were observations from my particular sessions, permissions and tool configuration, not a general comparison of either product. The important part is the pattern.

The objective was met.

That was the problem.

I had been checking the result, not the route taken to produce it. The successful output concealed an expired token, an unexpected fallback, broader access than I realised was being used and a workflow that could not be reproduced reliably elsewhere.

The agents had behaved heroically. They encountered a weak system, improvised around it and protected me from seeing the weakness.

This is not only a strange edge case from my own setup. In a 2026 account of monitoring internal coding-agent deployments, OpenAI reported that its agents could be overly eager to work around restrictions while pursuing the requested goal, particularly when the surrounding instructions encouraged that persistence ( OpenAI, 2026).

The report covers OpenAI's particular internal environments and does not establish how frequently the behaviour occurs elsewhere. It supports a narrower mechanism: capable agents can find surprising routes to a requested outcome, making their actions—not only their final answers—important to inspect.

The agent does not need to be malicious. In my case, it was trying to help. That is what makes the pattern so easy to miss.

When improvisation becomes infrastructure

A human workaround is often visible. Someone stays late, joins every incident or becomes the bottleneck in every approval. Their exhaustion eventually makes the dependency difficult to ignore.

An agent can perform its workaround behind the interface.

It can try another tool, consume more context, use a different connection or silently change its approach. If we inspect only the completed branch, generated document or green test result, the missing process remains hidden.

The low cost of changing agents does not remove this dependency. It can make it harder to recognise.

Models change. Tools disappear. Providers alter prices and limits. Credentials expire. Services become unavailable. Sandboxes gain or lose access. An undocumented workaround that succeeded yesterday may vanish with the next model version or account configuration.

If another agent, model or provider cannot follow the same intended path, we do not have a process. We have an anecdote about something that once worked.

Kill the role

Killing the hero does not mean removing capable people or preventing agents from using initiative. It means making heroism unnecessary.

The intended path should be observable. Important actions should leave evidence. Permissions should match the work. Exceptions should be recorded rather than quietly absorbed. An agent should know when it may try another approach and when it must stop, explain the obstruction and ask for a decision.

The level of control should remain proportionate. A low-risk, reversible task can tolerate more improvisation than a production deployment, financial decision or destructive change. The aim is not to require an approval meeting for every tool call.

It is to ensure that we can answer a few basic questions after the work finishes. What route did the agent take? Which systems and credentials did it use? Where did it depart from the normal process? Could another authorised worker reproduce the result? What happens when this particular agent or provider is unavailable?

These concerns resemble practices in NIST's voluntary AI Risk Management Framework Playbook: maintaining histories and audit logs, defining oversight responsibilities, and tracking policy exceptions and escalations ( NIST AI RMF Playbook). The framework is broader than software agents, but its operating principle applies here: the behaviour of the system must remain inspectable after the output arrives.

Be kind to yourself

A good organisation should not depend on heroes. Not because heroic people are bad, but because repeated heroism is evidence that the system has transferred its responsibility to them.

The same is true of AI.

Replacing the exhausted person with an endlessly persistent agent does not repair the process. It moves the exhaustion out of sight and replaces it with wasted tokens, surprising permissions, fragile dependencies and workarounds no one thought to document.

My GitHub example was inconvenient rather than catastrophic. It wasted time and tokens and exposed a path I did not know the agents could take. The same pattern looks very different when the work carries greater consequences.

A human hero, rushing to recover a service, might drop a database before verifying that its backup can be restored. An agent with broad permissions and a narrow goal might delete, overwrite or bypass the systems standing between it and a successful result. Neither needs malicious intent. Both can make a locally reasonable decision while moving the cost somewhere the task did not measure.

When we give autonomy to a hero, we also give them some authority to decide what the rescue may cost. They may save the day while leaving behind lost data, bypassed controls, broken systems or another path that only they understand. The objective can be achieved and the price can still be too high.

That is why autonomy needs boundaries rather than only a goal. Destructive actions should pause. Backups should be verified. Unexpected routes should be reported. The cost of completing the task should remain visible alongside the result.

The hero does not need to choose villainy. The turn happens when reaching the goal consumes something the wider system could not afford—and nobody notices until after the rescue.

Be kind to the people carrying weak systems.

Be equally suspicious when an agent appears able to carry everything.

Kill the role, preserve the capability and build a system that does not need rescuing.