Agentic AI: Capability vs Architecture
Introduction
“Agentic AI” is the buzzword of the moment. It’s everywhere in my feed, often accompanied by complex diagrams of five different bots talking to each other to accomplish a task. But there is a growing pattern of confusion: smart people are equating “Agentic AI” solely with these complex “Multi-Agent Systems” (MAS).
It’s time to clear up the confusion. Agentic AI is a capability, while Multi-Agent Systems are just one specific architecture for achieving it.
Important: A single, well-orchestrated LLM loop that can plan, act, and observe is 100% Agentic AI. You don’t always need a squad to be agentic.
What is it?
At its core, Agency refers to the capability of a system to be autonomous. It’s not about how many models are running; it’s about what the system can do.
An Agentic system isn’t just a passive chatbot waiting for a prompt. It has a loop:
- Understand a high-level goal (parse intent, extract constraints)
- Plan the approach (decompose into subtasks, choose tools)
- Act using tools (search, run code, query databases, call APIs)
- Observe results and self-correct (evaluate, replan if needed)
The magic is in step 4: Observation & Self-Correction. When a tool returns an error or unexpected result, the agent doesn’t just fail—it adapts. It might switch strategies, try a different tool, or break down the task differently. This adaptive loop is what makes it “agentic.”
Example: An agent trying to scrape a webpage gets a 403 error. Instead of stopping, it observes the failure and switches to a headless browser tool. That’s agency.
If a single script running one LLM can do this loop, it is an agent.
Why does it matter?
We need to stop using “Agentic” and “Multi-Agent” interchangeably because it leads to over-engineering.
- The Capability: A system that can autonomously plan, use tools, and achieve a goal.
- The Architecture: Assigning those tasks to a squad of specialized bots vs. one generalist.
If you assume you need a “Multi-Agent System” to be “Agentic,” you might build a complicated system when a simple loop would have sufficed.
How it works
To understand the difference, let’s visualize it with a kitchen analogy: The Brain vs The Room.
The Single Agent: The Master Chef
Imagine a Master Chef in a small, high-end kitchen. They are autonomous, capable, and self-correcting (planning, cooking, tasting). They carry all the context in their head and can switch tasks rapidly.
The Multi-Agent System: The Kitchen Brigade
Now imagine a huge hotel kitchen with specialized chefs (Sauce, Grill, Pastry) and an Expeditor. This is a Multi-Agent System. It’s powerful for massive operations but comes with communication overhead.
| Kitchen Role | Technical Equivalent | Function |
|---|---|---|
| Sauce Chef | Database Agent | Accesses internal SQL/Vector DBs. |
| Grill Chef | Coder Agent | Generates and executes Python/JS code. |
| Expeditor | Orchestrator | Routes tasks, manages state, and ensures the final JSON is valid. |
The Soft Boundary: Persona Switching
There is a powerful middle ground called Persona Switching. Instead of multiple agents, you use one agent but dynamically swap its system prompt during the loop.
How it works: You keep a single LLM instance but change its “role” at each phase:
- Phase 1: “You are a strategic planner” → Generates task breakdown
- Phase 2: “You are a Python expert” → Writes implementation code
- Phase 3: “You are a code reviewer” → Finds issues and suggests fixes
Benefits:
- ✅ Single context window (no communication overhead)
- ✅ Simpler debugging (one execution trace)
- ✅ Lower cost (one LLM instance)
- ✅ Maintains “separation of concerns”
Limitations:
- ❌ Can’t run in parallel
- ❌ Potential “persona bleed” between phases
Sweet Spot: 2-4 distinct personas for sequential workflows. Covers 80% of use cases without the complexity of true multi-agent systems.
Decision Framework: When to Choose What
| Factor | Single Agent | Persona Switching | Multi-Agent |
|---|---|---|---|
| Task Complexity | Linear workflows | Sequential phases | Parallel specialized tasks |
| Context Size | < 50K tokens | < 100K tokens | > 100K tokens (split required) |
| Prompt Length | < 1000 words | < 2000 words | > 2000 words (conflicting instructions) |
| Execution Pattern | Sequential steps | Sequential with role changes | Parallel or async operations |
| Cost | $ (lowest) | $ (low) | $$$ (multiple LLM instances) |
| Use When | Simple automation | Role-based workflows | Need parallelism or isolation |
Quick Guide:
- ✅ Start with Single Agent for most tasks
- ✅ Upgrade to Persona Switching when you need distinct “modes” of thinking
- ✅ Go Multi-Agent only when you hit context limits, need parallelism, or require isolated failure domains
Examples
1. The “Web Scraper” Loop (Single Agent Capability)
Imagine finding a product price:
- Loop 1 (Plan): Search Google.
- Loop 2 (Act): Scrape URL. Result: 403 Forbidden.
- Loop 3 (Observe & Correct): Switch to headless browser tool.
- Loop 4 (Success): Extract price. Agency is the loop, not the number of bots.
2. The Context Wall (When to use Multi-Agent)
You need to summarize 50 long PDF contracts. A single agent’s context window will choke.
- Solution: Split it. Agent A (Researcher) searches and summarizes PDFs. Agent B (Writer) takes summaries and writes the report.
3. The Instruction Wall (When to use Multi-Agent)
Your prompt is 3,000 words long trying to teach one model to be a Lawyer, Coder, and Poet. It forgets rules.
- Solution: Split prompts. dedicated “Coder Agent” and “Reviewer Agent”.
Common Pitfalls to Avoid
1. The “Smart Wrapper” Trap
Wrapping an LLM in a for-loop doesn’t make it agentic. True agency requires observation, replanning, and tool use—not just retries with the same prompt.
2. Over-Decomposition
Creating 10 micro-agents for a simple task adds communication overhead that exceeds the value. Start simple, scale only when needed.
3. Unclear Success Criteria
Agents loop forever if they don’t know when to stop. Always define explicit exit conditions and max iterations.
4. Ignoring Costs
Multi-agent isn’t “free parallelization.” You’re paying for multiple LLM calls, state management, and orchestration overhead.
Conclusion
Don’t fall into the trap of over-engineering. Start with the Master Chef (Single Agent). Build the Brigade (Multi-Agent) only when the kitchen gets too chaotic.
What about you? Are you finding yourself building squads when a single agent would do?