For most of those six months, it was bad at all of it. And every time it handed me a plan that missed, I got mad at it. If it had been a junior employee, I’d have fired it every other week.

Four weeks ago I worked out who I should have been mad at. Me. And once I saw it, I couldn’t unsee the second version of the same mistake — the one I’ve been quietly making with every capable model I touch.

Here’s the hypothesis I backed into the hard way. An AI does the work in the middle, but it’s blind at both ends. Going in, it can’t see the workflow in your head — the part you never wrote down. Coming out, it can’t see the edge of its own competence — the places it’s confidently wrong. Those two blind spots are the whole of what you own — and you own them differently. The sight going in you supply once: write down what you know, and the gap closes. The sight coming out you supply for as long as you use the tool: a model won’t reliably flag its own edge, so someone has to watch for it. What never transfers is the responsibility for either. And the better it gets, the easier it is to believe it can see for itself. It can’t — and the one being fooled is you, not the machine.

I fumbled both. Here they are.

Half one: the sight going in

Here’s what I never did for six months: explain how I work.

Not the tasks — the workflow. How I decide what earns a deep-work block and what gets triaged. What actually counts as a deliverable. How I guard the thirty minutes before a meeting so I walk in ready. To me all of that is innate; I’ve done it long enough that it doesn’t feel like knowledge, it feels like breathing.

But an agent can’t act on what you never say. It looks like it remembers, like it understands the shape of your day — but underneath, between turns, it doesn’t. I’d handed it a job without ever handing it the context that makes the job doable, then resented it for guessing.

The fix wasn’t a smarter model. It was writing the innate part down — capturing the actual workflow of my day. First thing I made explicit: every deep-work block gets a named deliverable and a time, so the agent knows what “done” even means. That’s when it started to work.

The tool took days. The integration took six months — because the integration was me. That’s the sight going in: the workflow only you can see, that the model needs and cannot get on its own.

Half two: the sight coming out

Supervision is the last of the Marine troop-leading steps — and the one they’ll tell you matters most, because it’s what turns a plan into a result, and it’s the first thing to slide when the work keeps coming back good. That’s the second blind spot, and the one I’m still fighting: with AI, it hides behind the model getting better.

Picture the best hire you ever made — aggressive, takes initiative you didn’t ask for. For four, five, six months the work comes back outstanding, faster and cleaner than you’d have managed yourself. So you relax. You skim where you used to scrutinize. You approve on reputation. Then one day, one deliverable, they’re confidently, catastrophically wrong — and because you’d stopped looking, it’s out the door before you catch it. That bad day is usually the first time you notice how far your supervision had slid. The trust doesn’t erode; it shatters, all at once.

I’d started living that with my AI — and the pull is stronger, because the model keeps earning it. It gets better, more consistent; when a tool is right nine times running, you stop bracing for the tenth. And you’re told, constantly, that it’s trained on *everything* — so it’s easy to assume there’s no edge at all. So you do the efficient thing: you hand it the checking too, on the quiet assumption that it’s mostly right.

But “mostly right” has a shape, and neither of you can see it. At Sequoia’s AI Ascent this year, Andrej Karpathy told the story of chess: model chess ability jumped sharply between releases, and the field read it as the model getting generally smarter. It hadn’t. Someone had fed its training a pile of chess games; the spike was local to that data — nothing beyond it. A brilliant game told you nothing about the task one square over.

Here’s why that should worry a manager. With a person, you can find the edge of what they know — they hesitate, they say “that’s not my lane” — and finding that edge is what lets you safely trust everything inside it. A model rarely gives you the edge. It runs off the end of its competence at nearly full confidence, with none of the hesitation a person would show — and no way for you to tell, in the moment, which side of the edge you’re on. So you can’t trust it to check its own work: the place it’s least reliable is the place it’s least likely to flag. And you won’t reliably catch it either — you follow it over the edge. The field experiment that gave this its name, the “jagged frontier,” handed 758 consultants a problem set just past what the AI could do. On their own, they got it right about 84% of the time. With the AI, they did worse: 19 points less likely to land the right answer — because a confident output carried nothing in it to tell them they’d crossed the line.

Which is why the checking never transfers. Someone has to hold the sight the model doesn’t have, and that someone is you. I used to file this under “autonomy ladder” — more rope as the agent proves itself. I still believe it, for scoping *what* it may touch. But proven reliability earns a model wider scope; it never earns it your absence.

The line I already knew

None of this should have surprised me. I spent years being trained on it, in a setting where the cost of getting it wrong wasn’t a missed deadline.

