Jordan Henning
Essay

The model was never the hard part.

The rarest skill in AI product work is reading the workflow — fast.

The industry is obsessed with the model. Which one benchmarks highest this month, which framework to standardize on, how to squeeze a few more points out of a prompt. It's a comfortable obsession, because it's measurable. It's also mostly beside the point.

The AI systems that make it into production and stay there rarely win on the model. They win because someone understood the workflow cold — saw exactly which part of a messy real-world process deserved to be automated, which part had to stay human, and where the whole thing would break. That understanding is the scarce resource. The model is the commodity.

The model is the commodity now

Swapping one frontier model for another is a config change. The providers are converging, the wrappers are interchangeable, and 'prompt engineering' is a skill with a shrinking half-life. None of that is where the leverage is.

The leverage is in the part that doesn't transfer: understanding the actual process you're pointing the model at. When I built RFP Factory, the Python was the easy part. The hard part was knowing which steps of a 40-hour federal proposal workflow had to stay human, which ones deserved automation, and how to instrument the system so a contracting officer could trust the output. No model choice solves that. Only knowing the workflow does.

Where AI products actually die

AI products almost never fail because the model was too weak. They fail upstream of the model, in the read of the process.

Someone automates the judgment call that should have stayed human. Someone misses the edge case that everyone who actually does the job knows cold. Someone ships a beautiful demo of the wrong ten percent — the flashy part, not the part where the hours and the risk actually live. By the time the model is even involved, the mistake has already been made.

The people who live inside a workflow carry a map of it that no dataset contains: the exceptions, the handoffs, the quiet places where trust breaks. Miss that map and it doesn't matter how strong your model is. You've just automated the wrong thing, faster.

It's a speed skill, not only a depth skill

Understanding a workflow isn't enough. You have to understand it fast.

You rarely get months to marinate. You drop into a domain, a team, a process you didn't build, and you have days to see its real shape — where the hours go, which steps are rote and which are judgment, where a human has to own the decision, where the failure modes hide. The person who reads that quickly ships in weeks. The person who can't spends a quarter building the wrong thing with excellent engineering.

Speed of comprehension is also what makes you portable. It's the difference between someone who's only useful in the domain they came from and someone you can drop into a new one and trust to find the real problem before they ever touch the model.

Seventeen years of operations is an unfair advantage

I don't pick AI projects from a tech-trend deck. I pick them from workflows I've personally owned and watched fail.

Every system I've built started as a process I already understood from the inside. RFP Factory came from federal proposals I'd lived through. My marketing system runs the marketing I do myself. The résumé engine came out of job-hunting. The multi-agent dev system is a software organization modeled as agents — because I've run the human version. I knew where each one would break before I wrote a line, which is exactly why they shipped in weeks and survived contact with reality.

That's what seventeen years running real federal operations actually bought me. Not a rolodex — a trained instinct for reading a process quickly and knowing what it can bear.

If you're hiring for AI, test for this

Stop quizzing candidates on model trivia and framework preferences. The model will keep getting better on its own; you're not hiring someone to babysit a benchmark.

Hand them a real workflow your team owns and watch what they do with it. How fast do they find the failure points? Do they know which steps should stay human? Do they ask the questions that reveal they've thought about where the hours and the risk live — or do they reach for the model first? The candidate who reads your process fastest is the one who'll turn that model into a product instead of a demo.

The model was never the hard part. Hire the person who knows what it's for.

Companion essay
If you can dream it, you can build it. So why are we still hiring people who can only build?
If this is the skill you're hiring for, I'm a 15-minute conversation away.
Book 15 minutesjordanhenning32@gmail.comGitHubLinkedIn
© 2026 Jordan Henning. AI Engineering & Delivery Leader.
Jordan Henning · jordanhenning32@gmail.com · 330-280-0642 · https://calendly.com/jordanhenning32/15-min-intro-meeting