Commander's Intent for AI Agents

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

They had written a prompt that ran maybe two hundred words. Step one, do this. Step two, do exactly that. Step three, then this other thing, and 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 did not exist 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 exact same failure mode play out with people. The lieutenant who writes a five-paragraph order so detailed that the moment the enemy does something unexpected, the whole plan seizes up. We have a name for the antidote. It is called commander's intent, and 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 would 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 is actually happening than the person who wrote the plan back at headquarters.

So the doctrine the modern Army runs on — they call it mission command — solves for that. A commander does not hand subordinates a script. He gives them intent: a crisp statement of the end state we are trying to reach and, crucially, *why* it matters. Then he trusts the people closest to the problem to figure out the how. We call that decentralized execution and disciplined initiative. Fancy words for: I told you where we need to end up and why, now you adapt.

The "why" is the load-bearing part. When a squad leader knows that 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, brittle, over-specified prompts that try to anticipate every step. And then they are surprised when 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 do something different. They state the end state clearly. They explain why it matters. They give the constraints that actually matter and leave out the ones that don't. And then they let the model find the path — and verify the result against the intent, not against a checklist of steps.

I learned this the slow way building this very website. I am a COO, not an engineer. I cannot write the code myself. Early on I would try to spoon-feed Claude Code line by line, and it was miserable — I was a non-technical person pretending to be a technical lead, and badly. The turn came when I stopped giving orders and started giving intent. "I want readers to be able to share a single blog post to LinkedIn without friction. Here is the brand. Here is what matters: it has to feel native to the site and it cannot break the existing layout. Figure out the cleanest way." The agent made a dozen small decisions I would never have specified correctly, and most of them were better than what I'd have asked for.

Mapping it, concept by concept

I don't want to wave at the analogy and call it a day. The mapping is specific, and that is what makes it useful.

Commander's intent → end state plus the why. Open your prompt with what "done" looks like and why it matters to you. Not the steps. The destination and the stakes. 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 find yourself writing "first do X, then Y, then Z," stop and ask whether you actually care about the sequence or just the outcome. Usually you only care about 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. Your first prompt is a plan, and it will meet reality. 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 you let it re-route.

After-action review → review the output honestly. In the Army, after every operation, you sit down and run an AAR: what was supposed to happen, what actually happened, why the gap, what we do differently. No egos. I run the same loop with AI. When an agent produces something off, I don't just patch it — 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 and letting the agent run does not mean you stop owning the outcome. You absolutely still check the work. When I built the crypto strategy I've written about, I let the agent design and run backtests with a lot of latitude — but I read the logic, I sanity-checked the numbers, and I killed approaches that looked good and were actually 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

I keep coming back to this with founders and operators I advise, because it reframes the whole relationship. 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 not knowing the perfect incantation. It is the thing good commanders have always had: the ability to articulate a clear end state, explain why it matters, and then trust execution to the entity closest to the work — while never pretending that trust relieves you of owning the result.

That is 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 the specific work you're trying to get out of these tools, reach out through the contact page. That conversation is one of my favorites to have.