A commander doesn’t hand responsibility for an operation to the operations officer who planned it. The OPSO designs the op; the commander owns what happens when it meets the enemy. You can delegate the task. You never delegate the outcome. HBR put a number on it: in a study of 1,200-plus managers this year, framing an agent as an “employee” led them to catch 18% fewer of its errors and to blame the model when it failed. But blame doesn’t move; it stays with whoever deployed the thing. When its work ships under your name, it’s your work.

I forgot that — not in a briefing tent, but at my own desk, with a tool I built myself. When it failed, I got mad at the assistant. I should have gotten mad at the manager who never gave it the sight going in, then stopped supplying the sight coming out.

That manager was me.

Onboard like a hire. Own like a commander.

So here’s where I’ve landed, sharper than the advice I’ve been giving.

Onboard your AI like a junior hire: give it the context, scope its access, keep a record. That’s the sight going in. Then own it like a commander: the judgment is yours, the review is yours, most of all in the places the model is confident and wrong and you’re tired and it’s late. That’s the sight coming out — and it’s the half that gets *harder to hold* as the model gets better, not easier.

Here’s the catch. The sight going in has to come from *you* — no vendor can see the workflow in your head; your domain knowledge is the asset, the AI only the instrument. But getting it out of your head, building the tool around it, and standing up the loop that watches the output is its own discipline — the part I kept getting wrong on my own. That’s the work I do with operators now: not sell them a model, but pull their workflow into the open and build the ownership, both ends, around it.

That’s the part that’s actually hard — and the part worth getting right. So if you’ve got an AI tool that half-works and you can’t tell whether the problem is the model or the way it was never built into how you operate: that’s the conversation worth having.

You can hand an AI the work. You can’t hand it the sight at either end — the context going in or the judgment coming out. And the better it gets, the more that’s worth remembering — because the better it gets, the more it tempts you to forget.

---

*This is the thread I pull on here — running AI like a readiness problem instead of a magic button. It’s the throughline of a book I’m writing on applying military readiness models to enterprise AI adoption, worked out in the open, one issue at a time. If that’s your thread, subscribe.*

*Sources: Andrej Karpathy, Sequoia AI Ascent 2026 (”From Vibe Coding to Agentic Engineering”) — jagged intelligence and the chess example (capability local to added training data, not general). Dell’Acqua, McFowland, Mollick, et al., “Navigating the Jagged Technological Frontier” (Organization Science, 2025; field experiment with 758 consultants) — on a task set beyond the AI’s frontier, those using AI were 19 percentage points less likely to reach a correct answer than those without it. Harvard Business Review, “Research: Why You Shouldn’t Treat AI Agents Like Employees” (Kropp et al., BCG, May 2026) — accountability does not transfer to the model.*

A month later, Gartner ran a separate survey of Chief Sales Officers. 31% named “difficulty proving the ROI of AI-driven tools” as a top challenge for 2026.

Read those two numbers together and something becomes clear. The people who approved the AI budgets are losing faith in them. And the people responsible for revenue can’t show the math. This is not a technology problem. It’s a measurement problem. And it’s everywhere.

Uber’s COO said it directly last month, on the record: “It’s hard to link AI use to product improvements.” His CTO had just disclosed four months of data — agent usage climbing from 32% to 84%, 70% of code commits AI-driven, monthly API costs between $500 and $2,000 per engineer. Every one of those numbers is real. Every one of them is the wrong number.

The military has a word for this distinction. Two words, actually.

MOPs and MOEs

Measures of Performance — MOPs — answer one question: are we doing things right?

Missions flown. Rounds fired. Sorties completed. Reports filed on time. These numbers tell you whether the activity happened. They do not tell you whether the activity mattered.

Measures of Effectiveness — MOEs — answer a different question: are we doing the right things?

Did the air campaign degrade the enemy’s ability to maneuver? Did the supply line hold under pressure? Did the training actually produce units capable of executing the mission? MOEs connect activity to outcome. They are harder to build, harder to measure, and the only numbers that actually answer the question a commander — or a board — needs answered.

The Joint Publication 5-0, the doctrine governing US military operational planning, treats this distinction as foundational. You don’t start with activity metrics. You start by defining what success looks like, then you build the measures that tell you whether you’re achieving it.

Most AI deployments do the opposite. They instrument the activity first — tokens consumed, code commits, hours saved per task, adoption rate — because those numbers are easy to collect. The tools already track them. Then, months later, someone in the boardroom asks whether any of this is working, and the answer is a dashboard full of MOPs with no MOEs in sight.

What it actually looks like

