LLM, RAG, Workflow, or Agent? Choosing the Minimum Necessary Complexity
In the previous article, we defined an Agent as a closed-loop system:
Goal
↓
Observe
↓
Decide
↓
Act
↓
Observe Result
↓
Continue or Stop
Once you understand that idea, a new misconception appears quickly:
If an Agent can decide what to do next, shouldn't every AI application eventually become an Agent?
Not necessarily.
In many cases, doing that only makes a simple problem harder.
Architecture should not answer:
Which technology looks more advanced?
It should answer:
What is the minimum system complexity required to complete this task well?
That is the core principle of this article:
Minimum Necessary Complexity
Add only the capabilities the task actually requires.
1. Architecture solves constraints; it is not a feature ladder
Suppose you have six possible building blocks:
Deterministic Code
LLM
RAG
Workflow
Agent
Multi-Agent
It is tempting to read them as:
simple
↓
advanced
↓
more advanced
But that is the wrong mental model.
They solve different problems.
| Architecture | What problem does it mainly solve? |
|---|---|
| Deterministic Code | Rules are known and can be computed explicitly |
| LLM | Language or semantic interpretation is uncertain |
| RAG / Retrieval | The model lacks external knowledge required for the task |
| Workflow | The task has multiple steps, but the control flow is mostly known |
| Agent | The next step must be chosen from runtime results |
| Multi-Agent | The task genuinely benefits from independent roles, contexts, or subgoals |
A better architecture process is:
Understand the task
↓
Find the smallest capability gap
↓
Add only the component that closes that gap
Not:
We are building AI
↓
Therefore we need an Agent
2. First question: can normal code solve it?
AI can make us forget something important:
Traditional software is better than an LLM for many problems.
Suppose:
Order amount = 1,000
Refund rate = 20%
The result is:
refund = 1000 × 0.2
This:
refund = order_amount * refund_rate
is usually better than asking an LLM to reason about the amount.
Deterministic code is:
- predictable,
- testable,
- fast,
- cheap,
- easy to debug.
So the first question should be:
Can this task be expressed as explicit rules?
If yes:
start with code.
3. When do you actually need an LLM?
Now consider:
What is the main intent of this customer complaint?
Possible labels might include:
refund
complaint
technical issue
account issue
question
But customers do not speak in a fixed schema.
They may say:
The thing I bought yesterday does not work, support has ignored me for two days, and I am done wasting time.
A deterministic rule set becomes difficult to maintain.
The problem now requires:
semantic interpretation
This is where an LLM becomes useful.
You can think of an LLM as appropriate when the main uncertainty comes from language, meaning, or open-ended generation.
Typical tasks include:
summarization
classification
rewriting
information extraction
semantic comparison
natural-language generation
4. If the model does not know something, more reasoning does not create the missing knowledge
Suppose the user asks:
What is our current hotel reimbursement limit for business travel?
The model may:
- never have seen the company policy,
- have seen an old version,
- have no information about this company at all.
The main problem is not:
insufficient reasoning
It is:
required knowledge is not in context
That is where Retrieval or RAG starts to matter.
5. RAG solves a knowledge gap
The basic idea is simple:
Question
↓
Retrieve relevant information
↓
Put evidence into Context
↓
LLM
↓
Answer
For example:
User:
What is the overseas hotel limit?
↓
Search the internal travel policy
↓
Find:
Tokyo: JPY 20,000 / night
↓
LLM answers from that evidence
What Retrieval adds is:
External Knowledge Access
It does not automatically make the model smarter.
If the failure is:
the system does not have the required information,
Retrieval is a reasonable answer.
If all the required evidence is already in context but the model reasons incorrectly, adding another vector database usually does not solve the root problem.
6. RAG does not automatically mean Vector Database
Another common shortcut is:
RAG
=
Embedding + Vector DB
That is too narrow.
Retrieval can come from:
Search Engine
Database
SQL
Document Index
Keyword Search
Vector Search
Hybrid Search
API
The important property is:
The system retrieves the right evidence and puts it into the model's current context before the answer is produced.
So the first RAG question should not be:
Which vector database should we use?
It should be:
Is the model missing external knowledge required for the task?
7. Do you still need a Workflow after adding LLM and Retrieval?
Suppose every day your system must:
collect news
↓
filter
↓
classify
↓
summarize
↓
generate report
↓
send email
This is not one LLM call.
But the sequence is already known.
You can write:
Step 1
↓
Step 2
↓
Step 3
↓
Step 4
↓
Step 5
That is a Workflow.
8. Workflow solves multi-step execution, not autonomy
The defining feature of a Workflow is:
Most of the control flow is predefined by the engineer.
For example:
Fetch data
↓
if empty → Stop
↓
Clean data
↓
LLM summarize
↓
Validate
↓
Save
The workflow may contain:
- an LLM,
- RAG,
- APIs,
- tools,
- databases.
It can still remain deterministic at the control-flow level.
So:
LLM + Tools + Multiple Steps
does not automatically mean Agent.
It may simply be a well-designed Workflow.
9. Workflow has important engineering advantages
When the process is known, a Workflow is usually easier to:
debug
test
estimate cost
control latency
limit permissions
locate failures
For example:
Retrieve
↓
Summarize
↓
Validate
↓
Publish Draft
If something fails, the system can tell you:
Validation failed
That is much easier to reason about than:
Why did the Agent decide to do that?
So:
If a Workflow can solve the task reliably, do not assume you need an Agent.
10. When does Workflow stop being enough?
Return to this task:
Fix this bug.
Before execution begins, you usually do not know:
- where the bug is,
- which test will fail,
- what a code change will break,
- which file must be inspected next,
- whether the plan must change.
You cannot realistically predefine:
Step 1: read A.py
Step 2: edit line 37
Step 3: run test_x
Step 4: edit B.py
because the next step depends on the previous observation.
That is where the Agent loop becomes useful:
Observe
↓
Decide
↓
Act
↓
Observe Result
↓
Decide Again
11. Agent solves process uncertainty
The core distinction can be reduced to this:
Workflow
The next step is mostly knowable in advance
Agent
The next step must be chosen after seeing the current result
A fixed report:
Fetch
→ Calculate
→ Summarize
→ Export
is naturally a Workflow.
Debugging:
Read error
↓
Form a hypothesis
↓
Choose a file
↓
Modify
↓
Run test
↓
Choose again from the new failure
is a better fit for Agent-style control.
What Agent adds is not simply more tools.
It adds:
Dynamic Control Flow.
12. RAG and Agent are not competing choices
People often ask:
Should I build RAG or an Agent?
That question mixes different layers.
An Agent can use Retrieval:
Agent
↓
Need knowledge
↓
Retrieval
↓
Get evidence
↓
Continue deciding
You can have:
Agent + RAG
or:
Workflow + RAG
or even:
Workflow
↓
small Agent decision point
↓
RAG
↓
Deterministic Validation
These terms are better treated as:
System Components and Control Patterns
rather than mutually exclusive product categories.
13. A practical selection order
When designing an AI application, ask questions in order.
Q1
Can deterministic code solve it?
If yes:
→ Code
If not, ask:
Q2
Does the task require language or semantic reasoning?
If yes:
→ LLM
Then:
Q3
Is required information missing from the current context?
If yes:
→ Retrieval / RAG / Data Tool
Then:
Q4
Does the task require multiple steps that can mostly be predefined?
If yes:
→ Workflow
Then:
Q5
Must the next step be chosen dynamically from runtime observations?
If yes:
→ Agent
Only after that ask:
Q6
Is one Agent genuinely not enough?
14. Multi-Agent should be one of the last questions
Multi-Agent systems can look impressive:
Research Agent
Writer Agent
Reviewer Agent
SEO Agent
Manager Agent
But every added Agent also adds:
Context
State
Communication
Coordination
Latency
Cost
Failure Surface
A single Agent may have one loop.
Five Agents add questions such as:
Did A correctly understand B?
Did C use B's output correctly?
Who owns the final decision?
Are they using the same data version?
So Multi-Agent should not mean:
One Agent is not working well, so add more Agents.
15. When can Multi-Agent actually make sense?
It becomes more reasonable when several conditions are real.
1. Subproblems are genuinely independent
For example:
Technical Due Diligence
Legal Review
Market Analysis
These can be separated.
2. Different tasks need large independent contexts
Putting everything into one Agent may create:
oversized context
cross-task interference
Separation can then help.
3. Tool or permission boundaries differ
For example:
Research Agent: read-only
Deployment Agent: can modify systems
4. Parallelism creates real value
If three tasks can each take 30 minutes in parallel rather than sequentially, coordination overhead may be worth paying.
Otherwise:
If one Agent can handle it, start with one Agent.
16. Every added layer has a Complexity Tax
Moving from:
LLM
to:
LLM + RAG
adds external knowledge access.
It also adds:
Retrieval Failure
Ranking
Freshness
Context Assembly
Moving from Workflow to Agent adds dynamic decision-making.
It also adds:
State
Decision Variance
Tool Selection Error
Loop Control
Observability
Cost
Latency
Moving to Multi-Agent adds:
Coordination
Communication Failure
Shared State
Conflict Resolution
Every architectural upgrade is an exchange:
New Capability
↕
Complexity Tax
The real question is:
Is the new capability worth the additional complexity?
17. Do not use the wrong architecture to solve the wrong failure
Several mistakes appear repeatedly.
Reasoning error → add RAG
If all evidence is already in context:
Retrieval does not automatically repair reasoning.
Poor Retrieval → use a more autonomous Agent
The Agent still consumes the bad data.
It may only become:
more autonomous at using the wrong evidence
Fixed process → build an Agent
If:
A → B → C → D
is already known, a Workflow is often more appropriate.
Rule problem → use an LLM
For:
age >= 18
you do not need model reasoning.
Single Agent is weak → add Multi-Agent
If the real issue is:
unclear prompt
bad tool schema
missing context
adding more Agents multiplies the same problem.
18. Concrete examples
Case 1: calculate a refund
Requirement:
order amount + refund rate
Architecture:
Code
An LLM may not be needed.
Case 2: classify customer messages
Requirement:
natural language
→ billing / technical / account
Architecture:
LLM
because the core problem is semantic interpretation.
Case 3: answer the latest internal travel policy
Requirement:
natural-language question
+
latest internal information
Architecture:
Retrieval / RAG
+
LLM
because the missing capability is knowledge access.
Case 4: generate a fixed daily market report
Process:
Fetch
→ Filter
→ Analyze
→ Summarize
→ Validate
→ Export
Architecture:
Workflow
+
LLM
+
Retrieval
There is no need for an Agent to reinvent the process every day.
Case 5: diagnose and fix failing tests
You do not know in advance:
where the bug is
which file to inspect
what the next failure will be
Architecture starts to fit:
Agent
+
Tools
because control flow itself is uncertain.
Case 6: large cross-domain due diligence
Suppose the task truly contains:
Market
Technical
Legal
Financial
with:
- large independent contexts,
- different tools,
- parallelizable work,
- a clear integration step.
Then Multi-Agent may be justified.
It is still not the default.
19. Real production systems are usually hybrid
A production system may look like:
Deterministic Input Validation
↓
Retrieval
↓
LLM Decision
↓
Known Workflow
↓
Agent Decision Point
↓
Tool
↓
Deterministic Validation
↓
Response
A useful principle is:
Deterministic where possible, probabilistic where necessary.
That is usually easier to control than giving the entire process to an Agent.
20. Put Agent behavior at the uncertain decision points
Imagine the process is:
A → B → ? → D → E
Only the question mark requires runtime judgment.
Then there is no reason to make A, B, D, and E agentic.
You can design:
Workflow
↓
Agent Decision
↓
Workflow
Agent architecture does not mean:
The Agent must control everything.
A better question is:
Which decision points actually require agency?
21. Ask three questions before adding architecture
Before adding:
RAG
Workflow
Agent
Multi-Agent
ask:
1. Which existing failure does this solve?
If you cannot name it, do not add the component yet.
2. How will you prove the change helped?
For example:
Task Success Rate ↑
Retrieval Accuracy ↑
Human Intervention ↓
Without evaluation, you may only be increasing complexity.
3. Which new failure modes does it introduce?
For an Agent, examples include:
loop failure
tool misuse
state drift
cost increase
Are they worth the trade-off?
22. Minimum Necessary Complexity does not mean cheapest at all costs
The principle does not mean:
Always choose the simplest possible implementation.
It means:
Choose the smallest architecture that still satisfies the task requirements.
If the business requirement is:
automatically handle large volumes of open-ended troubleshooting
and a fixed Workflow cannot do it, then Agent complexity may be necessary.
But if five if / else rules solve the task, an Agent is unnecessary complexity.
23. The selection logic can be condensed into a Decision Tree
Can the task be expressed as explicit rules?
│
├─ Yes → Deterministic Code
│
└─ No
↓
Do you need language / semantic reasoning?
│
├─ Yes → LLM
│
└─ Use a traditional system where appropriate
↓
Does the LLM lack external / fresh / private information?
│
├─ Yes → Retrieval / RAG / Data Tool
│
└─ No
↓
Does the task require multiple known steps?
│
├─ Yes → Workflow
│
└─ No
↓
Must the next step change from runtime observations?
│
├─ Yes → Agent
│
└─ No → Keep the simpler architecture
↓
Can one Agent reasonably handle the task,
and are the subproblems truly independent / parallel?
│
├─ No → Single Agent
│
└─ Consider Multi-Agent
This is not a universal formula.
It is a way to avoid choosing the most impressive architecture before understanding the problem.
24. Architecture Thinking
Across this series, the question gradually changes.
At first:
Which model is best?
Then:
How should I write the prompt?
Then:
Do I need RAG?
Then:
Do I need an Agent?
A better sequence is:
What is the task?
↓
Where is the uncertainty?
↓
What capability is the simplest system missing?
↓
Which layer closes that gap?
↓
How will we prove the added complexity is worth it?
That is Architecture Thinking.
25. If the answer is Agent, the next problem begins
Suppose the decision process ends with:
This task genuinely needs an Agent.
The next question should not immediately be:
Which Agent framework should I use?
It should be:
What components let this Agent maintain a working closed loop?
The previous article introduced:
Goal
↓
State
↓
Decision
↓
Action
↓
Observation
But what belongs in State?
How should the model use Tools?
How does information persist across multiple steps?
What is the difference between Memory and Context?
That is the focus of Article 08: