DeepLearning.AI Agentic AI Course in 29 Minutes

I took Andrew Ning's agentic AI course

for you. So, here's the cliffnotes

version to save you the eight hours.

I've been really looking forward to this

one, but it is not enough for you just

listen to me talk about stuff. So, at

the end of this video, I have included a

little assessment because research shows

that immediately reviewing information

after you learn it is the best way to

retain that information. Now, without

further ado, let's go. A portion of this

video is sponsored by HubSpot Media.

Let's first go over the structure of the

course. The Agentic AI course has five

modules. Module one, introduction to

Agentic Workflows, covers the

foundations of Agentic AI and is what

the rest of the course is built on top

of. Module two is a deep dive into the

reflection pattern, a common pattern for

agentic workflows. Module three covers

tool use, another common agentic

pattern. The course also covers lots of

examples and ways to improve the

results. Module four is called practical

tips for building agentic AI. And this

module is by far the most important

module. I have not seen this information

especially on evaluations being covered

to this depth anywhere else. It's what

everybody talks about but nobody has

actually really covered it well and this

course does it well. And finally module

five is patterns for highly autonomous

agents where Andrew covers more

experimental agentic workflows a taste

for the future.

All right let's jump into module one the

fundamentals starting off by defining

agentic AI. An agentic AI workflow is

defined as a process where an LLM based

app executes multiple steps to complete

a task. For example, if you want your

agentic AI workflow to help you write an

essay on tea ceremonies.

First, the LM will need to come up with

an essay outline about tea ceremonies.

Then, it will need to think to itself,

do I need any web research? It decides

that it does, and it will then do

research on tea ceremonies across

different locations and across different

times. Next, it would then write a first

draft, but that's not good enough. It

would then consider what parts would

need more revision and more research.

Maybe it would even request a human

review at this point if it's really

quite unsure about tea ceremonies. Then

finally, it would revise the draft and

have the final draft ready. This is an

example of an angentic AI workflow that

is less autonomous since it's quite

clear what the steps are to be taken in

order to get the final result, but you

can also have more autonomous agents,

too.

Using the same essay writing agentic

workflow and a more autonomous workflow

would look something like you similarly

tell the LM to you know write an essay

about tea ceremonies but instead of

directing it to go write an outline and

then do the web research and then etc

etc you can just give the LM a set of

tools like web search and news search

and maybe archive search for more

research papers too and you let the LM

itself decide which tool it's going to

use to gather the right information find

the best sources compile it together

then write it the essay draft. It will

also have the autonomy of how it's going

to reflect on how it is that you can

improve things, whether it wants to call

a human reviewer or not until the agent

itself feels satisfied and produces the

final result. It's the same input and

the output that you want is the same as

well. But you can see that one is very

linear and the steps are well very well

defined, less autonomous, and you have

the much more autonomous version where

the agent has access to tools and a lot

more freedom to decide how it's going to

get to that final essay.

There's of course pros and cons to being

less autonomous versus more autonomous.

Like if you're less autonomous, the

steps are predefined. They're clear and

most of all, you have a lot more control

over what is happening and the final

result. On the other hand, if something

is more autonomous, the agent gets to

make a lot more decisions for itself and

you can end up with really creative,

really great results that are beyond

what you imagined. But the downside is

that you would then have less control

and it could also potentially come up

with results that may not be what you're

looking for at all. In any case, with

agentic AI workflows, there is this

spectrum of autonomy that you, the

person building the agentic workflow,

gets to choose how autonomous you want

it to be. Very explicitly though, Andrew

in the course emphasizes that he rejects

this notion of like a binary something

is either an agent or it's not an agent,

which is pretty much like what the

people on X has been debating about for

like the past 2 years. What is actually

considered an agent? But Andrew is

basically like, no guys, no guys, still

just don't think about it that way,

okay? Let's just call things like

agentic AI and as long as it involves

multiple steps, it's agentic AI and you

can just be on the spectrum of least

autonomous to more autonomous.

Paraphrasing a little bit here. Anyways,

