Commander's Intent for AI Agents

The first time I watched someone fight with an AI agent, it felt painfully familiar.

They had written a two-hundred-word prompt. Step one, do this. Step two, do exactly that. Step three, do not under any circumstances deviate. The model dutifully marched through all of it — and produced something almost right but slightly wrong, because step two had assumed a world that no longer existed by the time the agent got there. So they rewrote step two. New problem downstream. They spent an hour patching a script that was supposed to save them an hour.

I recognized it because I spent twelve years in the Army watching the same failure mode play out with people. The lieutenant who writes an order so detailed that the moment the enemy does something unexpected, the whole plan seizes up. We have a name for the antidote: commander's intent. It is the single most useful mental model I have for directing AI.

What the Army actually figured out

Here is the thing about combat that translates better than you'd think: the plan never survives contact. Ever. Reality is too chaotic, the other side gets a vote, and the person standing at the objective always knows more about what's actually happening than the person who wrote the plan back at headquarters.

The doctrine the modern Army runs on — mission command — solves for that. A commander doesn't hand subordinates a script. He gives them intent: a crisp statement of the end state and, crucially, why it matters. Then he trusts the people closest to the problem to figure out the how.

The "why" is the load-bearing part. When a squad leader knows the intent is "deny the enemy the high ground so the convoy can pass safely by dawn," he can improvise. The bridge is out? He finds another route. He never needed me to anticipate the bridge being out. He needed to understand the point.

A step-by-step order tells someone what to do. Intent tells them what done looks like and why it matters — which is the only thing that lets them make good decisions you never thought to plan for.

The same thing is true for AI

Most people who struggle with AI agents are writing five-paragraph orders: rigid, over-specified prompts that try to anticipate every step. Then they're surprised the model can't recover from a situation they didn't foresee — because they never told it where it was going or why.

The operators who get extraordinary work out of these tools state the end state clearly, explain why it matters, give the constraints that actually matter, and let the model find the path. Then they verify the result against the intent, not against a checklist of steps.

I learned this the slow way building this very website. I'm a COO, not an engineer. Early on I tried to spoon-feed Claude Code line by line, and it was miserable — a non-technical person pretending to be a technical lead, badly. The turn came when I switched from orders to intent: "I want readers to share a blog post to LinkedIn without friction. Here's the brand. It has to feel native to the site and it can't break the layout. Figure out the cleanest way." The agent made a dozen small decisions I would never have specified correctly — and most were better than what I'd have asked for.

Mapping it, concept by concept

The mapping is specific, and that's what makes it useful.

Commander's intent → end state plus the why. Open your prompt with what "done" looks like and why it matters. Not the steps. That single move does more for output quality than any prompt-engineering trick I know.

Decentralized execution → let the agent choose the steps. If you're writing "first do X, then Y, then Z," ask whether you care about the sequence or just the outcome. Usually it's the outcome. Over-specifying the path strips the model of exactly the judgment you're paying for.

The plan never survives contact → expect to iterate. When the first attempt comes back wrong, the intent is your anchor. You don't rewrite the whole order. You say "good, but that drifted from the point — the point was X," and let it re-route.

After-action review → get honest about the gap. After every operation the Army runs an AAR: what was supposed to happen, what happened, why the gap. No egos. I run the same loop with AI. When an agent produces something off, I don't just patch the output — I figure out why my intent was ambiguous, and I fix the intent. The next iteration is sharper because I got more honest, not because I wrote more rules.

Trust, but verify → delegation is not abdication. This is the one people get wrong in the other direction. Giving intent does not mean you stop owning the outcome. When I built the crypto strategy I've written about, I gave the agent a lot of latitude to design and run backtests — but I read the logic, sanity-checked the numbers, and killed approaches that looked good but were overfit. The commander owns the result whether or not he wrote every step. So do you.

Why this is an operator's edge, not a prompt trick

The instinct of a smart, controlling executive — and most of us are smart and controlling — is to tighten the leash when the stakes go up. More detail, more constraints, more steps. With people that backfires. With AI it backfires the same way.

The skill that matters is the thing good commanders have always had: articulate a clear end state, explain why it matters, trust execution to the entity closest to the work — and never pretend that trust relieves you of owning the result. That's a judgment skill, not a technical one, which is exactly why operators are positioned to be great at this. You already know how to give intent to a team. The agent is just a new kind of subordinate — fast, tireless, occasionally brilliant, occasionally confidently wrong — that rewards the same discipline.

If you're directing AI this way already, or fighting with it the old way, I want to hear about it — drop it in the comments. And if you want to think through what commander's intent looks like for your specific work, reach out through the contact page. That conversation is one of my favorites to have.