🚫 Stop building AI agents. Here’s what you should build instead

Guest collaboration post with AI instructor Hugo Bowne-Anderson

Hi fellow High Growth Engineer, Jordan here 👋

Today’s article features a special guest, Hugo Bowne-Anderson, AI scientist and instructor of a top-rated LLM/AI course on Maven. In this article, you’ll learn why AI agents are often the wrong first choice and what to do instead. Hugo walks through multiple patterns you should use, when to use them, and how—with brief code snippets.

Without further ado, I’ll pass the mic 🎤 to Hugo 👏

---

I’ve taught and advised dozens of teams building LLM-powered systems. There’s a common pattern I keep seeing, and honestly, it’s frustrating.

Everyone reaches for agents first.

They set up memory systems. They add routing logic. They create tool definitions and character backstories. It feels powerful and it feels like progress. Then… everything breaks. And when things go wrong (which they always do), nobody can figure out why.

Did the agent forget its task? Did the wrong tool get selected? Or is the whole system fundamentally brittle?

I learned this the hard way. Six months ago, I built a “research crew” with CrewAI. It used three agents with five tools and had perfect coordination on paper. But in practice? The researcher ignored the web scraper, the summarizer forgot to use the citation tool And the coordinator gave up entirely when processing longer documents. It was a beautiful plan falling apart in spectacular ways.

I created the flowchart below after debugging numerous broken agent systems. Notice that tiny box at the end? That’s how rarely you actually need agents. But too many people start there.

Flowchart showing when to use an agent

This post is about what I learned from those failures and how to avoid them.

The patterns I’ll walk through are inspired by Anthropic’s Building Effective Agents post. But this isn’t theory. This is real code, real failures, and real decisions I’ve made while teaching these systems. Every example here comes from actual projects I've built or debugged.

You’ll discover why agents aren’t the answer (most of the time). And more importantly, you'll learn what to build instead. The examples will be from this GitHub notebook.

⛔ Don’t Start with Agents

Everyone thinks agents are where you start. It’s not their fault: frameworks make it seem easy, demo videos are exciting, and tech Twitter loves the hype.

But here’s what I learned after building that CrewAI research crew: most agent systems break down from too much complexity, not too little.

In my demo, I had three agents working together:

1. A researcher agent that could browse web pages

2. A summarizer agent with access to citation tools

3. A coordinator agent that managed task delegation

Pretty standard stuff, right? Except in practice:

• The researcher ignored the web scraper 70% of the time

• The summarizer completely forgot to use citations when processing long documents

• The coordinator threw up its hands when tasks weren’t clearly defined

So wait: what exactly is an agent? To answer that, we need to examine 4 characteristics of LLM systems.

1. Memory: Let the LLM remember past interactions

2. Information Retrieval: Add RAG for context

3. Tool Usage: Give the LLM access to functions and APIs

4. Workflow Control: The LLM output controls which tools are used and when
   ^ THIS makes an agent

Source - Anthropic article on workflows vs. agents

When people say “agent,” they mean that last step: the LLM output controls the workflow. Most people skip straight to letting the LLM control the workflow without realizing that simpler patterns often work better. Using an agent means handing control to the LLM. But unless your task is so dynamic that its flow can’t be defined upfront, that kind of freedom usually hurts more than it helps. Most of the time, simpler workflows with humans in charge still outperform full-blown agents.

I’ve debugged this exact pattern with dozens of teams:

1. We have multiple tasks that need automation

2. Agents seem like the obvious solution

3. We build complex systems with roles and memory

4. Everything breaks because coordination is harder than we thought

5. We realize simpler patterns would have worked better

Takeaway: Start with simpler workflows like chaining or routing unless you know you need all the characteristics we listed.

✅ Workflow patterns you should use

The following five patterns come from Anthropic’s taxonomy. For each pattern, we’ll walk through a sample use case, why you’d use it, and the code to implement it. Feel free to reference the GitHub notebook as needed to see the full tests and demos I did.

(1) Prompt Chaining

Use case: Writing personalized outreach emails based on LinkedIn profiles

You want to reach out to people at companies you’re interested in. Start by extracting structured data from a LinkedIn profile (name, role, company) then generate a tailored outreach email to start a conversation.

Prompt chaining

✅ Use when tasks flow sequentially.
⚠️ Be cautious about errors at each step. Implement error handling tailored to your use case.

(2) Parallelization

Use case: Quickly extracting structured data from profiles

Now that chaining works, you want to process many profiles in parallel and speed up processing. Split each profile into parts — like education, work history, and skills, then run extract_structured_data() in parallel.

Parallelization

✅ Use when LLM calls don’t depend on each other.
⚠️ Be cautious about diving up too many LLM calls and API costs.

(3) Routing

Use case: Support bot uses the most appropriate logic based on the input. The LLM classifies the input and sends it to a specialized workflow

Say you’re building a support tool that handles product questions, billing issues, and refund requests. The routing logic classifies each message and sends it to the right workflow. If it’s unclear, it falls back to a generic handler.

Routing

