has acquired critical consideration with the rise of LLMs able to dealing with advanced duties. Initially, most discussions on this speak revolved round immediate engineering: Tuning a single immediate for optimized efficiency on a single job. Nonetheless, as LLMs develop extra succesful, immediate engineering has become context engineering: Optimizing all information you feed into your LLM, for optimum efficiency on advanced duties.
On this article, I’ll dive deeper into agentic context engineering, which is about optimizing the context particularly for brokers. This differs from conventional context engineering in that brokers usually carry out sequences of duties for an extended time period. Since agentic context engineering is a big matter, I’ll dive deeper into the matters listed under on this article and write a follow-up article masking extra matters.
- Particular context engineering suggestions
- Shortening/summarizing the context
- Device utilization
Why care about agentic context engineering
Earlier than diving deeper into the specifics of context engineering, I’ll cowl why agentic context engineering is vital. I’ll cowl this in two elements:
- Why we use brokers
- Why brokers want context engineering
Why we use brokers
Initially, we use brokers as a result of they’re extra able to performing duties that static LLM calls. Brokers can obtain a question from a consumer, for instance:
Repair this user-reported bug {bug report}
This could not be possible inside a single LLM name, since you might want to perceive the bug higher (perhaps ask the one who reported the bug), you might want to perceive the place within the code the bug happens, and perhaps fetch a few of the error messages. That is the place brokers are available.
An agent can have a look at the bug, name a device asking the consumer a follow-up query, for instance: The place within the software does this bug happen? The agent can then discover that location within the codebase, run the code itself to learn error logs, and implement the repair. This all requires a collection of LLM calls and instruments calls earlier than fixing the difficulty.
Why brokers want context engineering
So we now know why we’d like brokers, however why do brokers want context engineering? The principle motive is that LLMs all the time carry out higher when their context comprises extra related info and fewer noise (irrelevant info). Moreover, brokers’ context rapidly provides up once they carry out a collection of device calls, for instance, fetching the error logs when a bug occurs. This creates context bloat, which is when the context of an LLM comprises lots of irrelevant info. We have to take away this noisy info from the LLMs context, and likewise guarantee all related info is current within the LLMs context.
Particular context engineering suggestions
Agentic context engineering builds on prime of conventional context engineering. I thus embody just a few vital factors to enhance your context.
- Few-shot studying
- Structured prompts
- Step-by-step reasoning
These are three generally used strategies inside context engineering that always enhance LLM efficiency.
Few-shot studying
Few-shot studying is a generally used strategy the place you embody examples of the same job earlier than feeding the agent the duty it’s to carry out. This helps the mannequin perceive the duty higher, which normally will increase efficiency.
Under you possibly can see two immediate examples. The primary instance reveals a zero-shot immediate, the place we straight ask the LLM the query. Contemplating this can be a easy job, the LLM will doubtless get the precise reply; nonetheless, few-shot studying may have a larger impact on tougher duties. Within the second immediate, you see that I present just a few examples on methods to do the maths, the place the examples are additionally wrapped in XML tags. This not solely helps the mannequin perceive what job it’s performing, nevertheless it additionally helps guarantee a constant reply format, because the mannequin will usually reply in the identical format as supplied within the few-shot examples.
# zero-shot
immediate = "What's 123+150?"
# few-shot
immediate = """
<instance>"What's 10+20?" -> "30" </instance>
<instance>"What's 120+70?" -> "190" </instance>
What's 123+150?
"""
Structured prompts
Having structured prompts can be an extremely vital a part of context engineering. Within the code examples above, you possibly can see me utilizing XML tags with <instance> … </instance>. You may as well use Markdown formatting to reinforce the construction of your prompts. I usually discover that writing a normal define of my immediate first, then feeding it to an LLM for optimization and correct structuring, is a good way of designing good prompts.
You need to use designated instruments like Anthropic’s immediate optimizer, however you may also merely feed your unstructured immediate into ChatGPT and ask it to enhance your immediate. Moreover, you’ll get even higher prompts if you happen to describe situations the place your present immediate is struggling.
For instance, you probably have a math agent that’s doing rather well as well as, subtraction, and division, however fighting multiplication, it’s best to add that info to your immediate optimizer.
Step-by-step reasoning
Step-by-step reasoning is one other highly effective context engineering strategy. You immediate the LLM to assume step by stepabout methods to resolve the issue, earlier than making an attempt to unravel the issue. For even higher context engineering, you possibly can mix all three approaches lined on this part, as seen within the instance under:
# few-shot + structured + step-by-step reasoning
immediate = """
<instance>"What's 10+20?" -> "To reply the consumer request, I've so as to add up the 2 numbers. I can do that by first including the final two digits of every quantity: 0+0=0. I then add up the final two digits and get 1+2=3. The reply is: 30" </instance>
<instance>"What's 120+70?" -> "To reply the euser request, I've so as to add up the digits going backwards to entrance. I begin with: 0+0=0. Then I do 2+7=9, and at last I do 1+0=1. The reply is: 190" </instance>
What's 123+150?
"""
It will assist the mannequin perceive the examples even higher, which frequently will increase mannequin efficiency even additional.
Shortening the context
When your agent has operated for just a few steps, for instance, asking for consumer enter, fetching some info, and so forth, you would possibly expertise the LLM context filling up. Earlier than reaching the context restrict and dropping all tokens over this restrict, it’s best to shorten the context.
Summarization is a good way of shortening the context; nonetheless, summarization can generally minimize out vital items of your context. The primary half of your context won’t comprise any helpful info, whereas the second half contains a number of paragraphs which might be required. That is a part of why agentic context engineering is troublesome.
To carry out context shortening, you’ll usually use one other LLM, which I’ll name the Shortening LLM. This LLM receives the context and returns a shortened model of it. The best model of the Shortening LLM merely summarizes the context and returns it. Nonetheless, you possibly can make use of the next strategies to enhance the shortening:
- Decide if some complete elements of the context will be minimize out (particular paperwork, earlier device calls, and so on)
- A prompt-tuned Shortening LLM, optimized for analyzing the duty at hand, all related info out there, and returns solely the data that will likely be related to fixing the duty
Decide if complete elements will be minimize out
The very first thing it’s best to do when making an attempt to shorten the context is to seek out areas of the context that may be fully minimize out.
For instance, if the LLM would possibly’ve beforehand fetched a doc, used to unravel a earlier job, the place you could have the duty outcomes. This implies the doc is just not related anymore and ought to be faraway from the context. This may also happen if the LLM has fetched different info, for instance through key phrase search, and the LLM has itself summarized the output of the search. On this occasion, it’s best to take away the outdated output from the key phrase search.
Merely eradicating such complete elements of the context can get you far in shortening the context. Nonetheless, you might want to remember that eradicating context that may be related for later duties will be detrimental to the agent’s efficiency.
Thus, as Anthropic factors out of their article on context engineering, it’s best to first optimize for recall, the place you make sure the LLM shortener by no means removes context that’s related sooner or later. Whenever you obtain virtually excellent recall, you can begin specializing in precision, the place you take away an increasing number of context that’s not related anymore to fixing the duty at hand.

