So much as we started week two.
We're now going to go through the core concepts of crew I, the sort of building blocks to understand
how it works, and there's some similarities.
First of all, there is an agent.
An agent is basically the smallest the unit of work, an autonomous unit, which is related to an LM.
It has an LM underneath it, and it has something called a role, a description of what it does, a
goal and a backstory.
And it can also have memory and it can have tools.
And that is how an agent is defined.
And you can remember back to OpenAI agents SDK definition.
There is something new here.
A task is another thing.
And there wasn't an analog in the last framework.
A task is a specific assignment that is going to be carried out.
It has a description, it has an expected output, and it has an agent.
So a task is assigned to an agent.
So that is the distinction agents.
And then tasks.
And there can be multiple tasks for an agent, and then a crew is a team of agents and tasks, and that
is simply so.
A crew is the aggregate of the of the other two, and a crew can be can be has two different process
modes.
One of them is called sequential, and that is where it will simply execute each task in turn as it's
laid out.
And the other is called hierarchical.
And that is where an LM will be used a manager LM in order to assign tasks to agents.
So those are the two different modes that you can operate in.
So that gives you these are the three core concepts to keep in mind.
So how do we think about this.
So so it's it's this these are lightweight concepts.
And they're certainly reminiscent of last week I would say that it is a bit more opinionated than the
OpenAI agents SDK.
There's a bit more terminology.
It's a bit more prescriptive.
So as a clear example, if you look at the agent there, if you remember last week, agents just had
instruction.
An instruction was basically the system prompt.
And you provided the instruction.
And that's very unopinionated.
You can choose to think about instructions however you want.
Now with crew, an agent has a role, a goal, and a back story.
So it's a bit more you can see immediately.
It's more prescriptive in terms of how one is supposed to to prime the this, this, this LM, and how
that is constituted into a system prompt is something that's, that's not immediately available.
There are, in fact, ways that you can choose to set that you can sort of put in templates, but that's
somewhat hidden from you at the, at the certainly at the beginner level, if you just use it out of
the box, you have to provide the role, the goal, the backstory.
And I think this is a really good example of the trade offs between these different frameworks, because
obviously forcing us to think in terms of a role and a goal and a backstory is good, because these
are all sort of good prompting practices to think about the context, to give the backstory this this
is a a good, best practice at the same time.
So so that's the benefit.
The trade off is that we might not we might have a specific situation where we don't want to give a
backstory that's not relevant.
We want to think about it differently.
And that is completely possible with AI.
But it's going to be harder.
We're going to have to then dig in and find out what's going on.
And also if we're trying to debug a problem and we're not sure what's what's happening, we don't we
don't have the same control over the system prompt.
We just know that it's being constituted based on these various building blocks.
So hopefully I give you this color because I want you to have a good sense of what are the trade offs
in adopting these different platforms.
And and that's a pretty important one.
So a nice feature of crew is that you can do a lot of the definition of things like agents and tasks
using configuration, which allows you to sort of nicely separate some of the text rather than having
it embedded all over your code.
So when you think about agents and tasks, those those are the two things that make up a crew.
Agents and tasks can be created by code.
You can say agent equals my agent, my agent equals agent.
Open brackets and then pass in a lot of things like the LLM to use and the role and the backstory and
so on.
Or instead of that, you can write a YAML file that looks a bit like this.
We'll look at many of them in the course of this week, but it's a YAML file.
If you're not familiar with YAML, it's a very simple, easy for humans to read kind of markup file.
And it and it looks a bit like this.
And this is going to allow us to lay out a, a role, a goal, a backstory, and an LLM associated with
an agent called researcher in this example.
And that will allow us to separate out the configuration from the code.
And whilst that is in some ways, as always there's some pros and cons.
The, the con is that it's a bit of something to get used to.
It's some scaffolding, it's specific to crew.
There's definitely a great benefit that this means that you don't have your your various prompts buried
within your code all over the place.
You've got it nicely separated out and you can work on that somewhat independently.
So.
So I think it's a nice a nice touch in your code.
You can then create something like an agent and instead of specifying all of the fields of an agent.
Like the role of gold backstory.
You can just simply select the configuration as as it shows in this code right here, and they will
all be populated for you.
So it's I like it because it's lightweight.
It's not like there's magic happening behind the scenes.
You clearly refer to the config right there.
It's clear what's going on.
And it has this nice separation of concerns, allowing us to work on our prompts separately from our
code.
And then in addition to the YAML files, there are a couple of Python files.
And the most important one is called crew.py.
And it's where everything comes together.
It defines your crew and it's going to look a bit like this.
And we're going to of course go and look at a proper example in a second, but it has some decorators
over it and you're now you've got a bit of experience with decorators from, from last week.
And uh, sure enough, crew has decorators as well.
And you can see that they there is a few of them.
It has crew base as the decorator you put around the whole class that's going to manage your crew.
And then there's a decorator agent for each of your functions which creates an agent, and there's a
decorator task for each of your functions which creates a task.
And then there's decorator crew for your final function that generates your crew.
And you can see that it creates an instance of crew and it returns and it passes in the agents, the
tasks.
And this thing that's telling it that it is sequential, not hierarchical.
It's where you set that important different mode of processing.
And you can see that there.
It says agents is self dot agents.
And you might wonder where is that coming from.
Well that's really one of the roles of this decorator at agent that that is making sure that any function
that has that decorator automatically, the agent that comes from that will be associated with the instance
variable agents will be added to that list.
So that's why you can just simply refer to it at the bottom.
So anyway, this this will be more concrete when we look at a proper coding example.
My main point is that there is this very important module crew, and it's where you define your agents,
tasks and crew, and it uses decorators.