No Plan Survives Contact with the Data: Why AI Blueprints Need a Commander's Intent

A few months ago, during a coffee chat, a very smart AI mentor at Google told me something:

"The best way to think about these agents," she said,"is like a very smart intern. Give them enough context, define the workflow, and they will execute the code beautifully."

It reframed how I looked at AI.

That was a couple of months earlier. Which seems like a different era with the pace of how things are moving.

Today, we aren't dealing with a single "intern." We are orchestrating teams of them. And these agents aren't just reading static files anymore; they have access to Model Context Protocol (MCP) servers and dozens of custom skill files. Internally, if a task is done more than once at Google, there’s a skill file for it.

They can analyze experiments, query databases, and generate production-ready dashboards on command's notice.

They are no longer interns.

They are highly capable soldiers.

And that's where the trouble starts.

When the Blueprint Meets the Real World

In the first article of this series, I wrote about the AI Blueprint Protocol. I argued that the secret to reliable AI execution is separating the thinking from the doing:

1. The Architect Session : Where you design the execution plan and output a plain-English Blueprint.

2. The Builder Session : Where a fresh, zero-memory AI takes that Blueprint and writes the code.

It’s a beautiful system. On paper.

But if you’ve spent any time actually running these workflows, you know what happens next. The Builder Session wakes up, takes the Blueprint, charges into the data—and immediately runs into a wall.

A database schema has changed. A server times out. The raw data contains unexpected null values.

The plan breaks.

The legendary Prussian military strategist, Field Marshal Helmuth von Moltke, famously wrote a version of this truth in 1871: "No plan survives the first contact with the enemy"

Or, as Mike Tyson more casually put it: "Everyone has a plan until they get punched in the mouth."

When our AI "soldiers" get punched in the mouth by real-world data constraints, they usually do one of two things: they hallucinate a path forward, or they crash.

To fix this, we need to borrow another concept from military strategy.

We need Commander's Intent.

The Power of the Single Goal

In the US military, they realized that rigid top-down plans fail in the chaos of battle. So they designed a protocol called Commander's Intent.

It is a plain-English statement at the top of an operation order that defines the core purpose of a mission. It doesn't tell soldiers how to take a hill; it tells them why the hill must be taken, and what the field must look like when they are done.

The Combat Maneuver Training Center recommends officers arrive at this intent by asking two simple questions:

1. If we do nothing else during tomorrow's mission, what is the single most important thing that we must do?

2. What is the state of the field we must leave behind?

This gives the executing team "wiggle room." If the bridge is blown, they don't sit there waiting for orders; they know the intent is to cross the river, so they find a ford.

We must build this exact wiggle room into the top of our Blueprints.

Instead of just listing a sequence of code-generation steps, the start of every Blueprint must establish the Commander's Intent.

For example, when architecting an AI agent to build a Customer Satisfaction (CSAT) defect-reporting pipeline, the intent will likely look like:

Identify not just IF a defect occurred in the user experience, but WHY it happened - transitioning from merely tracking satisfaction metrics to optimizing for the immediate actionability of defects as they occur.

If the data schema has changed, the modality of survey has changed, the AI knows the mission. It can pivot, filter, or re-route because it understands the why , not just the how. When building our survey measurement ecosystem, this means the agent knows to prioritize open-ended feedback rates (which drive actionability) over systems that capture higher raw volumes of numeric feedback (which only help with hill-climbing).

And this principle must cascade. Each sub-module or sub-agent in your system needs its own micro-commander's intent.

But if you are a data scientist, this strategy requires one more critical layer.

Hypotheses Over Insights

My previous article focused heavily on software code development. But as a Data Scientist, my day-to-day isn't just about writing code; it’s about extracting truth from noise.

And that brings us to the second principle of the AI-First workflow.

Traditional data science is consultative. When a PM or Executive comes to us and asks, "What insights can we find here?", traditional data scientists were seen as the truth-keepers of data—people who sift through mountains of data, remove the noise, and find the truth, however inconvenient.

If you give that exact prompt to an AI agent, it will drown. It will calculate 500 different statistical metrics, generate 20 uninterpretable charts, and hallucinate correlations. It gets lost in the data sea.

A mentor of mine once gave me a piece of advice that changed my entire approach to the craft:

"A data scientist's primary job is not just to find insights in data. It is to construct falsifiable hypotheses without the presence of any data."

You must do the thinking before you touch the database.

In an AI-first workflow, you must build falsifiable statements directly into your Blueprint during the Architect Session.

A falsifiable statement does two things:

1. It narrows the search space: It tells the AI exactly what subset of data to look at, preventing context overload.

2. It builds a native validation mechanism: Because the hypothesis is falsifiable, the AI knows precisely how to prove itself wrong.

What it looks like in practice

Instead of telling the AI: "Analyze our experiment data and find why CSAT is down," your Blueprint should contain a falsifiable statement:

Falsifiable Hypothesis:The 2% drop in Customer Satisfaction might be driven by a latency spike in the smart-home triggering event.

By specifying the scope and the validation boundary (stat sig difference from control), you have turned a vague exploratory data dump into a highly structured, objective mission.

The Builder Session now knows exactly what query to write, what metrics to compare, and when to abort the hypothesis and notify you.

The Thought is the Job

In the AI era, code is cheap. The execution is fast.

But if we do not bring rigor to the design, we are simply training our highly capable AI "soldiers" to sprint off the wrong cliff faster.

By inserting a clear Commander's Intent to give our agents adaptability, and anchoring our data workflows in Falsifiable Hypotheses before we touch a single row of data, we reclaim our role as the Architect of Agency.

The code belongs to the AI. The intent belongs to us.

How do you build adaptability into your AI prompts when they hit real-world data constraints?

Originally published on LinkedIn.