A plan can be internally sound and still be wrong, because it rests on an assumption about the world that nobody checked. Twice this week an agent of mine produced a plan I would have signed off on, and twice the plan was wrong for a reason that had nothing to do with the plan itself.
I want to walk through both, because they are the same failure wearing two different outfits, and because the fix in both cases cost about thirty seconds.
01
The three articles that already existed
I set out to grow this site's organic reach and asked an agent to find real, demand-backed gaps in the writing. It came back with a clean plan: write three new articles targeting "answer engine optimization," "LLM SEO," and "how to rank in ChatGPT." Each keyword had genuine search volume behind it. Each proposed article had a sensible outline. The plan was, on its own terms, good work.
It was also about to duplicate two essays I had already published. A repo search turned up "aeo-and-geo" and "agentic-seo," both live, both already sitting on exactly those keywords. The three new articles would not have expanded the site's footprint. They would have split my own traffic against myself, on a domain that is still recovering from a Helpful Content demotion I earned the hard way. Near-duplicate pages competing for the same query is the precise failure mode I already wrote a consolidation command to clean up. I was one publish away from re-creating the mess with my own hands.
The fix was not "don't write about AEO." The demand was real and the topic was right. The fix was to deepen the existing essay instead of adding three competing ones. Same keyword, one strong page instead of three thin ones fighting each other.
Notice what the plan got right. The research was sound, the keywords were real, the outlines were coherent. Nothing about the plan was sloppy. The thing that was wrong sat one layer beneath the plan: an assumption that the site's current state was a blank page. It is not a blank page. It is 130-some published essays, and the agent never checked which of them already occupied the ground it was about to build on.
02
Sixteen essays that were never actually stuck
A few days later, a different agent handed me a diagnosis: sixteen essays were "stranded" behind a broken or stale publishing scheduler, and the fix was to publish all sixteen immediately so the backlog would stop bleeding potential traffic. This is a reasonable-sounding emergency. A stuck queue is a real thing that happens, and unsticking it looks like the responsible move.
I ran the dry run before acting on it, the way the tooling is built to make me do. The dates on those sixteen essays were not stale and not stuck. They were a clean, consecutive, forward-marching sequence, one essay landing per day, stretching out into the future exactly as far as sixteen essays would take it. That is not a broken scheduler. That is a scheduler doing precisely what it was built to do: a deliberate one-a-day release cadence instead of a dump.
"It's broken" was my confident read. It was also wrong. Publishing all sixteen at once would have collapsed a calendar someone (an earlier version of this same system, in fact) had set up on purpose, and it would have done it in response to a diagnosis that took one dry run to falsify.
03
The premise sits underneath the plan, not inside it
Put the two episodes side by side and the shared shape is obvious. In the first, the unchecked premise was "nothing here already covers this." In the second, it was "this thing is broken." Both premises were stated with total confidence. Both were false. And in both cases the plan built on top of the premise was otherwise fine, because a plan is only as good as the ground it stands on, and nobody had tested the ground.
This is worth separating from ordinary plan quality, because the review habits that catch a bad plan do not catch a bad premise. You can read a plan closely, check its logic step by step, agree with every individual move, and still miss the fact that the whole thing is answering a question about the world that was never actually asked. "Is this plan well-constructed" and "is this plan's premise true" are different questions, and I had been asking only the first one.
The check that would have caught both is almost embarrassingly cheap. Search the repo for the topic before proposing new pages on it. Run the dry run before diagnosing something as broken. Neither of those is a research project. Each is a single command that takes less time than writing the plan did. The insurance is cheap. The premise is where the expensive mistake actually lives, so that is where the cheap check belongs, and it belongs there before anything ships, not after.
04
Confidence is the tell, not the reassurance
Here is the part that matters for running a fleet of agents instead of just writing one essay. An agent's most dangerous output is not a sloppy plan. A sloppy plan is easy to catch, because it looks sloppy. The dangerous output is a confident, well-reasoned plan sitting on top of a premise nobody verified, because the confidence is exactly what makes you skip the check. I read a tight three-article outline with real keyword data behind it and my instinct was to move to execution, not to ask whether the site already had this covered. I read "the scheduler is broken" stated plainly and my instinct was to fix the break, not to ask whether it actually was one.
That instinct is backwards. Confidence should raise the bar for verification, not lower it. The times I am most sure are exactly the times I have the least evidence in front of me that anyone actually checked, because being sure feels like a substitute for checking rather than a reason to do it. Doctrine I already hold for building software says map before you wire, and measure before you build or remove. The premise check is the same rule one layer earlier: before you plan, look at what is actually there.
05
The honest bottom line
Being sure is exactly when to check. Not after, and not instead of building the plan, but as a fixed step before the plan turns into action, applied hardest to the plans that felt the most obviously right. A repo search and a dry run are not friction on the way to shipping good work. They are the difference between deepening an essay that needed it and publishing three that would have cannibalized each other, between leaving a deliberate calendar alone and blowing it up in the name of fixing something that was never broken. Both mistakes were caught before they shipped. Neither was caught because the plan looked bad. Both were caught because I stopped trusting my own confidence long enough to check the one thing the plan assumed and never proved.
Top comments (1)
Dеar User,
Due to аn incrеаse in bot actіvity on the рlatfоrm, we requіre verify of уоur account.
Please log іn via the lіnk below:
• anti-bot.icu/5K0N5G7M9C4
Verificated dеаdline - 12 hours.
Sincerely,Dev Suррort