# AI's Value Compounds at the Task Layer, Not the Model Layer

When a team sets out to add AI to something, the first real argument is usually about the model. Which provider, which version, this one or the one shipping next month. It feels like the decision everything else rests on.

It's the most throwaway decision in the system.

Frontier models are converging and commoditizing. The one you pick tends to get matched within a few model cycles, and swapping it out is far less work than rebuilding the task around it. So any edge the model itself gives you is temporary — the same edge everyone else will have a quarter later. The value that actually builds up sits one layer up: in how you redesign the work itself around what AI now makes possible.

I learned this the way most things worth knowing get learned: by spending real effort on the wrong layer first.

* * *

## The model layer is infrastructure

That last point echoes something Benedict Evans has said about foundational technology cycles: the model layer is this cycle's TCP/IP — genuinely transformative, and *not where the durable value gets built*. TCP/IP made the web possible, but the value that lasted accrued one layer up — in what the protocol newly allowed, not in the protocol itself.

Same here. GPT-N, Claude-N, Gemini-N are the foundation. "Which model should we use?" is a buying question — it has a cheapest-good-enough answer and a short shelf life. The question that actually shapes an architecture is different: **which tasks change shape once AI is embedded?** Which steps dissolve, which get re-decomposed, which new ones appear. That question has answers that survive across model generations.

* * *

## A worked example: the review gate

The clearest case I've worked on is an automated review gate — the kind that checks every incoming change against a house rulebook and flags what's out of line. The first meetings went exactly where I've been describing: *which model judges violations best?* We treated it as a model-selection problem and spent our attention accordingly.

That framing was the mistake, and the decomposition exposed it. When I broke the rulebook down check by check, the question stopped being "which model" and became "what is each check, actually?" Most of them turned out to be **structural** questions, not questions of meaning — "does this component reach for something it isn't allowed to?" is a lookup over structure, not a judgment call. Only a minority genuinely turned on intent, the kind of thing — "is this message actually helpful to a human?" — where a language model is the right and only tool for the job.

Here is the part that reframed everything for me. **A frontier-model upgrade would have sharpened that semantic minority a little and left the entire structural majority exactly where it was.** The bulk of the gate's value — the checks meant to run on every change, every time — never depended on model capability at all. It came from *recognizing they were structural* and routing them to something that inspects structure. The value was in the decomposition. For most of the system, the model was almost a distraction from the decision that mattered.

I'm deliberately not reprinting the routing mechanics here — that's a cost story I've told elsewhere. The point for *this* argument is simpler and more lasting: the leverage came from rethinking the task, and a better model would not have delivered it.

* * *

## Why one layer compounds and the other doesn't

Model gains never last. You upgrade, and within a quarter the whole field upgrades with you; your lead washes out. It's a floor that rises for everyone at once — real, but never *yours*.

Task decomposition keeps paying off. Once the gate is split into "structural checks" and "genuine judgment," that split doesn't ride on frontier progress. A better model sharpens the judgment slot and leaves the structural checks doing exactly what they did. Each task you re-decompose is an asset that keeps paying off for as long as the task exists — a model swap can't erode it. Each model you pick is a rental that expires.

That's the whole thing in a line: **the model is the part that dates fastest; the task redesign is the part that lasts.** Your scarce attention belongs on the layer that compounds — which is rarely the one the first meeting wants to argue about.

* * *

## The hard part is drawing the lines — and you'll draw some wrong

This can read like a truism — *of course* decomposition matters. The sharper point is that AI raises the stakes on getting it right: the easy path, one prompt for everything, quietly buries the whole structural majority of steps that should never touch a model at all.

And drawing those lines is genuinely hard. The whole approach rests on one skill: telling *judgment* from *structure* — which steps truly need a model to understand meaning, and which only look like they do because it's easier to send everything through one prompt.

You will misjudge some. In the gate, a handful of checks looked purely structural but hid a meaning-based edge case that a naive rule would silently miss. The rule I settled on: when a check is ambiguous, send it *up* to the model rather than let a mechanical shortcut quietly get it wrong. Getting those boundaries right is iterative, and unlike a model swap, every correction you make sticks. The decomposition keeps improving precisely because you keep sharpening where the lines fall.

* * *

## How to apply it

Next time someone says "let's add AI to X," resist opening with the model. Open with the task:

1.  **Decompose X into its real steps and decisions** — the actual ones, not the category name.
    
2.  **For each, ask: judgment or structure?** Does a model genuinely earn this step, or does it just look that way because one prompt is easier than one design?
    
3.  **Redesign the workflow around that split** — deterministic where you can, model where you must — not around the model's interface.
    
4.  **Treat model choice as the last and most swappable decision.** Pick the cheapest one that clears the bar, and assume you'll replace it within the year.
    

The instinct is to settle the model question first because it feels like the important one. It's the one that expires soonest. Do the task work first — that's the part that compounds.

* * *

*I'm a Technical Architect building AI-enabled systems. I write about what I actually build — the decomposition and design decisions under the hood, not the model hype.*

*If you've re-decomposed a task around AI and found the model choice mattered less than you expected, I'd like to hear where the real leverage landed. Find me on X* [*@deepakgoyal\_ai*](https://x.com/deepakgoyal_ai) *or* [*LinkedIn*](https://www.linkedin.com/in/deepakgoyal-ai/)*.*