You’ve probably spent hours debating whether to use an AI agent or a workflow. Maybe you’ve even built a multi-agent system that nobody asked for. I’ve been there. And I’ve seen teams burn months of engineering time on the wrong architecture—not because they chose the wrong pattern, but because they skipped the only question that matters: Should we be using AI at all?
Here’s the uncomfortable truth: most AI projects fail not because of technical limitations, but because of a fundamental lack of clarity. Teams rush to ‘how’ before they’ve answered ‘why.’ They treat every problem as a candidate for agents, RAG, or multi-agent systems, when the real bottleneck is something far simpler and far cheaper to fix.
Here’s the framework I use to cut through the hype. It’s three steps. And it starts with four questions you never want to skip.
Step 1: The Four Gates of Value
Before you even think about architectures, answer these four questions. If you can’t answer all of them, stop. Go back. Do not collect $200.
1. Is the scenario real?
Who uses this? When? How often? Is it assisting a human or replacing them? If you can’t describe the scenario in one sentence, it’s a fake problem. “Everyone else is doing it” is not a scenario.
2. How painful is the current solution?
If the current process works fine and nobody’s complaining, AI won’t help. AI is for problems that are either poorly solved or too expensive to solve. Not for problems that aren’t problems.
3. What role does AI play?
Is it a productivity tool (human stays in the loop)? An automation engine (replaces human actions)? Or a decision advisor (suggests, human decides)? Get this wrong and you either over-engineer a simple task or unleash a risk nightmare.
4. What’s the cost of a mistake?
Can you fix it with a quick edit? Does it require human cleanup? Does it affect customers, money, or compliance? The answer determines your safety buffer—not the architecture choice.
The golden quote: ‘If you can’t explain why this problem needs AI, you’re not ready to build it.’
If all four gates pass—real scenario, painful problem, clear role, manageable error cost—you’re cleared to proceed. If even one is fuzzy, you’re not ready.
Step 2: Classify the Problem, Not the Solution
Once you’ve validated the value, you need to understand the problem itself. Here’s the six-dimensional checklist I use:
- What’s the input? (text, image, structured data, voice?)
- What’s the core task? (generate, classify, extract, transform, decide?)
- Are the steps fixed or variable? (SOP vs. exploration)
- Does it need to interact with external systems? (read, write, both?)
- Who’s the user? (expert, general public, internal team?)
- How stable does the output need to be? (creative variation vs. deterministic precision)
These answers will naturally point you toward the right pattern—not the other way around. Don’t start with ‘should I use an agent?’ Start with ‘what kind of problem is this?’
Step 3: Match Patterns—But Don’t Stop There
Here’s my quick rule of thumb:
- Fixed steps? Use a workflow. (Approval flows, scheduled reports, data syncs.)
- Variable path, clear goal? Use a single agent. (Research, analysis, task planning.)
- Repetitive, templated task? Package it as a Skill. (Risk reviews, monthly reports.)
- Need to search your own knowledge base? Build a RAG system. (Policy Q&A, historical data lookup.)
- Multi-role, complex decision? Consider multi-agent—but only if you can’t do it with fewer.
The golden quote: ‘Two agents can solve what one agent can’t. Five agents will solve nothing but each other.’
But here’s the twist: the real world is messy. Most solutions are combinations. You might need a workflow that calls an agent for a tricky sub-step, or a RAG system that feeds into a multi-agent review. The key is to keep your prompts lean and push stable logic into external tools (skills, APIs, databases). Don’t cram everything into a single prompt—it dilutes attention and breeds errors.
The Bottom Line: Safety First, Always
Every architecture decision comes with a security boundary. If the output affects customers, money, or permissions, you need human-in-the-loop. Not as a formality, but as a real check. If your AI is wrong so often that the human has to rewrite everything, you’re not doing human-in-the-loop—you’re doing human-with-no-help. Fix the AI first.
The golden quote: ‘The most expensive mistake in AI isn’t choosing the wrong model. It’s choosing any model before you’ve validated the problem.’
This framework isn’t theoretical. I’ve used it to save teams months of wasted effort. It’s not about being anti-AI. It’s about being pro-value. Start with the gates. Then classify the problem. Then match the pattern. And always, always keep the error cost in mind.
Now go build something that actually matters. And if you’ve got a better framework—or a worse failure story—drop it in the comments. Let’s learn together.
FAQ
Q: Isn't this just common sense? Why do teams need a framework?
A: Common sense is rare under pressure. When everyone around you is building agents, the fear of missing out replaces critical thinking. The framework forces you to slow down and ask the uncomfortable questions before the hype takes over.
Q: What if I skip the value validation and just build an agent quickly to test?
A: You can—but you'll likely waste time. A quick test without a clear scenario and error cost definition often leads to a prototype that solves a non-problem. You'll end up with a 'solution looking for a problem.' The framework is cheaper than a failed sprint.
Q: Does this framework apply to all AI use cases, including generative AI for content creation?
A: Yes. The four gates—scenario, pain, role, error cost—apply universally. For content generation, the error cost might be low (a typo is fine), but the role clarity is still critical: is the AI generating a first draft, or should it be final? Without that, you'll over-engineer or under-deliver.