what we all can agree on though is if

you wrap a LM, a model in an agentic

workflow, it is going to be much better

than just calling it directly. This is a

fact. It would also be often times

faster and more modular, meaning that

you can change things a lot more easily.

So that is why agentic AI is so popular

and very much worth building.

Okay, let's now cover from a practical

perspective. What are the building

blocks of Agentic AI? Andrew's building

blocks for Agentic AI is pretty

simplistic actually. It involves just

three components. Let's start off by

addressing the first two which is models

and tools. Models just refers to the AI

model. That can be large language models

or it can be like other types of AI

models, multimodm models like video

generation models, audio generation

models, any type of model. And then

there are tools which are basically

functions and capabilities that you're

giving your AI agent so that it's able

to perform different types of task.

Examples of this would include being

able to use external software through

their APIs. Stuff like web search,

getting real-time data, being able to

check emails, things like that.

Information retrieval, so being able to

access certain types of databases, and

code execution, being able to write code

to be able to do things like math, data

analysis, building stuff. So all of

these are tools. There is also a third

component which I will talk about in a

little bit because when you are first

thinking about creating an agentic

system, you're really just thinking

about how do you take these building

blocks of different models and different

tools and chain them together and put

them together in such a way to achieve

the results that you want. For example,

say you want to develop an agentic AI

system with the goal to respond to a

customer email for your company. This is

an example of the type of email that you

may get. Subject line here is wrong item

ship. It's like, "Hi, I ordered a Blue

Kitchen Pro blender. Here's the order

number, but received a red toaster

instead. I need a blender for my

daughter's birthday party this weekend.

Can you help?" Susan Jones. If you want

to create an AI workflow that's able to

accomplish this task, the easiest way to

do this is actually think to yourself,

how would I go about accomplishing this

task? Like, how would a human do this?

Okay, so the first step would be you

need to extract key information,

including the order number, the fact

that it was supposed to be a Blue

Kitchen Pro blender, but they got a red

toaster instead, and the timeline. The

daughter's birthday party is for the

weekend. Then you would go and find the

relevant customer record, which would

likely include looking into an orders

database to see what was actually

recorded. You would then determine what

possibly could have went wrong and then

send a email reply back. Now, we need to

translate these three steps into what an

LM would do. Well, for the first one,

extracting key information, the LLM is

able to extract that information just by

itself. But for the next step, which is

finding a relevant customer record, the

LM would actually need a tool that would

allow it to look into the orders

database. So, it would need to provide

that with that tools for orders database

query. And then finally, for writing and

sending the response, the LM would be

able to draft the response, but in order

to actually send that email, it would

need to have access to another tool that

allows it to send the email. Make sense?

This is how the building blocks are

coming together here. You have the large

language models and the different tools

that it requires. Of course, the type of

large language model you want to use on

each of these steps could vary depending

on what it's supposed to be doing

exactly and how it is that you're

actually going to build this type of

tool also varies as well. But don't

worry too much about this. We're going

to go into a lot more detail later in

the video. But here what I want to just

make really clear is that you're

basically taking um a goal and then

translating that into a sequence of

steps in which you will then use the

building blocks of models and tools in

order to accomplish those steps. So the

ideal situation after your AI system

goes through these steps is that it

would come up with a wonderful email

that says something like, "Thank you so

much for emailing the company. After

looking at your order number, we did

notice that it does correspond to a blue

blender. And we apologize that you

received a red toaster instead. We will

send you a blender with expedited

shipping so that you can get it tomorrow

and make it for your daughter's birthday

on the weekend. And you can keep the red

toaster as well. Then the customer,

Susan Jones, will probably be very

happy. But what happens if your agent

doesn't give you this wonderful email

and instead write something like, "Oh,

thank you for shopping with us. As you

can see, we are so much better than

Rival Corp, our competitor, or something

like sure, we'll issue a refund and not

actually address the issue. That is why

you need the third component of Andrew's

framework, which is evaluations.

Evaluations, as his name suggests, is

all about evaluating the results of your

agent. It's like the other half of

