There you have it.
Those are the five tricks that allow us to take calls to LMS with inputs and the way we interpret the
outputs.
Do it in such a way that gives this impression that we have something out there carrying out tasks autonomously
for us.
And don't worry if you if you didn't get all of this because we're going to be doing this again and
again and again, and by the end of it it's all going to connect wonderfully, but hopefully this giving
you some intuition for it.
So what about the trap?
I told you there were five tricks and a trap.
So this trap is something that I find personally galling, and it happens all the time.
And so I wanted to to warn you about it and get your take on it.
And I'm calling it the human trap.
The proper word people use for this is anthropomorphizing.
It's the problem of when people approach a genetic AI, treating llms as if they're humans, as if they
have roles and responsibilities.
And let me tell you more about what I mean.
It's so common when I hear business people have have an objective they want to automate a business process,
something we'll be doing a lot on this course.
And the first their go to thought for business people and for technology people too, for engineers
that should know better, uh, is to say, okay, let's create an agent architecture, an agent architecture,
which is a diagram with different agents with lines between them.
And I'm going to assign roles and responsibilities to these agents just by sort of analogy with the
way humans go about doing this as if they are people.
I'm going to have agents that represent different jobs, and I'm guilty of doing this myself.
I do this in some of my, my, my courses teaching a genetic engineering, and we build things like
a trading floor and we have traders and researchers.
It's so natural to go towards that.
And when you're doing like, like toy projects and demos, it's fine.
You can do that because it's great fun to see it in progress, but it's not a disciplined way to do
it.
And it has lots of lots of problems.
So what are the problems?
Well, the big problem is that you have to keep in mind that what llms are good at doing is generating
realistic content.
That's what they're trained to do, generating stuff that seems compelling.
And so if you give it a job, you say you are an evaluation agent.
Your job is to evaluate what came before.
You should give it marks out of ten.
Then it will do that because that's what it's meant to do.
And it will come up with a reason, because you've told it to give a reason.
It doesn't mean that it's doing it well.
It doesn't mean that this evaluation is aligned with your objectives.
It just means it's going to follow the script.
It's going to do what it's told to do in the prompt.
So the danger, the risk of this is that you can fool yourself into thinking you have this, this,
this whole sort of cadre, this whole group of different agents all doing their thing, all generating
very reasonable, very realistic content.
But it might all be llms slop.
It might be nonsense that apparently is doing something.
They're all they're all collaborating together.
They're all assuming their roles, but they're not actually solving your task in an accurate way.
So it's all very well, me complaining, but what am I suggesting is the the answer?
Well, the right way to do it.
When you divide up your problem into different agents, you should do it because it solves your problem
better, not because it sounds like those are the roles you would have, but because you've tried it
and that's an improvement.
You've got some chunky problem.
It makes sense to divide it into some steps.
You try it and you get better outcomes and then you stick with it.
That's the way to do it.
Uh, scientifically, with experiments and most importantly with this, the magical word is that word
in that last bullet there.
Evaluate.
You need to have a way to measure your outcomes, and you should divide things into smaller steps or
organize your agents differently because you get better evaluations, because it results in superior
performance.
That's the right way to do it, not just because it sounds like that's the right kind of responsibility.
Now, often it's a good starting point to start by analogy with with some human organization.
If we divided up roles and responsibilities for for humans, we probably had some, some reason for
that.
Maybe it's a decent starting point, but you should treat it as your starting point and always start
as simple as possible.
Start with just one role, divide up and start assigning more responsibilities.
Experiment with that because it's going to help you get better outcomes and then measure it.
That's the right way to do it.
That's how to avoid the trap.
And that's a wrap on the theory around Agentic AI.
I hope this has given you some good intuition as we dive into building agentic workflows and also some
some real, real world kind of lessons learned from actually building Agentic AI in anger.
And now it's time for us to go back to N810, starting with the navigation.
The big picture building blocks of N810.