I run three parallel workstreams on a typical working day. In one window, AI-assisted development on a new feature. In another, a requirements document for a client. In a third, processing the day’s communications. None of that is sequential. The agent runs, I review, I move.

The productivity gain isn’t “I built the feature 30% faster.” It’s that three things got done in the time one used to take, and my afternoon opened up for work I couldn’t reach before. A client onboarding. A compliance review that had been deferred for two weeks. A proposal that needed to go out.

That freed-up time is net-new capacity. It didn’t exist last quarter. And it doesn’t appear anywhere on a standard AI productivity dashboard — because there’s no baseline to compare it against, and no column on the report to put it in.

That’s the gap Uber’s COO was naming. Not “AI doesn’t work.” His organization couldn’t yet connect the activity to the outcome, because nobody had built the measurement layer that makes that connection possible. MOPs everywhere. MOEs nowhere.

This is not unique to Uber. It’s the shape of AI adoption at scale right now. Adoption is real. Measurement is a generation behind.

Why this happens

MOPs are instrumented by default. Your IDE counts commits. Your ticketing system counts closes. Your token dashboard counts tokens. The data exists because the tools generate it automatically.

MOEs require deliberate design. You have to define the outcome before you deploy the capability. What does success look like — not in activity terms, but in business terms? What would have to be true six months from now for this AI investment to have been worth it? Then you build the measurement layer that ties the activity back to that outcome.

Most AI pilots skipped this step. The implicit logic was: deploy the tool, demonstrate activity, let the value prove itself. It doesn’t work that way. If you didn’t define the outcome before you started, you have no reference point to measure against when the board asks.

The Brookings Institution mapped this problem economically last year, analyzing AI deployment in computer vision — one of AI’s most mature domains. 80% of tasks are technically feasible for AI. Only 23% are economically viable to deploy when real-world costs are factored in — customization, human oversight, domain expertise. Most organizations don’t know which side of that line they’re on before they commit. MOEs are how you find out. If you can’t define a measurable business outcome before you deploy — not activity metrics, but an actual outcome the business can count — you’re almost certainly working in the 77%. Defining your MOEs before deployment is the filter that puts you in the 23%.

The question to run on your next dashboard review

Before your next AI metrics review, apply one filter to every number on the dashboard: is this a MOP or an MOE?

MOPs tell you what happened. MOEs tell you whether it mattered.

If you can find MOPs but not MOEs, you don’t have an AI ROI problem — you have something worse. You have no way to know whether your AI investment is working or not. The activity is real. The outcome definition is missing. And without it, no amount of activity data will answer the question the board is actually asking.

The doctrine for building that measurement layer has been sitting in military planning doctrine for forty years. Most boardrooms have never heard of it.

That’s what this newsletter is about.

MOEs and Commander’s Intent

There’s a deeper connection worth naming here, one that comes from the doctrine that produced MOEs in the first place.

In military planning, MOEs are not standalone metrics. They are the feedback mechanism of what the doctrine calls Commander’s Intent — a precise, concise statement of the desired end state that gives subordinates enough guidance to act without further orders when the plan changes. Commander’s Intent doesn’t prescribe every step. It answers two questions: what does success look like, and why does it matter? Everything else flows from that.

One of Commander’s Intent’s four required elements is feedback loops — the specific mechanisms that tell the commander whether execution is tracking toward the intended outcome. MOEs are those loops. Without them, Commander’s Intent is a statement with no way to know if it’s being achieved.

Most AI deployments have neither. No defined end state before deployment, and no feedback loops after. The organization knows what the tools are doing — the MOPs are instrumented from day one — but has no mechanism to know whether any of it is pointing in the right direction.

This is the measurement problem in its complete form: it isn’t just that organizations lack MOEs. It’s that they skipped the step that makes MOEs possible — defining what success looks like before the first token is spent.

I’m writing a book on this — applying the full set of military operational frameworks to AI adoption. Commander’s Intent gets its own chapter. If this thread is useful, the book is where it goes deeper.

What’s next

Next issue: before you can define your MOEs, you have to direct your AI toward the right outcomes in the first place. Most people treat AI agents like search engines — you ask them things and hope. The people getting results treat them differently. Next issue I’ll introduce the framework I use to brief AI agents the same way a Marine briefs a subordinate before a mission.

If you found this useful, forward it to one person in your organization who’s sitting on an AI dashboard full of MOPs.

— Glen Lewis Founding Principal, Coyote & Quill Observe. Assess. Advise.

Sources: Gartner, April & May 2026 | JP 5-0, Joint Doctrine for Planning | Brookings Institution / MIT FutureTech, August 2024