building an AI agent. Not good enough to

just build an agent. You actually got to

make sure it works properly, right? And

I am so glad that this course covers so

much in depth about evals. I will be

covering this in a lot more detail in

module four, but very briefly, an

evaluation in this case is making sure

that your AI agent doesn't actually talk

about your competitors because that's

kind of like in poor taste. So, how do

we do this? Well, first we can compile a

list of all the competitors that we

don't want to be mentioned like comp

code and rival co or the other code.

Then you can actually write a small

snippet of code like this. If competitor

is in response, then the num competitor

mentions is plus or equal to one. What

this basically does is check for the

email responses and if any of these

competitors are mentioned in the

response then you would just increment

the counter of number of competitor

mentions to one more. Of course, ideally

you want this counter the number of

competitor mentions to be equal to zero.

But you know if it does show up you

would have a way now of tracking how

many times it shows up and where it is

showing up. This is a very objective way

to determine if these competitors are

actually still showing up. And you can

use this counter as a way to then tweak

your prompt, tweak your system, and do

stuff to it to try to lower this number

so that it eventually goes to zero.

Don't worry about it if any of the

detail seems a little bit hazy. I'll be

going into a lot more detail later in

the video. But what I just want you to

understand here is that see by having

like an evaluation like this where you

can measure the occurrence of this bad

behavior, you now have an objective way

to improve your system to decrease the

bad behavior. If you didn't have this

EBAL, this way of measuring the bad

behavior, then you can like kind of

think that you are improving your

system, but you don't actually

objectively know if you're improving the

system or not. That is why evaluations

are so important. This is an example of

a very objective codebased approach for

evaluating a result. There's another one

called LM as a judge in which you're

actually using another large language

model to rate the results and evaluate

the results of your AI agent. Anyways,

more detail in module 4. This course is

an excellent introduction to Agentic AI,

but when you're ready to start building

your own AI agents with business impact,

there are many other factors that you do

need to consider, which is why I highly

recommend that you check out the free

master AI agents resource from HubSpot

Media. It provides good practical

frameworks and examples on how to get

started with building useful AI agents

with business impact. It also includes

real use cases in marketing, sales, and

operations that you can directly use to

start implementing your own agents to be

able to do things like content

production optimization, process large

amounts of data, do customized outreach,

and much, much more. There's also a

second download and resource called how

to use AI agents that has an excellent

checklist to guide your organization

through each phase of implementing AI

agents. This is so useful and it's

something that we actually use in our

company whenever we're launching a new

agent. Really recommend you check out

the resource linked over here also in

description. Thank you so much Hopsoft

Media for providing practical free

resources on building AI agents and for

sponsoring this portion of the video.

Now back to the video. But first, let's

move on to modules two and three which

are covering what are known as agentic

design patterns. And what are agentic

design patterns you may ask? Well,

remember we talked about earlier about

sending that email for the blender and a

toaster. Got to first decompose that

task and then translate that into a

combination of large language model and

tool use. So you could just kind of like

figure that out yourself with any type

of task that you want your agentic AI to

do. But luckily, we do have a lot of

precedence now for specific types of

task and specific types of design

patterns like how it is that we're

decomposing it and fitting together the

pieces that has proven to shown really

good results because more likely than

not, whatever it is that you're trying

to accomplish will converge to one of

these design patterns. In this course,

Andrew covers four design patterns. two

that are less autonomous and two that

are more experimental, more autonomous.

Let's now talk about the first design

pattern, which is reflection. The

reflection design pattern is super

intuitive. For example, if you tell a

human, hey, go write this email, and

they're like, you know, distracted or

something and maybe they just like had

lunch, so they just write some sloppy

email. But if you go like, hey, reflect

on this and improve the email, probably

the result you're going to get is going

to be a lot better. Exactly the same

with AI. If you tell an AI to write an

email, it will first do a first draft,

which might not be that great. But if

you tell it to go back and reflect on it

and improve it, you will end up having

much better results. The second step,

asking to reflect on it and come up with

another draft, is literally the