Immediate-tuned shortening LLM
I additionally advocate making a prompt-tuned shortening LLM. To do that, you first have to create a take a look at set of contexts and the specified shortened context, given a job at hand. These examples ought to ideally be fetched from actual consumer interactions along with your agent.
Persevering with, you possibly can immediate optimize (and even fine-tune) the shortening LLM for the duty of summarizing the LLM’s context, to maintain vital elements of the context, whereas eradicating different elements of the context that aren’t related anymore.
Instruments
One of many details separating brokers from one-off LLM calls is their use of instruments. We usually present brokers with a collection of instruments they’ll use to extend the agent’s means to unravel a job. Examples of such instruments are:
- Carry out a key phrase search on a doc corpus
- Fetch details about a consumer given their e-mail
- A calculator so as to add numbers collectively
These instruments simplify the issue the agent has to unravel. The agent can carry out a key phrase search to fetch further (usually required) info, or it might probably use a calculator so as to add numbers collectively, which is way more constant than including numbers utilizing next-token prediction.
Listed here are some strategies to bear in mind to make sure correct device utilization when offering instruments within the agent’s context:
- Properly-described instruments (can a human perceive it?)
- Create particular instruments
- Keep away from bloating
- Solely present related instruments
- Informative error dealing with
Properly-described agentic instruments
The primary, and possibly most vital be aware, is to have well-described instruments in your system. The instruments you outline ought to have sort annotations for all enter parameters and a return sort. It must also have a great perform title and an outline within the docstring. Under you possibly can see an instance of a poor device definition, vs a great device definition:
# poor device definition
def calculator(a, b):
return a+b
# good device definition
def add_numbers(a: float, b: float) -> float:
"""A perform so as to add two numbers collectively. Ought to be used anytime it's a must to add two numbers collectively.
Takes in parameters:
a: float
b: float
Returns
float
"""
return a+b
The second perform within the code above is far simpler for the agent to grasp. Correctly describing instruments will make the agent a lot better at understanding when to make use of the device, and when different approaches is best.
The go-to benchmark for a well-described device is:
Can a human who has by no means seen the instruments earlier than, perceive the instruments, simply from wanting on the features and their definitions?
Particular instruments
You must also attempt to hold your instruments as particular as attainable. Whenever you outline obscure instruments, it’s troublesome for the LLM to grasp when to make use of the device and to make sure the LLM makes use of the device correctly.
For instance, as a substitute of defining a generic device for the agent to fetch info from a database, it’s best to present particular instruments to extract particular data.
Unhealthy device:
- Fetch info from database
- Enter
- Columns to retrieve
- Database index to seek out data by
Higher instruments:
- Fetch data about all customers from the database (no enter parameters)
- Get a sorted checklist of paperwork by date belonging to a given buyer ID
- Get an combination checklist of all customers and the actions they’ve taken within the final 24 hours
You’ll be able to then outline extra particular instruments whenever you see the necessity for them. This makes it simpler for the agent to fetch related info into its context.
Keep away from bloating
You must also keep away from bloating in any respect prices. There are two essential approaches to attaining this with features:
- Capabilities ought to return structured outputs, and optionally, solely return a subset of outcomes
- Keep away from irrelevant instruments
For the primary level, I’ll once more use the instance of a key phrase search. When performing a key phrase search, for instance, in opposition to AWS Elastic Search, you’ll obtain again lots of info, generally not that structured.
# unhealthy perform return
def keyword_search(search_term: str) -> str:
# carry out key phrase search
# outcomes: {"id": ..., "content material": ..., "createdAt": ..., ...}, {...}, {...}]
return str(outcomes)
# good perform return
def _organize_keyword_output(outcomes: checklist[dict], max_results: int) -> str:
output_string = ""
num_results = len(outcomes)
for i, res in enumerate(outcomes[:max_results]): # max return max_results
output_string += f"Doc quantity {i}/{num_results}. ID: {res["id"]}, content material: {res["content"]}, created at: {res["createdAt"]}"
return output_string
def keyword_search(search_term: str, max_results: int) -> str:
# carry out key phrase search
# outcomes: {"id": ..., "content material": ..., "createdAt": ..., ...}, {...}, {...}]
organized_results = _organize_keyword_output(outcomes, max_results)
return organized_results
Within the unhealthy instance, we merely stringify the uncooked checklist of dicts returned from the key phrase search. The higher strategy is to have a separate helper perform to construction the outcomes right into a structured string.
You must also make sure the mannequin can return solely a subset of outcomes, as proven with the max_results parameter. This helps the mannequin loads, particularly with features like key phrase search, that may probably return 100’s of outcomes, instantly filling up the LLM’s context.
My second level was on avoiding irrelevant instruments. You’ll in all probability encounter conditions the place you could have lots of instruments, a lot of which can solely be related for the agent to make use of at particular steps. If you recognize a device is just not related for an agent at a given time, it’s best to hold the device out of the context.
Informative error dealing with
Informative error dealing with is essential when offering brokers with instruments. That you must assist the agent perceive what it’s doing flawed. Normally, the uncooked error messages supplied by Python are bloated and never that straightforward to grasp.
Under is an effective instance of error dealing with in instruments, the place the agent is informed what the error was and methods to cope with it. For instance, when encountering price restrict errors, we inform the agent to particularly sleep earlier than attempting once more. This simplifies the issue loads for the agent, because it doesn’t must motive itself that it has to sleep.
def keyword_search(search_term: str) -> str:
attempt:
# key phrase search
outcomes = ...
return outcomes
besides requests.exceptions.RateLimitError as e:
return f"Fee restrict error: {e}. You need to run time.sleep(10) earlier than retrying."
besides requests.exceptions.ConnectionError as e:
return f"Connection error occurred: {e}. The community is likely to be down, inform the consumer of the difficulty with the inform_user perform."
besides requests.exceptions.HTTPError as e:
return f"HTTP error occurred: {e}. The perform failed with http error. This normally occurs due to entry points. Make sure you validate earlier than utilizing this perform"
besides Exception as e:
return f"An surprising error occurred: {e}"
You need to have such error dealing with for all features, preserving the next factors in thoughts:
- Error messages ought to be informative of what occurred
- If you recognize the repair (or potential fixes) for a particular error, inform the LLM methods to act if the error happens (for instance: if a price restrict error, inform the mannequin to run time.sleep())
Agentic context engineering going ahead
On this article, I’ve lined three essential matters: Particular context engineering suggestions, shortening the brokers’ context, and methods to present your brokers with instruments. These are all foundational matters you might want to perceive to construct a great AI agent. There are additionally additional matters that it’s best to be taught extra about, such because the consideration of pre-computed info or inference-time info retrieval. I’ll cowl this matter in a future article. Agentic context engineering will proceed to be an excellent related matter, and understanding methods to deal with the context of an agent is, and will likely be, elementary to future AI agent developments.
👉 Discover me on socials:
🧑💻 Get in touch
✍️ Medium
You may as well learn a few of my different articles: