Next up is a topic that I love and it is one of the latest buzzwords in AI context engineering.
I think the term was coined by a few people, but definitely made famous by a Google engineer called
Phil Schmidt.
That will look at his post in a second.
And it really comes down to this observation that, look llms are constrained.
They have an input in the form of a set of tokens.
They're predicting what would most likely come next.
And that input set of tokens has to sit within something called the context window.
The maximum number of tokens that it can squeeze in and still pay attention across all of this input.
And that input needs to include everything like the conversation so far, the chat history, descriptions
of any tools that need to be called, any tools that have been called, and the results of them being
called as part of this particular conversation, along with with any rag that you've done, anything
you've shoved in the system prompt and the system prompt itself.
All of that stuff, it all has to go in this context window.
And so that is a constraint.
And also it's not like it's not like you want to use up all of the context window, because the more
you shove in there, the more you're at risk of losing what people call coherence of the model, which
is basically saying how reliable is it at generating outputs consistent with your goals?
The more you confuse it by putting lots of stuff in there, the less likely you are to get reliable
outcomes.
And so adding in tools, which feels like I'm equipping my model with more and more abilities to do
different things, this has to be a good thing, but no, giving it more choice can lead to less predictable
outcomes and can reduce reduce accuracy.
And so the term context engineering came about to represent the art and science of getting it right,
picking the right input tokens, the right information to pack into the space.
You've got to give your model the greatest chance of getting the right answer.
Picking the right tool, giving the right the right reasoning, or giving the right kind of background
information from your rag.
Getting it right by.
By putting the best possible cut of information in your inputs.
And that that is what context engineering is all about.
And here is the seminal blog post from Phil Schmidt, the Google engineer from Google DeepMind, who
really was one of the first to expand on this idea of context engineering and express it.
And he did so visually with that Venn diagram there that shows all the kinds of things that you pack
in to the context, to the to the input tokens, and includes what people like to call short term memory,
which is just referring to the conversation history, the stuff we've been putting into the memory in
with longer term memory, which is really what people use to describe all of the other databases that
you might have that are allowing your your LM to have some persistent knowledge of, of its interactions
or of the information that it needs.
The system prompt, which typically contains your rag available tools, structured output.
You see, I'm thrilled to see that Phil included that my favorite piece in his diagram, and he cunningly
showed it as overlapping with available tools, probably to recognize that most of the time structured
output is in fact implemented behind the scenes, just as another tool.
It's just the way it works.
But as far as we're concerned, it is the output.
And uh, and the, the user prompt as well, of course, most importantly is the input that's used that
the LM is actually responding to.
So figuring out the right decisions and trade offs to get this most efficiently packed into your context
window.
That's what it's all about.
And you should read this blog post because it's terrific.
And if you Google context engineering, this is probably the first thing that comes up.
But there's lots of other good material on it.
And I'll put a link to Phil Schmidt's post in the course resources.
Now you're probably thinking, okay, so what's the process that I should follow in order to get the
best context?
Engineering?
What is what is the waterfall that you take to get the context to be optimized?
And of course, the answer is it's not like there is a fixed process like an A, B, C, d.
This is a classic example with LMS of where what you need to do is experiment.
This is about R&D context.
Engineering is trial and error R&D and the North Star.
The way that you do it is by having an evaluation.
You need to have a metric, something which allows you to measure how effective is your agent system
towards your ultimate commercial objective.
And once you've got that metric, which we'll be talking about a bit later, once you've got that evaluation
metric, you can then use that to test different approaches for your context test using Rag in a different
way.
Test different combinations of tools to figure out what does best.
Maybe try tools versus structured outputs to see which one performs better.
And so start with a metric and then run lots of experiments.
There is no shortcut to experimentation.
That's how to do great context engineering.
All right.
And the other big topic for today.
Sub agents which we've already met a bit.
So a few things that sub agents are all about.
It's all about dividing your bigger agentic problem into small steps that you can test independently.
That a sub agent, another AI agent, can manage itself and be responsible for.
It's about being able to reuse the same AI agent as part of multiple larger agentic flows.
If you've got one task, perhaps it might be, say, finding prospects.
If that task is something that you might want to be able to reuse, maybe behind an MCP server, maybe
in another project, maybe and another a couple of projects.
Then building that out as a subagent that carries out its task, is tested and evaluated, meets the
criteria, then that is great for reusing it in different agentic flows.
That's another good reason to use a subagent.
And of course, super important context engineering.
If you've got like 12 different tools that you're equipping with your same model, it might get to a
point where it's starting to lose coherence.
It's not able to track all these different bits of functionality.
You might find that there's a sensible group of them, that one particular task only needs that group
of tools, and no other task needs that group of tools.
That sounds like that's going to be a great thing to experiment with.
Try breaking that off.
Have that be a separate subagent that is then offered up as a single tool to the bigger agent, and
now you've just optimized your context.
The context window for the Subagent is very efficient, and you've reduced the window.
The amount of tokens you need for the the overall agent as well.
So that can be a great trade to make.
And now Nan gives us a particularly easy way to implement Subagents.
They can be implemented using these things called sub workflows, which we've actually already seen
because I did that yesterday.
Uh, when we built out the prospecting Subagent, I called it a sub agent rather sneakily without even
defining a sub agent.
We called it a prospecting subagent.
That's what we created.
And I set it up as a workflow.
And I had it.
I added the trigger.
I had it be something that was triggered by a different workflow.
So it effectively was a sub workflow because it could be called by another workflow.
And doing it that way is a very nice, easy, simple way to say all of this workflow is itself a sub
agent.
And so Nan makes it very simple for us.
So it's easy to build up these workflows, test them, give them a limited number of tools that make
sense for the task at hand.
Have it be something that we can evaluate, have it be something we can test, we can sign it off,
we can publish it to production.
And then that is something we can use from a different agent, which will have a more efficient use
of its context, because we farmed everything out to the subagent.
It makes total sense.
And I should mention you don't need to have a sub workflow to have a sub agent.
A sub agent can be as simple as, hey, you're in an you're in a workflow.
You put down one AI agent, the output you put into another AI agent, that output you put into a third
AI agent, and then you just got like three AI agents in a row and you can say, these are each three
sub agents that are working together on a bigger task.
So, you know, you can you can organize agents in many different ways.
A sub agent is just really the name of saying you've got a smaller part of your bigger agentic problem,
and that is itself an AI agent, which which, you know, it seems very reasonable thing to do.
It's just that it's quite nice and elegant to use a sub workflow as your sub subagent, but it's not
required.
Okay, so those are the good ways to use subagents or the good reasons to use them.
A few things to watch out for.
First of all, beware of the thing that I called the human trap, which I mentioned all the way back
in week one, week one, day two.
I do believe, and that is when you see people that are anthropomorphizing, they are coming up with
agents with human like roles because it just sort of sounds good.
It feels right.
We should have these different agents that have a junior this and a senior this and do this and this
and this, because that's how our org is structured.
And that's why they choose the agents to have those responsibilities, human like responsibilities.
It might turn out that that is a good way to do it in order to divide your problem into smaller steps.
Maybe there was a good reason why humans were put into those roles, but but still, it shouldn't be
first and foremost why you do it.
You should divide into subagents because it gives you independently testable steps because it improves
your evals, because it fixes a particular problem.
Not not just because it sounds like those are responsibilities that should make sense.
So the other thing to be aware of with Subagents is that it it constrains the way that your agency platform
runs.
You are putting some some constructs around what has to happen.
This this overall agent is going to only be able to call these fixed subagents.
And in doing so, you are reducing some of the flexibility that you are giving your LLM.
It's not able to decide, you know what, I'm going to do things a bit differently.
I'm going to call this tool.
And then the other one over here and then this one.
But rather you're packaging your tools into fixed subagents.
So whilst you're giving this the benefit of the smaller, independently testable steps, you are removing
some of the flexibility that is the trade off that you are making, and you just have to be cognizant
of that trade off.
And Typically when you do it this way with Subagents, you do have more to build.
It's like you've got to build each of these subagents, you've got to test them all independently.
So it's more work.
Building with Subagencies is harder than just simply setting up one main AI agent, equipping it with
a ton of tools and say, hey, this is your goal.
Go do what agents do.
Go run these tools in a loop with a goal.
Make it happen that is easy to code and wonderful when it works.
So building subagents is harder work and takes longer, but of course it's easier to test it because
you've got this much, much more sort of constrained, independently testable steps.
And it's typically it is, as a result, more bulletproof, more predictable because you've got it on
rails.
It's worth pointing out this trade off between being more flexible, more autonomous, and being more
bulletproof and reliable.
That's something I just mentioned a few minutes ago as well, in the context of structured outputs versus
tools.
So you'll see this sort of familiar pattern that we're coming back to that again with Subagents.
And in fact, many of the decisions that you make with context engineering come down to this, this
trade off between autonomy, flexibility and reliability.
And I'll tell you that when I see real systems implemented in production, they tend to lean heavily
towards this more bulletproof approach.
Structured outputs subagents divide your problem into smaller, testable units.
That's how Agentic AI is being deployed to production today.
The only exception is the more high tech tools like Claude Code, where you're more willing to just
give a bunch of tools to a model and let it go at it.
And you have some tolerance for failure because you need to see the innovation.
So understanding these trade offs and keeping them front of mind that that is really that is what it
takes to move from being someone who's got some experience in this field to being a pro.