✅ Use when different inputs need different, predefined handlers.
⚠️ Be cautious about unmatched handlers. Define a catch-all just in case.

(4) Orchestrator-Worker

Use case: Creating specialized emails to send to recruiters to ask for a position. The sections of the email are dynamic based on the info available in the recruiters’ profile.

In the orchestrator-worker case, the subtasks are determined by the orchestrator dynamically at runtime. This gives more control to the LLM, but it might be necessary if you can’t define all the subtasks upfront.

The orchestrator then passes each task to a worker for processing.

Orchestrator-Worker: Anthropic shares a detailed example in their cookbook too

✅ Use when large tasks need a distinct set of subtasks.
⚠️ Be cautious about the orchestrator breaking the task down incorrectly. Keep orchestrator logic simple and use a high-quality prompt to determine which sub-tasks are needed.

(5) Evaluator-Optimizer

Use case: Refining outreach emails to better match your criteria

You have an email generator running, but you want to improve the tone, structure, or alignment. Add an evaluator that scores each message and, If it doesn’t pass, send it back to the generator with feedback and loop until it meets your bar.

Evaluator-Optimizer

✅ Use when output quality matters more than speed.
⚠️ Be cautious about infinite optimization loops. Set a limit for looping.

👍 When to Use Agents (If You Really Have To)

As you can see, most use cases don’t need agents. They need a better workflow structure. The cases that do need agents often have unstable workflows that can’t be well-defined upfront. Here are a few examples…

Example 1: Data Science Assistant

An agent that writes SQL queries, generates visualizations, and suggests analyses. You’re there to evaluate results and fix logical errors. The agent’s creativity in exploring data beats rigid workflows.

To build something like this, you’d give the LLM access to tools like run_sql_query(), plot_data(), and summarize_insights(). The agent routes between them based on the user’s request — for example, writing a query, running it, visualizing the result, and generating a narrative summary. Then, it feeds the result of each tool call back into another LLM request with its memory context. We walk through a live example of this pattern in our Building with LLMs course.

LLM calls tools and feeds results into more LLM calls

Example 2: Creative Writing Partner

An agent that brainstorms headlines, edits copy, and suggests structures. A human judges the quality and readjusts the agent as needed. Agents excel at ideation with human judgment.

Example 3: Code Refactoring Assistant

Proposing design patterns, catching edge cases, and suggesting optimizations. The developer reviews and approves changes. Agents spot patterns humans miss.

🚫 When NOT to use agents

• Enterprise Automation: Building stable, reliable software? Don’t use agents. You can’t have an LLM deciding critical workflows in production. Use orchestrator patterns instead.

• High-Stakes Decisions: Financial transactions, medical diagnoses, and legal compliance need deterministic logic, not LLM guesswork.

Returning to my CrewAI agent example, the agents frequently forgot their goals and skipped tools. Here’s what I learned:

1. ❌ Agents assumed they had context they didn’t. Long documents caused the summarizer to forget citations entirely.
   ✅ Now, I would use explicit memory systems, not just role prompts.
   

2. ❌ Agents failed to select the right tools. The researcher ignored the web scraper in favor of general search.
   ✅ Now, I’d constrain choices with explicit tool menus.
   

3. ❌ Agents did not handle coordination well. The coordinator gave up when tasks weren’t clearly scoped.
   ✅ Now, I’d build explicit handoff protocols via the workflows we discussed above, rather than using free-form delegation.

When to use an LLM, augmented LLM, or Agent

📖 TL;DR

• ❌ Agents are overhyped and overused

• 🔁 Use the 5 workflow patterns we discussed: prompt chaining, parallelization, routing, orchestrator-worker, and evaluator-optimizer. Refer to my GitHub Notebook or Anthropic’s Cookbook as needed.

• 🤝 Agents excel in human-in-the-loop scenarios

• ⚠️ Don’t use agents for stable enterprise systems

• 🧪 Build with observability in mind through explicit control

🙏 Thank you to Hugo

👋 Jordan back. Thanks, Hugo, for the highly informative article and not only for debunking common misconceptions about agents but also for showing what to do instead.

As a reminder, Hugo teaches a top-rated cohort course on Maven that goes even deeper. You learn about RAG, embeddings, vector stores, evals, and more, plus build full AI applications. I recommend checking it out to learn more.

👏 Shout-outs of the week

• Killing the tiny annoyances in work and life on

  Manager.dev
  by Anton Zaides — Relatable article with actionable tips for reducing stress from the little things.

• How to form a genuine rapport with senior leaders on

  A Life Engineered
  by Steve Huynh — Practical advice and stories for working with senior leaders. I’ve found “Be brilliant, be brief, be gone” and the open/close loop to be most helpful in the past. I didn’t know it was called that though, as I usually instead say, follow up on what you say you’ll do!

• Arguing point by point considered harmful by Sean Goedecke — Addresses a common behavioral trap many engineers fall into and what to do instead.

---

Thank you for reading and being a supporter in growing the newsletter 🙏

You can also hit the like ❤️ button at the bottom of this email to support me or share it with a friend to earn referral rewards. It helps me a ton!