reflection design pattern. Simple but

powerful. And remember how it is that

way you can actually go about tweaking

this and improving the systematically is

by having the whole like evaluation

section. The course also provides like

code examples of how to implement design

patterns like the reflection pattern,

which you can see over here, but I'm not

going to go into too much detail about

this. You can actually go and try out

the implementation with code if you want

to in the course. It's actually free to

get this code. So, I'll link it in the

description. By the way, don't be

discouraged and like rage quit right now

if you don't know how to code. Um, this

is absolutely doable with no code as

well. They just don't show it in the

course. Like, we teach the full no code

approach for doing this in our agents

boot camp ourselves. I also do have a

video over here that covers the basics

of how to implement um agents using no

code approach too.

Okay, let's go on to the second design

pattern called tool use. So, this part I

did get like a little confused because

we did talk about tools uh when we

talked about the building blocks, right,

of like models and tools and and

evaluations, but I think Andrew included

this as like a full-on design pattern

because he wanted to emphasize like how

much tool use can elevate the

performance of an agent. So, we'll go

through it. Firstly, to define tool use,

you're letting your agent have access to

tools that's able to implement and do

certain things that it normally cannot

do just as a model itself. For example,

if you have an agentic AI workflow in

which you want to be like booking

meetings and stuff, you would need to

give your agent access to a calendar

booking tool. What tool use? You can

make it like very strict telling your

agent that you have to use this exact

tool to do this exact thing or you can

make it more autonomous and give your

agents more like a selection of tools

that it can choose from and they can get

to choose which tool it wants to use to

accomplish a task. But whatever tools it

is that you choose to give your AI agent

and how much you restrict how it's using

the tools. The key here is that you do

need to define the tools and you need to

let your agent know that you gave them

access to these tools and what the tools

are in the system itself. Or else your

agent would just be like what is this? I

don't know what this is. Like for

example, if you have a personal

assistant agentic AI system and you tell

it to find a free slot on Thursday in my

calendar and make an appointment with

Alice, you would need to give it tools

such as make appointment, check calendar

and delete appointment and tell it in

the system prompt you have access to the

tools make appointment which is for

making an appointment booking. Check

calendar which is for checking a

calendar to check for availabilities.

Delete appointment in order to delete

existing appointments. then you can tell

your agent to like you know find that

time slot between you and Alice and it

should be able to use the tools at his

disposal in order to accomplish the

task.

So how it is that you can actually

define these tools for your agents.

There's actually quite a few different

ways of doing this. The most simple

approach if you're using code is to

literally just like write a function for

it and then give it access to your AI

agent through some type of framework. Um

the example that they showed in the

course is called the AI suite, but

there's like a lot of other frameworks

that you can use as well. Not going to

go into too much detail about this, but

if you are interested in implementing

this, there is an assignment in the

course as well, which I will link in the

description. So yeah, keep that in mind.

Angie also explains that there's other

ways for you to give your agent tools as

well. For example, through something

called MCP, which is the model context

protocol. This is a protocol that was

developed by Anthropic that standardizes

the way that tools are being defined so

that it's very easy for agents to have

access to different tools without having

to like write custom functions for all

of them. MCPS are actually really cool.

A lot of developers are actually

building MCPs and like selling their

MCPs and stuff like that as well. So, if

you are interested in learning more

about it, I do have a full video which

I'll link over here that goes into the

depths of MCP. But for now, let's move

on to the much anticipated module 4,

practical tips for building agentic AI,

where we talk a lot now about

evaluations, the missing piece of

agentic AI development and what makes

this course so valuable. To properly

define it, evaluations or evals are

agent evaluation mechanisms that refer

to processes and criteria used to assess

the performance of agents within a

system. We already talked about why we

need evals and why it is the third major

building block because you can build an

AI agent, but how do you even know how

good it is and how do you know how to

improve it if you don't measure the

results of it? And that is where eval

come in. For example, say you have an

invoice extraction agent. So you give

the system PDF invoices which then it

converts to text. Then the LM extracts

four required fields like the biller,

