AI agents are everywhere.
Multi-agent systems.
Agent swarms.
Autonomous teams.
Planning agents.
Self-improving agents.
It seems every week a new framework appears promising to build the next generation of autonomous AI systems.
After spending considerable time studying and experimenting with AI workflows, I have come to a simple conclusion:
I think most AI agents are overengineered.
That doesn't mean agents are useless.
Far from it.
I simply believe many builders are solving problems with agents that could be solved with something much simpler.
The Industry Loves Complexity
Let's imagine you want to build a system that:
- Reads PDFs.
- Extracts information.
- Stores embeddings.
- Answers questions.
I've seen builders create architectures like this:
Research Agent
↓
Planner Agent
↓
Retriever Agent
↓
Memory Agent
↓
Answer Agent
↓
Reviewer Agent
Six agents.
Multiple prompts.
Complex state management.
Retries.
Memory synchronization.
And a lot of headaches.
Meanwhile, the same problem can often be solved with:
PDF → Chunk → Embed → Vector DB → LLM → Response
Sometimes a workflow is enough.
Not everything needs an agent army.
Workflows Solve Most Problems
In my experience, most AI applications are deterministic.
They follow a sequence:
Input
↓
Transform
↓
Retrieve
↓
Generate
↓
Output
Examples include:
- Document Q&A
- Customer support
- Meeting summaries
- Blog generation
- Code review
- Knowledge assistants
These are workflows.
Not autonomous systems.
And workflows are:
- Easier to debug
- Easier to scale
- Easier to maintain
- Easier to explain
Complexity should be earned, not assumed.
Agents Introduce Hidden Costs
Every additional agent brings:
More prompts
Which means more tokens.
More latency
Each step adds execution time.
More hallucination opportunities
One bad output propagates downstream.
More debugging pain
Finding failures becomes difficult.
More infrastructure complexity
Memory, orchestration, retries, and monitoring become necessary.
What started as a simple application suddenly becomes an engineering project.
Most Builders Don't Need Multi-Agent Systems
Let's compare.
Simple Workflow
documents → embeddings → Chroma → GPT → answer
Simple.
Reliable.
Fast.
Now compare that to:
Planner Agent
↓
Retriever Agent
↓
Research Agent
↓
Critic Agent
↓
Memory Agent
↓
Final Writer Agent
Do you really need six agents to answer questions from a PDF?
Probably not.
Where Agents Actually Shine
I'm not anti-agent.
I think agents are powerful when:
Long-running tasks exist
For example:
- Researching across multiple websites
- Monitoring APIs
- Scheduling actions
- Autonomous coding loops
Decision-making is required
For example:
if bug_found:
fix_code()
elif tests_fail:
rerun()
else:
deploy()
Human intervention matters
Human-in-the-loop systems benefit greatly from agent architectures.
Multiple tools must collaborate
Email.
GitHub.
Slack.
Databases.
Web search.
This is where agents become interesting.
I Believe Workflows Matter More Than Agents
One thing I've learned is that builders often jump directly into agent frameworks.
CrewAI.
LangGraph.
AutoGen.
And many others.
But before building agents, I think we should first ask:
Can a workflow solve this?
If the answer is yes, start there.
Only introduce agents when complexity demands them.
Not because Twitter says agents are the future.
In fact, I recently shared some of my favorite repositories in:
"7 GitHub Repositories I Recommend to Every AI Builder"
Some of those tools are incredibly powerful—but power doesn't always mean more complexity.
Sometimes the best architecture is the simplest one.
The Software Industry Has Seen This Before
Microservices.
Kubernetes.
Distributed systems.
Event-driven architectures.
Many teams adopted them before they truly needed them.
AI may be repeating the same pattern.
Builders see impressive demos and assume every project needs:
- Agent memory
- Multi-agent orchestration
- Planning loops
- Reflection agents
But complexity isn't innovation.
Complexity is cost.
My Rule
I follow a simple principle:
- Workflow first.
- Agent second.
- Multi-agent last.
Start with the simplest architecture possible.
Only add complexity when reality demands it.
Not because hype demands it.
Final Thoughts
AI agents are exciting.
Frameworks like LangGraph and CrewAI are pushing the ecosystem forward.
And I believe autonomous systems will play a major role in the future.
But today, I think many AI builders are overengineering solutions.
Most problems don't require a team of agents.
Most problems require clear workflows.
Because at the end of the day, users don't care whether your application has twelve agents.
They care that it works.
And in engineering, simplicity is often the most underrated feature.
Top comments (7)
Very true. I built an autonomous accounting suite, which uses LLMs to extract data and store it to the db. But a LLM call for getting the text, the layout, document classification, template creation and understanding? It wasnt cost effective, let alone with quotas (which is stupid for pay as you go usage imo), so I stripped the LLM from everything but understanding, replaced it all with a custom OCR engine that swarms. Result is it runs faster now, makes less errors and costs pennies to the dollar what it used to cost per page. We rely too heavily on using a hammer for every problem, when often times it shatters the entire vision. AI is amazing, but it's not the next computer, it's the next Excel. Dont rely on it for everything, use it for what it's meant for (i.e. dont go making rollercoaster tycoon in excel...)
This is a great real-world example of using AI where it creates the most value instead of forcing it into every step. I like the architecture you ended up with, using traditional OCR for deterministic tasks and reserving the LLM for reasoning. That's a much more efficient design.
Your point about "using a hammer for every problem" really resonates. The best AI systems I've seen are hybrid systems, where each component does what it's best at. Thanks for sharing your experience; it reinforces that good engineering is still about choosing the right tool for the job.
Honestly, lately I've been looking at things from a hardware perspective and determined. We've been doing surgery with a spoon... It took building a new file format, a new data transport layer and it formed the basis of a new architecture I named V.E.L.O.C.I.T.Y. and I've been experimenting... It started off with a Messenger app, a file-share app, a remote desktop app and a mcp server. Each I had to write custom codecs and rebuilt practically every component, Followed by what started as an extension for vs code, but I ended up building an entire ide built on velocity and it's 1000-150000x faster than vs-code... So I integrated LLM functionality directly into it. Then the model was the slowest part of the system, so I built a custom runtime, which gave a decent boost, but still limited, so I converted the model weights, caches and tokenizer to my file system, result is a 4x compression in kv-cache size, while decreasing latency. Model weights convert in 10 seconds from FP32 to NDA, which is built to operate similar to b1.58, but with auditability and runtime security (no more prompt injecting or weight poisoning) and it's faster, I still need to fully benchmark it, but sofar it's remarkably faster than running the models the native way.
What this goes to show, is often times, the right tool for the job, is actually a new tool all together, because relying on industry standards from 20 years ago... In the age of AI... Really isnt the smartest move. Even JSON didnt make the cut, because of the serialization bloat, it alone adds a massive performance penalty. Sometimes you need to use a scalpel to dismantle everything bit by bit, just to understand why it's not optimal.
That's an impressive journey. What stands out to me isn't just the performance gains, but your willingness to question assumptions all the way down the stack instead of accepting existing abstractions.
Your point about creating new tools rather than forcing old ones into new problems is a good reminder that AI isn't just changing software; it may also reshape the infrastructure beneath it. It'll be interesting to see how your benchmarks compare once everything is fully validated.
I agree that many AI agent projects add layers of orchestration, memory systems, and tools before validating whether the task actually requires them. In many cases, a well-designed workflow or prompt can outperform a complex agent architecture with lower cost and higher reliability.
I completely agree. One of the biggest mistakes today is adding agent complexity before proving the problem needs it.
A simple, well-designed workflow is often faster, cheaper, and more reliable than a multi-agent system. The best architecture is usually the simplest one that solves the problem well.
This is the best time to build, however, the distribution has become difficult.