The case for a "do not build" list
Most AI strategy work focuses on what to build. The most experienced AI operators we've worked with maintain a different list, often more carefully than their build list: the "do not build" list. Workflows they've explicitly decided AI is not the right tool for, with reasoning documented for future reference.
Why this is valuable:
1. It prevents recurring distractions. When a new vendor pitches you a tool for a workflow on your do-not-build list, you can evaluate and pass without re-litigating. Your "no" becomes faster and more confident.
2. It clarifies your build list. Anything on the do-not-build list is, by definition, not on the build list. The list of things you're not doing makes the list of things you are doing sharper.
3. It earns trust internally. Teams resent AI deployments that should have been obvious not-fits. Maintaining a visible "things we considered and decided not to do" list signals discernment.
4. It captures hard-earned lessons. When a workflow fails as an AI deployment, documenting why prevents repeating the mistake later.
A good operator's do-not-build list typically grows in the first two years of serious AI work, then stabilizes as the patterns become clear.
Six categories of workflows that shouldn't be AI
Category 1: Workflows where the cost of being wrong is catastrophic and detection is slow.
This is Quadrant 4 from Lesson 20. Examples:
- Hiring decisions without significant human review
- Credit and lending decisions
- Medical recommendations (without licensed practitioner oversight)
- Pricing decisions for major B2B contracts
- Legal compliance decisions
Each can use AI as input — research, analysis, draft generation — but the decision should be human. The cost of an AI error here isn't just "redo the task" — it's lawsuits, lost customers, regulatory action, or harm to real people.
Category 2: Workflows where the volume doesn't justify the build cost.
AI deployments have meaningful build and operational costs. If the workflow only happens 5 times a year, automating it rarely pays back. Rough threshold: a workflow needs to happen at least weekly (ideally daily) to justify AI automation at SMB scale.
Examples: year-end report generation, new employee onboarding for a small team, major vendor contract negotiations. For these, AI as a tool in the moment is useful; AI as a deployment is not.
Category 3: Workflows that require deep customer relationships.
AI is bad at the parts of work that depend on long-standing trust, nuance about specific people, and judgment built from years of relationship.
Examples: account management for your top 5 customers, strategic conversations with key partners, high-stakes negotiations, personal outreach to your most important clients.
A common mistake: deploying AI to "scale up customer touch points" with key accounts. The customers notice. The relationship degrades. The short-term efficiency costs you long-term value that's hard to rebuild.
AI is excellent for broad customer interactions (long-tail support, lead qualification, transactional follow-up) and bad for deep customer interactions. Know the difference.
Category 4: Workflows where the inputs are too varied or unstructured.
AI works best on bounded, structured inputs. When inputs are wildly varied (every customer email is completely different, every project unique), AI struggles to produce reliable output.
Examples: free-form creative work for diverse clients, crisis response, innovation work. For these, AI as an individual productivity tool is fine. AI as an operational deployment is a poor fit.
Category 5: Workflows where the team genuinely doesn't want it.
When a team has principled objections — and those objections are substantive, not just resistance to change — that's signal worth respecting.
Examples we've seen: therapy practices where therapists feel strongly AI shouldn't be in patient communication, schools where teachers feel AI undermines the educational relationship, religious organizations where AI feels inappropriate for the work.
The AI might technically work. But deploying over the team's strong objections produces deployment failure for non-technical reasons. Sometimes defer to your team's domain wisdom.
Category 6: Workflows where the failure mode is silent and expensive.
Some AI failures are loud — wrong answers, hallucinations, customer complaints. Easy to catch.
Other AI failures are silent. The AI quietly under-performs in ways that don't show up in metrics for months. By the time you notice, real damage has been done.
Examples:
- AI that summarizes documents almost accurately, leaving out the paragraph that mattered
- AI that handles customer support competently but kills the warmth that drove retention
- AI that schedules meetings efficiently but breaks the informal coordination holding teams together
These are the trickiest cases because the deployment looks fine — until it doesn't. Building a do-not-build entry around "this workflow has silent failure modes" is one of the highest-value uses of the list.
How to build your own do-not-build list
1. Document past considerations. Every time you evaluate an AI use case and decide against it, write it down with the reason. Over time, this becomes your list.
2. Adopt patterns from this lesson. The six categories above are a reasonable starting point. Adapt them — "Hiring decisions" → "Specifically: any hire above [salary threshold]."
3. Learn from failed deployments. If a deployment doesn't work, document why. Failed deployments are expensive; let the cost at least produce institutional knowledge.
The format matters less than the practice of maintaining it.
When to revisit the list
Things on your do-not-build list aren't permanent. Three reasons to revisit:
1. The technology has materially improved. Something not possible in 2024 might be possible now.
2. Your business has changed. A workflow you put on the list because volume was too low might now have enough volume. A relationship-dependent workflow might have become more transactional.
3. The cost of doing it manually has gone up. Sometimes the calculation changes not because AI got better but because the manual alternative got worse.
Revisit your list annually. Most items will still belong on it. The discipline of revisiting prevents the list from becoming a thoughtless "no" that ages badly.
The case against AI maximalism
Maintaining a robust do-not-build list is the practical expression of a broader principle: AI is a powerful tool, not an answer to every problem.
There's a tendency in 2026 — driven by vendor marketing and the genuine excitement of the technology — to assume any operational challenge has an AI solution if you just find the right one. This is wrong. Some operational challenges are better solved by hiring the right person, simplifying the underlying process, improving a non-AI tool you already have, or acknowledging that the problem doesn't actually need solving.
A good AI strategy includes the discipline to use AI where it fits and not use it where it doesn't. The do-not-build list is how that discipline gets institutionalized.
This is the closing lesson of the Academy because it's the most important operational principle in the whole curriculum. Everything else — the prompts, the human-in-the-loop design, the vendor evaluation, the team rollout — assumes you're deploying AI to solve a real problem. Knowing when not to deploy is what separates operators who succeed with AI long-term from those who burn out their teams chasing the wrong things.
What's next
That completes the AI Operations track — and the Academy.
You've now worked through 23 lessons across 5 tracks: Bitcoin Foundations, Bitcoin Operations, Bitcoin Strategy, AI Foundations, and AI Operations. Roughly 50,000 words of operator-voice content on the two technologies most likely to shape your business over the next decade.
Two final observations:
1. The Academy ages. Some of what you've read will be revised. The technology will move; the deployment patterns will evolve. We'll keep updating.
2. Knowing isn't doing. Reading the Academy is the start, not the work. The operators who get the most value treat it as a reference they return to as they're actually deploying — not as a one-time read.
When you're ready to put any of this into practice, that's what VoltageAI does. The Academy is free. The deployments are the engagement.
Thanks for reading.
— The VoltageAI team
Frequently asked
Questions that come up after this lesson.