Back to Blog

Should you build that AI workflow? A three-layer test

Not every AI task is worth turning into a real system. Here's a quick test — books, movies, video games — for knowing which ones are.

Dave Hague
May 4, 2026
AI strategyconsultinginvestment

A common move on a consulting call goes something like this: a client describes an AI task they've been doing manually, says it feels repetitive enough that AI should be doing it, and asks how much it would cost to build a custom system around it. Half the time the right answer is "build it." The other half, the right answer is "don't build that. The thing you're describing will be a free model feature in six months."

The test for telling the difference, originally Jake Van Clief's, uses a metaphor of escalating production complexity: books, movies, and video games. Once you see the layers, the should we build this question gets a lot easier.

Books

A book is one person putting words on a page. Linear. Single output. If two writers tackle the same topic, they end up recognizably similar — the information is the value, not the form.

The book layer in AI is anything one prompt can do. "Summarize this PDF." "Draft a cold-outreach email." "Pull the action items out of this transcript." Anyone with a chat interface gets a roughly similar result. The model is doing all the work. Your investment in shaping the prompt is small, and the next model update will probably do it even better.

The implication: don't build for the book layer. Use it freely — your team should be using ChatGPT and Claude every day for these tasks — but don't put engineering hours into wrapping a custom system around them. Whatever you build will be subsumed by a free feature within a year. There's a much-quoted line for this: "don't automate something a generic prompt can do for you."

What this looks like in practice: someone asks for a "Slack summary tool" that takes a long thread and returns the key points. Stop. The free version of any major model already does this. Train the team to use the chat interface; don't build infrastructure.

Movies

A movie is many people coordinated together — director, screenwriter, actors, cinematographer, editor — to produce one polished experience. Lots of orchestration. But once the film is done, every viewer sees the same thing. It's static.

The movie layer in AI is a multi-step workflow. A pipeline that takes a brief, drafts options, picks one, runs it through quality checks, and produces a polished output. Each step does work that compounds with the next. The orchestration is real value — you can't get the same quality from a single prompt because the model can't hold the whole quality bar in mind at once.

The implication: build at the movie layer when the orchestration produces something noticeably better than one prompt could. A research-then-write pipeline. A monthly client-report generator. A multi-pass content production flow with voice rules and a review checkpoint. These are real engineering objects: stages, contracts, handoffs, audits. They survive even as the model underneath gets smarter, because the structure is what's doing the work.

This is also where the Interpreted Context Methodology series lives. Once you've decided your work is movie-layer or higher, ICM is what good structure looks like — folders and markdown instead of code and frameworks.

What this looks like in practice: an agency that's been hand-producing weekly client newsletters builds a workflow that takes the week's research notes, pulls the angle, drafts the issue in the agency's voice, runs it through a brand-compliance check, and pauses for human review before sending. Same input → same kind of output, every time. Reliable, repeatable, polished. Worth building.

Video games

A video game is interactive. Each player's experience is different because the game responds to choices, history, skill level, what they've done before. Same game, different play-throughs, different outcomes. The system has context about who's playing.

The video game layer in AI is bespoke, adaptive, context-heavy work. A research assistant that knows your company's clients, voice rules, brand history, the analyst running it, and the audience the report is for. The same question to the same system produces different work for different users — because the system has context about who's asking and why. The model's contribution is generative capability; everything meaningful about the output comes from the data and relationships you're feeding it.

The implication: this is where the most durable value lives. The reason is simple: a generic model update can't replicate it because the model doesn't have your context. Your client roster, your past engagements, your specific evaluation criteria, your stakeholder map — none of that is in the model's training data. Building a system that wraps your domain knowledge in an AI interface gives you something a competitor can't copy with a free chat.

This is also where the real compounding investment lives. Movie-layer work is built once and runs the same way every time. Video-game-layer work gets better the longer you run it, because the context grows: more historical data, more refined criteria, more institutional knowledge encoded in the workspace. Consulting clients sometimes ask why you'd bother building a custom system when ChatGPT exists. The answer is here: ChatGPT doesn't know what you know.

What this looks like in practice: a compliance audit tool that knows your industry's specific regulations, the audit history of each of your clients, and the way your firm specifically writes findings. Or a customer-research synthesis tool that knows your specific product taxonomy, customer-segment definitions, and decision criteria. The output of these tools is materially different from what a generic prompt could produce — because they have access to context that lives outside the model.

The decision rule

When a workflow lands on your desk and someone asks whether to build it, run the test:

  • Book layer? Don't build. Use the model freely. The next update makes whatever you'd build free.
  • Movie layer? Build with structure. The orchestration earns its keep. ICM is the cleanest way to do it.
  • Video game layer? Build and invest in the domain context that makes it irreplaceable. This is the work that compounds.

A useful follow-up question: will this be valuable when models get a notch better? If the answer is no, save the effort — you're building at the book layer regardless of what the surface looks like. If the answer is yes, because the value is in the data and the context, not the prompt, you're at the video game layer and the investment is genuinely durable.

The Bitter Lesson connection

Rich Sutton's Bitter Lesson is the philosophical companion to this test. Sutton's argument: across seventy years of AI research, every time someone built clever, hand-crafted, domain-specific structure to make a system perform better, general methods using more compute eventually swept the structure aside. Specialized symbolic systems lost to statistical methods. Hand-tuned features lost to learned ones.

Mapped onto these three layers: the book layer always gets eaten. Anything a generic prompt can do, a better generic prompt will do better next quarter. The movie layer is partially eaten over time as models get better at one-shot tasks, but the orchestration value is real and worth building today. The video game layer is hardest to eat because it depends on context that lives outside the model — your data, your relationships, your specific way of working. That context isn't going to be in the next model's training data, and that's exactly why investment there compounds.

The test, in one sentence: build at the layer the next model can't replicate for free.

When you're ready to build

If your work lands at the movie or video-game layer, the next question is how to structure it. The ICM series walks through that question in five parts — folders instead of frameworks, layered context, where ICM fits in the broader stack of agent tooling, real workspace examples, and where the methodology is heading next.

If your work lands at the book layer, save the engineering hours. Use the model. Watch what gets better quarter to quarter, and revisit the test when something in the work shifts toward movie or video-game territory.

The framework comes from Jake Van Clief's videos and Skool community. Full attribution on the About this series page.

This guide was my gift to you. I want everyone to be able to punch above their weight class by leveraging AI to do more with what they've got.

If this helped and you want to know how I help companies through AI consulting, mentoring, or workshops — sign up for my email list or reach out below.

Or schedule a conversation →