Matt Viteri.Blog
Book a call Black and white photo of Matt Viteri

DeepLearning.AI’s Agentic AI Course: Who I’d Recommend It To

Technical Learning

November 1, 2026
5 min read
By Matt Viteri

Building an AI workflow can be easy to get started with and harder to improve.

You connect a model to a few tools, give it instructions, and get something that works on the examples you try. Then it misses information, takes an unexpected path, or produces an answer that looks reasonable but isn’t useful. What do you change first?

I recently went through Andrew Ng’s Agentic AI course from DeepLearning.AI. It brings the main patterns for building these workflows together with a process for figuring out where they fall short. For engineers moving into this work, that combination makes it a course I’d recommend.

Core Themes

The course covers how to build AI workflows that carry out tasks across multiple steps. At a high level, it focuses on:

  • Task decomposition: breaking a larger task into smaller steps and deciding what each step needs to accomplish.
  • Agentic design patterns: reflection, tool use, planning, and collaboration between agents.
  • Tools and integrations: connecting models to information and capabilities outside the model itself, including an introduction to MCP.
  • Evaluation and error analysis: examining results, finding recurring problems, and measuring whether changes help.
  • Quality, latency, and cost: understanding how individual parts of a workflow contribute to its performance.

That gives the course a useful progression. You see how workflows are put together, then how to examine and improve what you’ve built.

Start with the work you need done

I liked the way the course connects workflow design to how a person would approach a task.

Before choosing tools or deciding how many agents you need, you can ask some straightforward questions. What work needs to happen? What information does each step require? Where would someone check the result before passing it along?

Those questions help turn a broad request into something you can build. They also make it easier to see when a single step contains several different responsibilities.

This is an accessible way to introduce the design patterns. Each pattern has a purpose within the work being done, which gives readers a way to reason about when it might be useful. The course connects the terminology to decisions an engineer will need to make.

Evaluation gets the attention it deserves

The strongest part of the course for me was the emphasis on evaluation and error analysis.

It’s easy to spend time changing prompts or trying different models. Knowing which change is worth making takes more investigation. If the final answer is poor, you need to understand whether the workflow gathered the wrong information, mishandled it, or failed somewhere else.

The course spends time on that investigation. It walks through looking at outputs, inspecting intermediate steps, and identifying errors that occur often enough to deserve attention. Evaluation then gives you a way to track whether your changes address those problems.

I appreciated how approachable it makes the starting point. You can begin with a small set of examples and a specific failure you want to measure. As you see more of the system’s behavior, you can expand the evaluation and refine what it checks.

That matters because evaluation can otherwise become something a team plans to add later. The course gives engineers a way to make it part of the work from the beginning, without treating the first version as a major project of its own.

Figure out where to spend your time

The course also connects evaluation to a familiar engineering problem: deciding where effort will have the most impact.

A workflow can contain several model calls, external tools, and handoffs between steps. If you only look at the final result, you may know that something needs improvement without knowing where to start.

Looking at the individual components makes that decision more concrete. You can examine which step introduces errors, which takes the most time, and which contributes most to the cost. That gives you a reason to focus on one part of the system before changing several things at once.

I liked that this thinking carries into the discussion of latency and cost. Those considerations belong alongside output quality, and the course shows how examining the workflow can help you understand the tradeoffs.

For someone beginning to build agentic systems, this is a useful habit to establish early. As the system grows, there will be more things you could change. You need a basis for choosing among them.

Who I’d Recommend It To

Software engineers starting to build agentic workflows are the clearest audience. If you’re comfortable building applications and have begun experimenting with LLMs, the course gives you an organized introduction to the main patterns and how they fit together.

Engineers with an early prototype may get particular value from the evaluation material. Once you have something running, the question becomes how to make it work consistently across more inputs. The course provides a practical starting point for investigating failures and tracking improvements.

Hands-on technical leads helping a team get started could also use it as a shared foundation. A team needs common language for discussing how work is divided, what tools are available, and how results will be assessed. Going through the same material can give those conversations a clearer starting point.

If you already build and evaluate agentic systems regularly, much of the material will be familiar. I’d view it as an organized review of the fundamentals, with the development process being the part I’d pay closest attention to.

The people I’d most readily point toward this course are engineers who have started experimenting and want more structure around their next project. It gives them a way to think through what they’re building, examine how it behaves, and decide what to improve next.

Let's talk.

Thirty minutes for whatever's on your mind: a technical decision, a team question, something you're building.

Book an intro call or email matt@backslashstudio.com