biller address, amount, due, and due

date. It has access to a tool called

update database which will then use in

order to update the database with a new

invoice and the record is created.

Simple linear agentic workflow here.

Now, if we want to evaluate this agentic

system, one approach of doing this is to

just now take 10 to 20 different

invoices and then feed it through the

agent and then make a record of the

results. You might notice that invoice

one was fine. um it was able to extract

the four required fields and everything

is great but you found that invoice 2 it

actually mixed up the dates between the

due date and the invoice date. Uh

invoice 3 was okay as well and then you

keep on going and you find that invoice

19 it also makes up the dates and

invoice 20 it makes up the dates as

well. This is actually the most

practical way of doing this. So from

collecting this data you notice that one

of the tendencies of this agentic

workflow is that it mixes up dates which

is not good. We actually want to improve

that. So we want to build an eval for

this to set as a metric for us to

improve. One thing to note here is that

often times you don't actually know what

eval that you should be building before

you actually build out your system and

start running examples through it. It's

actually kind of hard to think through

like what are the potential like places

of failure for your system until you try

it out. So that's why I do like general

recommendation is just like build

something quickly, quick and dirty and

then just like start passing through

different examples and collecting that

data to decide what the eval should be.

Say we want to create an eval now for

date extraction because we notice that

it gets a date extraction wrong a lot.

How do we go about doing this? Well,

step number one is to manually extract

the due dates from the 10 to 20 invoices

that you pass through. Then you want to

specify the output format of the data in

the prompt itself. So then you can

extract the date from the LM response

using code and finally compare the large

language model results to the ground

truth. Does the extracted data equal to

the actual data? This is an example of

evaluation that uses code if you

actually want to implement evaluation

using code yourself. By the way, also in

the course there is the code for this

that you can run yourself.

Anyways, this is an example of a ebal

that you can implement so that in the

future as you're like tweaking your

prompt and then changing things around,

you can actually measure if your invoice

agent system is becoming more accurate

or less accurate at date extraction.

Hopefully more accurate. There are a lot

of other types of doing it. And the way

that the course frames it is that you

can think about evals as falling under

two different axes. This date extraction

eval is an example of an objective eval

because the result of it is that the

extracted date is either equal to the

actual date or it's not equal to the

actual date. Very objective either right

or wrong. With this type of eval system,

you can usually implement it pretty

easily just through code itself. Another

type of eval is a subjective eval. This

is when the result isn't just like a yes

or no binary kind of situation. An

example of a subject eval is if you're

trying to say assess the results of a

research agent. The agent is supposed to

research on a certain topic and then

output like some sort of essay at the

end. Say if you give it a prompt like

research and write an essay about recent

black hole science. There's no way to

objectively evaluate how good the

research and how good the essay ends up.

You can't just like, you know, count the

number of words or something like that,

right? So, what you need to do to create

this kind of email is first choose a few

different topics that you're going to be

using as the prompt. Like maybe

something about buck coal, something

about robot harvesting, renting versus

buying a home in Seattle, etc., etc. So,

for each of these prompts, you need to

actually manually establish a ground

truth annotation, which are like golden

standard talking points that you know

needs to be researched and needs to be

part of the final essay as well. For

example, with black holes, these could

be stuff like event horizon or radio

telescope. for robotic harvesting. It

could be like robo pick and pinchers. To

actually do this, you probably need to

like find someone who actually knows

these topics or you yourself know these

topics as well. So, this part is manual.

But then the second part is when you can

use the LM as a judge. So, you have

another type of LM to count how many of

these topics actually appear in the

research and the final results. The

reason why you need to use an LLM to to

count this and not just like um

objectively use code to count this is

because a certain term can appear in a

lot of different iterations. Like the

term event horizon could be like event

horizon, but it could also be like

uppercase, lower case, could be the

horizon on the type of event at the

horizon or like when the horizon is near

something like that, right? There's like

so many different types of iterations of

this that you need an LLM to be able to

capture all the different types of these

iterations. Then you can get the LM to

give you a final score for each prompt

