Agents & Agentic AI· Lesson 6 of 6
- 1What Is an Agent?8 min
- 2The Agent Loop9 min
- 11The ReAct Pattern — The Agent That Thinks Before It Acts8 min
- 20Reflection — The Agent That Reviews Its Own Work9 min
- 21The Evaluator–Optimizer Pattern — One Builds, One Judges9 min
- 22What Do You Build Agents With? — No Framework, LangGraph, CrewAI, or AutoGen?10 min
What Do You Build Agents With? — No Framework, LangGraph, CrewAI, or AutoGen?
In one line · **The model and the tools are identical in every case — you're choosing who manages the loop, the state, and the coordination between agents. And at BuildAI: learn with a loop you wrote by hand first — here's why…**
- An agent framework does not make the agent smarter — all the intelligence is in the model, all the capability is in the tools. The framework only organizes the loop and the state.
- Four options: no framework (your own hand-written loop — BuildAI's default for learning), LangGraph (explicit graphs with state and checkpoints), CrewAI (teams with ready-made roles), AutoGen/AG2 (conversational multi-agent with a research flavor).
- The criterion: how much does your flow actually need complex state or multiple agents? Not how impressive the framework's demo is.
- 💸 Frameworks don't reduce tokens — and multi-agent multiplies them. Remember the "$40 agent run" challenge.
- 🔥 This landscape is the fastest-moving in the entire field — check the date on any comparison you read, including this page.
Agents are the highest-hype area in AI right now — which means it's the area where decisions get made by announcements, not engineering. A demo of an agent team building a company in 3 minutes? Impressive. What's not in the demo: the bill, the failure rate, and the debugging night you'll spend figuring out why the "Researcher" and the "Writer" exchanged pleasantries for 80,000 tokens.
And this decision is riskier than the RAG stack decision for a specific reason: in RAG, the framework wraps a pipeline with fixed steps — the worst case is not being able to see a prompt. In agents, the framework manages a loop that makes decisions — when it breaks, you're trying to understand emergent behavior inside a closed box. A different level of pain.
Hence the rule you'll hear often at BuildAI: "If you can't write an agent loop by hand, no framework will save you."
Recall the agent loop: the model sees the goal, decides on a tool, your code executes it, the result comes back, and it repeats until done. That loop — a while loop around a tool-calling call — is the whole agent.
So what do frameworks sell? Three things missing from the naive loop: state management (what's been done, where we stopped, how to resume after an interruption), complex branching (if this, go here; loop back for review; then fork), and multi-agent coordination (who speaks, who decides, who stops whom).
If your task doesn't genuinely need those three — and most tasks don't — your simple loop beats any framework.
A real example — the same task, four mindsets
The task: "Research a topic and write a report."
| Option | Shape of the solution | What actually happens |
|---|---|---|
| No framework | One loop: model + search tool + file-writing tool | 30–60 lines, every step visible in your log, and you control the stop condition yourself |
| LangGraph | Graph: research node → drafting node → review node, with persisted state | Roughly the same calls + the ability to resume from any node if the system goes down |
| CrewAI | Crew: a "Researcher" and a "Writer" with written roles | Two agents exchanging messages — more calls, and role prompts injected without you |
| AutoGen (AG2) | A conversation between agents until they agree the work is done | The most flexible and least predictable — when did they "agree"? An open question |
Same model in all four. Same tools. The final report's quality won't differ fundamentally — what differs: the number of calls, the control, and what debugging looks like. Hold on to that observation — it is the crux of the whole decision.
| # | ❌ Wrong | ✅ Right |
|---|---|---|
| 1 | Multi-agent theater: five agents with fancy job titles doing work one agent with a good prompt would finish | Start with one agent. Split only when you've seen with your own eyes that one task fails because it's genuinely two different tasks |
| 2 | A framework before your first loop: your first-ever agent built with a ready-made crew | Write the loop by hand once — after that you'll read any framework knowing exactly what it wraps |
| 3 | Running with no limits: "let's see what it does first" | Budget cap, iteration cap, and timeout before the first run — an agent with no ceiling will find one in your bill |
| 4 | Judging by the demo: the framework was evaluated from a 3-minute video | Evaluate on your task, with your metrics: success rate, cost per task, and debugging time when it fails |
| 5 | Neglecting observability in the hand-written loop: "it works, we'll add logging later" | Log every decision, every tool call, and every cost from day one — in agents this isn't a luxury, it's your eyes |
Misconceptions
1) "The framework makes the agent smarter" — ❌ No — it only organizes. Every decision is made by the model, every capability comes from the tools, and neither changes when you swap frameworks. If your agent gets lost mid-task, change the model or improve the prompts and tools — moving the same lost loop into an elegant graph gives you the same lostness, just organized.
2) "Multi-agent beats single-agent" — ❌ Not a rule. Splitting a task across agents adds real communication and coordination cost (you saw the numbers above) — and the gain only comes when the task genuinely benefits from context separation or true specialization. In most cases we see, multi-agent is solving a problem a better system prompt would have solved.
3) "Serious companies use frameworks — a hand-written loop isn't production-grade" — ❌ The opposite is actually widespread: many production systems — including ones running millions of tasks — are built on direct loops over the tool-calling APIs, precisely for control and clarity during incidents. Production-grade is a property of the guardrails, the observability, and the evals — not of the dependency's name in your requirements file.
Cost — the full honesty
Same truth as the RAG stack, and it matters more here: the framework doesn't reduce tokens or add them in itself. The bill comes from model calls, and a loop that runs 10 times pays for 10 calls — hand-written or in the fanciest graph on the market.
What actually changes the bill is the multi-agent decision — because it multiplies calls by nature: each agent thinks with its own calls, and every message between them is carried with its context. A quick estimate using the rough numbers from the "$40 agent run" challenge:
> 💸 Rough calculation *(Volatile fragment — prices for illustration)*: A research task with one agent: ~12 calls × ~4,000 average input tokens ≈ 50k tokens ≈ $0.20. The same task with a crew of 3 agents messaging each other: every exchange reloads context for each party — easily 4–6× the calls with longer context per call ≈ $1–1.5. Roughly the same quality. If the flow loops with no clear stop bound (the open-conversation pattern): this is where the "$40 per run" stories are born.
The rule: budget caps and iteration caps before the first run, not after the first bill. And that's your responsibility under every option — no framework sets them for you with adequate defaults.
| Your situation | The call | Why |
|---|---|---|
| You're learning agents | No framework | The loop is the lesson — wrapping it means cancelling the lesson |
| One agent with a limited toolset (customer support, research, task automation) | No framework | A loop + hand-built guardrails is simpler, clearer, and cheaper — and it's most real-world usage anyway |
| A long flow with serious state: many steps, branches, human approvals, must resume after interruption | LangGraph | Checkpoints and explicit state are exactly what it sells — and here it earns its price |
| The problem genuinely looks like roles: content/analysis production lines with clear specialized stages | CrewAI | Role templates save real work — but only after you've proven one agent isn't enough |
| Research and experimentation in multi-agent collaboration patterns | AutoGen (AG2) | The widest experimentation space — with strict cost limits from second one |
| Production with minimal dependencies and clearest accountability | No framework / LangGraph if state forces itself | Every extra layer in a decision-making system = extra ambiguity during incidents |
- Don't hand-write complex state management out of stubbornness: if your loop now contains manual checkpointing, resume logic, and tangled approval gates — you're reinventing LangGraph as a less-tested copy. Migrating at that point is a sound engineering decision, not a defeat.
- Don't condemn role frameworks over a mismatched experiment: if you tried CrewAI on a task one agent could handle and it came out expensive and slow — that's a verdict on your task selection, not the tool. On genuine role pipelines it delivers real value.
- And don't stay "framework-free" when you need ready-made observability: mature frameworks ship with integrated tracing. If you build your own loop, building logging and tracing is on you — and neglecting it is the most expensive mistake in agent systems specifically.
Alternatives — the four real options as they actually are
### (a) No framework — your loop on top of the tool-calling API
| ✅ Strengths | ❌ Weaknesses |
|---|---|
| You understand every step — the loop, the guardrails, and the stop condition are all your code | State, resumability, and checkpoints are on you if you need them |
| Direct debugging: your log tells the whole story | With heavy branching, the loop turns to spaghetti if not designed well |
| Zero dependencies and zero churn | Serious multi-agent coordination you'll build by hand — and that's real work |
BuildAI's learning default — and the Customer Support Agent and Research Agent projects are built this way deliberately. Not austerity: building the loop by hand is the only known way to understand agents.
### (b) LangGraph — state as a first-class citizen
| ✅ Strengths | ❌ Weaknesses |
|---|---|
| An explicit graph: nodes, edges, and defined state — complex flow becomes readable instead of buried in ifs | A real learning curve — you're learning a way of thinking, not just an API |
| Checkpoints and resumability built in: long flows that must continue after an interruption or a human approval | Frank overkill for a simple single-loop agent |
| That explicitness is itself debugging: you know which node you're in and why | Tied to the LangChain ecosystem and its pace of change 🔥 |
### (c) CrewAI — the ready-made roles
| ✅ Strengths | ❌ Weaknesses |
|---|---|
| The fastest path to role-division patterns: Planner / Researcher / Writer defined in a few lines | Pushes you toward multi-agent even when one agent was enough — and the bill doubles silently |
| Ready collaboration templates instead of hand-writing a communication protocol | Less control over each agent's inner loop details |
| — | 🔥 A younger project — check its maturity when you read this, not when this page was written |
### (d) AutoGen (AG2) — conversation as the coordination model
| ✅ Strengths | ❌ Weaknesses |
|---|---|
| A very flexible model: agents converse until the task is done — strong for exploration and experimentation | "They converse until done" = inherently weaker cost and time bounds — the most dangerous for your bill |
| A research flavor: experimental coordination patterns land here first | The distance from demo to disciplined production is longer than the alternatives |
> 🔥 Volatile fragment: This list is not exhaustive — the market produces new names every month (and the model platforms themselves keep adding built-in agent capabilities that eat into what frameworks do). The criteria on this page are stable — apply them to any new name.
Trade-offs
| Criterion | No framework | LangGraph | CrewAI | AutoGen (AG2) |
|---|---|---|---|---|
| Control over the loop | ✅ Full | ✅ High (you draw the graph) | ⚠️ Medium | ❌ Lowest — the conversation takes its course |
| Debuggability | ✅ Direct | ✅ Good (the current node is known) | ⚠️ Medium | ❌ Hardest — emergent behavior from a conversation |
| State & resumability | ❌ On you | ✅ Strongest — it's the whole job | ⚠️ Basics | ⚠️ Basics |
| Multi-agent speed | ❌ Slow — the protocol is yours to write | ⚠️ Possible with explicit construction | ✅ Fastest | ✅ Fast |
| Out-of-the-box observability | ❌ You build it | ✅ Integrated | ⚠️ Medium | ⚠️ Medium |
| Cost discipline | ✅ You hold the meter | ✅ Limits easy to build | ⚠️ Watch the agent count | ❌ Riskiest — set a hard budget |
| Breaking-change churn 🔥 | ✅ Zero | ⚠️ Present | ❌ High (youngest) | ⚠️ Present (including a rename of the project itself) |
| Community size | — (the raw-API community) | ✅ Currently the largest | ⚠️ Medium and growing | ⚠️ Medium, academically inclined |
Interview questions
Q1: When do you build an agent without a framework, and when do you use one? The strong answer states the criterion before the names: the choice is about managing the loop, the state, and the coordination — not about intelligence, because the model and tools are constants. One agent with a simple flow → a direct loop. Complex state needing resumption and checkpoints → LangGraph. A role pipeline proven by experiment → a role framework. And close with the cost line: the framework doesn't save tokens, and multi-agent multiplies them.
Q2: What makes multi-agent systems expensive, and how do you control it? Every agent thinks with its own calls, and every inter-agent message is carried with repeated context — so calls and tokens multiply with each additional party, with no guarantee of higher quality. Control: the fewest agents that prove their necessity, budget and iteration caps, a compressed shared context instead of resending everything to everyone, and cost-per-task measured as a permanent KPI.
Q3: Your team proposes a 5-agent system: Planner, Researcher, Writer, Critic, and Manager. How do you evaluate the proposal? The judgment question of the moment. The mature answer demands the evidence: did we try one agent with a well-designed prompt? Where's the documented failure? Then it asks for the numbers: cost per task under both designs? What's the stop bound on the Critic–Writer loop? Most of the time the team discovers the 5 roles were simulating a company org chart, not solving a problem — and that two (a doer + a reviewer) achieve the same quality at a quarter of the cost.
- Inside BuildAI (in order): Agents vs. workflows vs. chains → Guardrails & boundaries → Agent cost management → Multi-agent preview.
- Tool documentation: 🔥 The official LangGraph, CrewAI, and AG2 pages change fast — read them dated today, not from 6-month-old comparison articles (in this market, 6 months = an entire geological era).