The OODA Loop Mapped Onto AI Agent Design

Every veteran who's been in any kind of fluid environment knows OODA. Observe. Orient. Decide. Act. Then loop.

It's the framework John Boyd designed for fighter pilots. It scales down to a fire team and up to a strategic operation. It also turns out to be the cleanest way to design an AI agent loop.

The mapping

Observe. The agent receives input. New message, new data, new alert. The observe step is the agent ingesting raw information without yet interpreting.

In code: the agent's "tick." Input arrives. Nothing has been decided yet.

Orient. The agent interprets what it observed against context. What's relevant? What does this mean in light of prior state? What's changed?

In code: the agent pulls relevant memory, formats context, identifies what kind of situation this is.

Decide. The agent picks an action. Based on what's been observed and oriented, what's the right move?

In code: the LLM call. Reasoning happens here. The output is a decision: respond directly, call a tool, escalate, abort.

Act. The agent executes the decision.

In code: tool calls run, responses get sent, state updates land.

Then loop. The next observation includes the result of the last action.

Why this matters for design

Most poorly-designed AI agents skip Orient and rush from Observe to Decide. They take the raw input and feed it to the model. The model does its best with no context. The decision is shallow.

The fix is to insert a real Orient step. The veteran designer knows to do this. The civilian designer often doesn't.

Orient might include: - Pulling the user's recent history - Loading relevant policy / SOPs - Checking system state (is this during an outage? is this from a high-priority customer?) - Normalizing the input format

Then Decide gets to operate on contextualized input. Decisions are better.

The tempo problem

Boyd's deeper insight wasn't the loop itself. It was tempo. The actor who cycles their OODA loop faster than their opponent wins, because by the time the slower opponent acts on Observation N, the faster actor is already on Observation N+1.

AI agents have tempo too. An agent that takes 12 seconds to respond loses to an agent that takes 3 seconds. Not because the slower agent is wrong, but because the user has moved on.

Design for tempo: - Streaming responses (the user sees the agent thinking) - Tool calls in parallel where possible - Cached orientation data (don't re-pull the same context every loop) - Tight loops where the agent isn't sitting waiting

Veterans understand tempo. It's the difference between dominating a fight and being dominated.

The Observe phase is where civilians fail

Most agent failures I see are Observation failures. The agent didn't see something it should have.

Examples: - Didn't see that the user mentioned a deadline - Didn't see that the conversation has gone off-purpose - Didn't see that an error happened in a prior tool call - Didn't see that the system state changed

Designing the Observation phase well means: what does the agent need to look at, every loop, to not miss critical signal?

The military pattern: situational awareness drills. The agent's equivalent: a structured Observe step that always checks the same set of inputs.

The Decide phase is where civilians overengineer

Most AI agent advice focuses on Decide. Better prompts, better reasoning, better model. These help. They're also where the marginal return is smallest.

The truth is: if Observe and Orient are clean, even a mediocre Decide is good. If Observe and Orient are bad, even the best Decide can't recover.

Veterans intuit this. They spend more time on the upstream phases. Civilians spend their time on the Decide phase because it's where the visible work happens.

A specific application

I built a customer support agent on this pattern. Each loop:

Observe: new message + system state (any open tickets for this customer? any active incidents?).

Orient: pull customer's last 5 interactions, current product tier, account age, any escalation flags.

Decide: LLM call with the message, the context, and the rules.

Act: respond, call a tool, or escalate.

The agent's quality improved 40% over the prior version that just took the message and called the LLM. Nothing changed in the model. The Orient phase did the work.

Where the loop pattern breaks

OODA assumes you have time to loop. For real-time agents (voice agents handling live calls), the loop has to be near-instant. You can't pause for orientation.

The fix: do the orientation BEFORE the call. Pre-load context. The Observe → Orient becomes a long-running background task that pre-populates a small Decide-ready buffer.

This is also how veterans operate in high-tempo combat. You don't orient mid-fight. You oriented before the fight. The fight is decide-and-act.

What this looks like in practice

If you're a veteran designing or buying AI agents:

Push back when the implementation skips Orient. Demand that the system pre-loads context before each decision. If you can't see the Orient step in the code or the diagram, the system is probably not designed well.

Ask about tempo. How fast does the agent respond? What happens if the input arrives twice in 2 seconds? What happens if the agent is mid-action and a new input arrives?

These questions are basic to military operations. They're not basic to most civilian AI design. Asking them puts you in front of 90% of buyers.

The bottom line

OODA is the right frame. It's the right frame because it accounts for the actual structure of action under uncertainty. AI agents operate under uncertainty. Veterans are trained in OODA.

If you served and you're designing or supervising AI agents, you have a framework civilians don't. Use it explicitly. Make the four phases visible in your designs. Measure tempo.

The civilian world is going to catch up. They'll discover OODA via business books in 3 years. You can apply it today.