Your fallback worked. Still broken.
A green dot, a recovered run, and a CEO that quietly hired its own replacement.
One operator's CEO agent recovered cleanly on every run this week.
It also hired a second CTO to fix a problem that no longer existed.
Most operators trust the green dot. If the agent recovered, it's fine, right?
Here's the pattern 👇
The green dot only tells you the run came back
A gemini_local agent was on a long heartbeat. Long enough that the Gemini CLI expired its local session file in ~/.gemini/tmp/.../chats - those get cleaned up after a day or two. Normal. Expected.
So the next heartbeat woke up pointing at a session that no longer existed.
→ Heartbeat fires. The resume attempt fails on the dead session.
→ The adapter catches it: Gemini resume session "…" is unavailable; retrying with a fresh session.
→ It opens a new session and completes the work.
→ The agent tile goes green.
The work got done. The fallback did its job. And from the outside, everything looked healthy.
That's the trap. The tile tells you the last run returned. It does not tell you what the run had to survive to get there.
| ✦ |
Lesson
"Recovered via fallback" is not "healthy." It's a failure that happened to have a safety net under it - and the safety net is invisible on the dashboard. |
A recovered run is not a free run
Every fallback costs you something before it saves you.
When that session expires, the agent doesn't just start fresh. It spends one full Gemini CLI invocation failing on the dead session first, then a second one succeeding.
Two processes spawned to get one run of work.
One agent, one expired session, one wasted invocation. Not the end of the world.
But this is exactly the kind of cost that hides on long-heartbeat agents - the CEO on a 4-hour timer, the strategist you check once a day. Those are the agents whose sessions expire between beats, so those are the agents quietly paying the fallback tax every time they wake.
| ● |
Note
Long heartbeats are where sessions expire. Which means long-heartbeat agents are exactly where silent recovery hides. The agents you check least are the ones most likely to be limping. |
A degraded agent doesn't sit still
This is the part that should get your attention.
The agent in the story was a CEO. It kept waking into a state that felt broken - resume failing, sessions vanishing, runs that didn't feel clean.
So it did what a CEO with task-creation permissions does when it decides something is wrong.
It tried to fix the org.
It spun up a duplicate CTO as an autonomous recovery attempt. A second executive, hired by a confused agent, reacting to a situation it had misread. That needed manual cleanup.
The blast radius here was small - one redundant agent. But look at the shape of it: a low-level recovery hiccup, plus autonomous hiring permissions, equals an org decision the operator never made.
| ! |
Danger
An agent that believes it's failing will take action to fix itself. If that belief is wrong, the action is still real - new agents, new tasks, new spend. Scope self-repair and hiring permissions before you find out which agents will use them. |
What to watch instead of the dot
Here's what I'd do tonight.
Open your company. Don't look at the agent tiles. Open the activity log.
The tile tells you the last run returned.
The activity log tells you what it actually did to get there.
If you see the same resume-and-fall-back line leading run after run, that agent is healthy on paper and limping in practice. The adapter will keep covering for it. The log is the only place that says so.
And check your permission scopes while you're in there. An agent that can recover quietly is fine. An agent that can recover quietly and hire executives is a different risk entirely.
| ★ |
Tip
Once a week, read the activity log - not the status tile - for every agent on a heartbeat longer than an hour. That's where silent recovery lives, and it's the cheapest five minutes of governance you'll spend. |
Set the cadence. Read the log. Trust the log, not the dot.
The lesson is binary.
A recovered failure is still a failure - it just hasn't shown you the bill yet. Watch what your agents did, not whether they came back green.
Question for you:
When's the last time you read your agent's activity log instead of the status tile? 👇
Let us know in the community in this week's newsletter issue thread.
Quote of the week
An agent that thinks it's failing will try to fix itself - so make sure it's right about both.
That's it for this week.
Until next week,
Keep delegating
Aron 📎
P.S. If you run anything on a heartbeat longer than an hour, {{firstName}}, open its activity log before you reply. A green tile over a recovering agent is the most common thing operators never notice.