Skip to main content
Context engineering is the process of designing and controlling the information (context) that is sent to language models to guide their behavior and outputs. In practice, building context comes down to one question: “Which information is most likely to achieve the desired outcome?” Effective context engineering is an iterative process: refining the system message, trying out different descriptions and instructions, and using features such as schemas, delegation, and tool integrations. The context of an Agno team consists of the following:
  • System message: The system message is the main context that is sent to the team, including all additional context
  • User message: The user message is the message that is sent to the team.
  • Chat history: The chat history is the history of the conversation between the team and the user.
  • Additional input: Any few-shot examples or other additional input that is added to the context.

System message context

The following are some key parameters that are used to create the system message:
  1. Description: A description that guides the overall behaviour of the team.
  2. Instructions: A list of precise, task-specific instructions on how to achieve its goal.
  3. Expected Output: A description of the expected output from the Team.
  4. Members: Information about team members, their roles, and capabilities.
The system message is built from the team’s description, instructions, member details, and other settings. A team leader’s system message additionally includes delegation rules and coordination guidelines. For example:
instructions.py
Will produce the following system message:
By default, instructions are not wrapped in <instructions> tags. If you prefer to wrap instructions in XML tags (for example, when using models that benefit from XML structure), set use_instruction_tags=True:

System message Parameters

The Team creates a default system message that can be customized using the following parameters: See the full Team reference for more information.
Configuration Warning: Setting delegate_to_all_members=True and respond_directly=True together logs a warning and disables respond_directly.

Orchestration Parameters

The Team class provides several parameters to control how the team leader orchestrates work across members:

How the system message is built

Lets take the following example team:
Below is the system message that will be built:
This example is exhaustive and illustrates what is possible with the system message, however in practice you would only use some of these settings.

Additional Context

You can add additional context to the end of the system message using the additional_context parameter. Here, additional_context adds a note to the system message indicating that the team can access specific database tables.

Team Member Information

The member information is automatically injected into the system message. This includes the member ID, name, role, and tools. You can optionally minimize this by setting add_member_tools_to_context to False, which removes the member tools from the system message. You can also give the team leader a tool to get information about the team members.

Tool Instructions

If you are using a Toolkit on your team, you can add tool instructions to the system message using the instructions parameter:
These instructions are injected into the system message after the <additional_information> tags.

Agentic Memories

If you have enable_agentic_memory set to True on your team, the team gets the ability to create/update user memories using tools. This adds the following to the system message:

Agentic Knowledge Filters

If you have knowledge enabled on your team, you can let the team choose the knowledge filters using the enable_agentic_knowledge_filters parameter. This will add the following to the system message:
Learn about agentic knowledge filters in more detail in the knowledge filters section.

Set the system message directly

You can manually set the system message using the system_message parameter. This will ignore all other settings and use the system message you provide.

User message context

The input sent to the Team.run() or Team.print_response() is used as the user message. See dependencies for how to do dependency injection for your user message.

Additional user message context

By default, the user message is built using the input sent to the Team.run() or Team.print_response() functions. The following team parameters configure how the user message is built:
  • add_knowledge_to_context
  • add_dependencies_to_context
The user message that is sent to the model will look like this:

Chat history

If you have database storage enabled on your team, session history is automatically stored (see sessions). You can now add the history of the conversation to the context using add_history_to_context.
This will add the history of the conversation to the context, which can be used to provide context for the next message. See more details on sessions.
All team member runs are added to the team session history.

Managing Tool Calls

The max_tool_calls_from_history parameter can be used to add only the n most recent tool calls from history to the context. This helps manage context size and reduce token costs during team runs.
In this example:
  • Run 1-3: Team sees tool calls [1], [1,2], [1,2,3,4,5]
  • Run 4: Team sees tool calls from runs that fit within the last 5 tool calls (older tool calls filtered out)
  • Run 5: Team sees tool calls from runs that fit within the last 5 tool calls (earlier tool calls filtered out)
Important: max_tool_calls_from_history filters tool calls from the runs loaded by num_history_runs. Your database always contains the complete history.
See the full example for a complete demonstration.

Additional input

You can add entire additional messages to your team’s context using the additional_input parameter. These messages are added to the context as if they were part of the conversation history. You can give your team examples of how it should respond (also called “few-shot prompting”):

Context Caching

Most model providers support caching of system and user messages, though the implementation differs between providers. The general approach is to cache repetitive content and common instructions, and then reuse that cached content in subsequent requests as the prefix of your system message. In other words, if the model supports caching, you can reduce the number of tokens sent by placing static content at the start of the system message. Agno’s context construction is designed to place the most likely static content at the beginning of the system message. If you want more control, you can fine-tune this by manually setting the system message. For teams, member information, delegation instructions, and coordination guidelines are usually static and therefore strong candidates for caching. Some examples of prompt caching:

Developer Resources