based upon how many of these terms were

captured in the final result. This on

screen now is an example of a prompt for

the LM as a judge. That's the first axis

of this 2x2 matrix uh for the different

types of evals. And this one is

objective versus subjective. The second

axis is whether something has a perample

ground truth or does not have a perample

ground truth. Both the examples that we

just talked about, the invoice example

and the LM research and essay writing

example are agenting systems that have a

perample ground truth. This means that

for every example like every input that

we give there is a established ground

truth for that example. like the invoice

extraction has a specific date that is

the correct result that is different for

all the different examples and the

topics for the research agent are

different for each of the examples too.

However, you can also have emails that

have no perample ground truth meaning

that there's a singular universal

standard that is there for every single

example. Say if you have an agentic

system that is for marketing copy length

um and you just want to make sure that

the marketing copy length is always

going to be less than 10 words. So like

the number 10 is like the universal

magical number. This is also an

objective eval. So you can actually

write code. So you can literally just

write if the length of the text is less

than or equal to 10, then that is good.

If it's not, then it's bad. The final

quadrant of this 2x2 matrix is when you

have something that is subjective and

does not have a per example ground

truth. Say you have an agentic system

that is supposed to create different

graphs. The judging of the graph is

going to be subjective. The result of

the graph is going to be subjective. And

the way that you judge it is going to be

based off this universal criteria where

you would ask the LM as a judge to grade

the graph to see whether it has axis

labels. Are the colors easy to see? Is

there any overlapping text? Etc., etc.,

etc. So, that would be like a universal

grading criteria.

Okay, great. That covers the four

general types of of evals that you can

make. Some of the tips that the course

suggests when you're creating these

evals, uh firstly is to just quick and

dirty is okay to start. just create

something and then just create some

evals and just get started like that.

You you can always continue to expand

the set of evals. You want to try to use

a lot of different types of examples to

try to capture all the different types

of errors that you can change into

evals. And finally, you want to look for

places where the performance of the

agentic system is worse than a humans.

These are the best areas for

improvement. Great. That was the module

on evals. Even if you implement just

like a few of these different evals,

you'll be setting up a system that will

help you dramatically improve the

results of your agents. I feel like

evals are such an open secret and by

implementing them, massive return on

investment.

All right, we're almost done. We are at

module five, which is the patterns for

highly autonomous agents. We're going to

be covering two of the more experimental

agents that are also more autonomous.

The two patterns that we covered

earlier, reflection and tool use, are

less autonomous and they're more

predictable. While for these

experimental ones, planning and multi-

aent systems, these are less

predictable, less controllable, but if

you get it right, the results can be

really, really good. Let's start off

with planning and jump straight to an

example. Say you have a customer service

agent in which it has an inventory

database of different types of products

in a store. You have like ID, name,

description, price, and stock. An

example of a customer query that the

agent would receive would be like, do

you have any round sunglasses in stock

that are under $100? So you see this is

actually a pretty difficult query

because it involves the customer survey

agent to have to go through the data set

and first like find what are the round

styles. Then they has to go pick out

which of these are in stock and finally

which of these prices are going to be

under $100 to be able to come up with

the final answer of yes we have our

classic sunglasses which are classic

round metal frame and cost $60. And of

course this is just a single example of

the kind of questions that customers

will be asking. There's a broad range of

questions that will be asked and that

can be answered by using this database.

However, there is no like set path for

you to actually answer these questions.

Each time you would have to figure out

and plan out what is the way to actually

answer these questions. This is where

the planning design pattern comes in.

Going back to that example of asking a

question, do you have any round

sunglasses in stock that are under $100?

The planning design pattern will first

have an LLM figure out what is the

actual plan to answer this question

given the set of tools that it has. Like

it has tools like get item descriptions,

check inventory, process item return etc

etc. So it would use this information

and the information of the database and

come up with a plan like number one have

to use get item description tool to find

the round sunglasses. Second step is to

use check inventory to see if results

are in stock. Then third step is to use

get item price to see if in stock

results are less than $100. Then the

agent will take that plan and execute

each of these steps to get the final

result. By the way, if you want to dig

into this and actually implement these

evals yourself, there is again

assignments that you can try out in the

course which I will link below. What is

cool about this planning design pattern

is that the plan is not predetermined.

So the agenda system has to actually

figure out the plan first and then go

and execute all of it. Which means of

course that the downside of this

planning design pattern is that you

don't actually know what the plan is. So

it's actually very hard to troubleshoot

and anticipate what kind of result

you're going to get until it actually

goes through the process itself. The

upside of this is this increased amount

of flexibility and sometimes like it is

pretty magical to witness an agent be

able to plan out super complex tasks and

then execute it and get like crazy good

results. This is the kind of magic that

more autonomous systems have. Less

control but more probability of really

cool results.

The other more experimental autonomous

design pattern is a multi-agentic

workflow. The idea of a multi- aent

system is to take an agentic system and

actually have it like be multiple

different agents working together to

produce the final result. The intuition

for why this can be better is kind of

like a company, right? If you have like

one person trying to do all the

different tasks in a company, um it's

probably not going to do the best job

and it's going to get overwhelmed

because it has to do like so many

different things and juggle so many

different things at the same time. But

if you have different people in that

company that specialize in different

things, each person would be able to

focus better on their specific task. and

when you put it together, it's going to

produce a better result. That's why we

usually have multiple people in a

company and not just like the CEO trying

to do everything themselves. So that's

the same intuition for developing

multi-agentic systems. For example, say

you have a marketing team agentic system

and instead of just having one agent,

you actually divide that into three

different sub aents. A researcher, a

graphic designer, and a writer. So that

when you receive a query like create a

summer marketing campaign for

sunglasses, your research agent will

focus on conducting research and figure

out that here are current sunglasses

trends and competitor offerings. It

would pass along that information to a

graphic designer agent which would then

come up with like five different data

visualizations and five different

artwork options for the report. It would

then pass all of this to the final

writer agent which will then compile

everything together and write the final

report. So this would be a marketing

team agentic system that's able to

generate report for a marketing campaign

on a specific topic. There's actually

quite a lot of research done on multi-

aent systems and in our boot camp as

well like we have a whole week that

covers multi- aent systems because the

results can be really really good like

much much better uh than if you just use

a single agent. This course doesn't

cover too much into it though but I will

leave a link in the description for an

anthropic article that goes into a lot

more detail about multi-agent systems. I

also have a video that covers multi-

aent systems as well which you can check

out at this link over here if you prefer

like a video approach. Anyways, for this

course they also have codebased

assignments where you can implement

these more autonomous systems too. Oh my

god. Okay, we have come to the end of

this video of this crash course. I

literally had let's see 93 pages of

notes which I have condensed for you

guys here. I overall I think this course

really was quite good. It has a very

good overview of all of the different

parts um for building agentic AI. My

critique though, if I may, Andrew does

approach it from a very like researchy

theoretical perspective, which makes

sense given his background as like a

research scientist, but I do feel like

he didn't really cover like the actual

process of deployment and what does that

actually look like when you put it into

the world and get users to start using

your agents and stuff like that. That's

like a whole other beast which we cover

a lot in our boot camps because we're

coming from like a more practical

approach so that we're building these

agents and actually deploying them and

people are using them and you know

you're hopefully making money from them

as well. Another critique that I do have

um is that the assignments here they're

all like based upon code. If you didn't

know any better you would have the

misconception that you have to know how

to code in order to implement these

systems and that is not true. So I just

want to like make that super clear for

you guys too. You can do this with no

code as well. I'll link in description

some of the videos that I cover where

you can implement these systems with no

code completely.

All right, as promised, here is the

little assessment in which if you can

answer these questions, then

congratulations. You are going to be

able to retain all the information we've

just covered from this 8hour course.

Please write your answers in the

comments. All right, thank you so much

for watching until the end of this

video. I really hope that you learned a

lot about Agentic AI and you're super

excited to start building your own

agents as well. And I will see you guys

in next video or live stream.