Swarm Enhanced Features
If you haven’t had a chance to read about or use AG2’s Swarm orchestration, see the Basic Concepts section on Swarm.
You can build complex, yet flexible, workflows using AG2’s Swarm orchestration.
In this walk-through of a customer service workflow, we will utilize three of the advanced features available in a Swarm orchestration:
- Updating an agent’s state
- Nested chats
- Conditional handoffs
Visualizing a Swarm
It’s useful to draw your agents, flows, context variables, and tools and then create the swarm based on the diagram.
This is the scenario we will run through, with customers able to enquire about their orders. However, we will make sure that they are authenticated to do so.
Key aspects of this swarm are:
- System messages are customized, incorporating the context of the workflow
- A nested chat handles the order retrieval and summarization
- Handoffs are conditional, only being available when they are relevant
Setting up
Context
With all agents in a Swarm sharing a common context as well as being able to use that context in system messages and hand-off conditions, context variables are a key component to AG2’s Swarm.
We’ll use the customer details to help the LLM know who the user is and be able to greet them appropriately.
The two workflow status keys will be used to ensure they are logged in, allowing and blocking hand-offs as needed.
Similarly, the has_order_id
keys will be used to ensure no hand-offs are available that require an order id.
We assign this context to the Swarm when initiating it and it will be attached to all agents.
Mock database
We’ll use dictionaries to mock actual databases. These will be used to validate the user based on a username (USER_DATABASE
) and then to retrieve orders using that username to filter orders that can be queried (ORDER_DATABSE
).
Order and Authentication Functions
Here are the functions we’ll soon add to our agents.
In Swarms, functions can be used to handle transitions to the next agent as well. Return an SwarmResult
and setting the agent
allows you to determine who the next agent is. If you don’t set the agent
parameter, it will be determined through hand-offs or other functions.
Later we will see the use of the available
parameter in an OnCondition hand-off to determine if a hand-off is made available for evaluation by the LLM. As that parameter takes a context variable that must be equivalent to True
, we use two context variable keys to control authentication hand-offs, logged_in
and requires_login
, which have alternating boolean values.
If you are updating context variables in a function, be sure to return it in the SwarmResult
so the shared context variables can be updated.
Agents with dynamic system message
Here are our agents and we register the functions we created above with them.
The first of our features for this enhanced Swarm walk-through is done here, UpdateSystemMessage
. By incorporating context variables into our agent’s prompts (e.g. {customer_name}
) and using UpdateSystemMessage
with the agent’s update_agent_state_before_reply
hook, the agent’s system message will be updated with the values from the context variables before they reply (goes to the LLM).
This provides robust context for the LLM to work with, allowing the LLM to make better decisions on what do to next.
Nested chats
For tasks that require a separate AG2 chat to occur, nested chats are a great option. This is the second enhanced feature we’re covering, nested chats as hand-offs.
In our scenario, we want to be able to find out the details of an order if a customer asks. To do this we need a couple of agents, one with access to the order database, to work together to retrieve and summarize the order details.
Our nested chats are setup as a queue of two chats, the first is for the order_retrieval_agent
who will extract the order information from the database and pass the details of it on to the second chat. The order_summarizer_agent
uses their LLM to format that and return it to the Swarm.
Conditional hand-offs
The ability to turn an OnCondition hand-off on or off is the third enhanced feature of swarms covered in the walk-through.
Using the available
parameter of an OnCondition with a context variable key or a Callable allows us to show/hide the option from the LLM when they’re determining what to do next.
Together with the ability to put context into an agent’s system message (UpdateSystemMessage
covered earlier), we’re afforded both the ability to control what options they have and also improved reasoning LLM capability through better context.
Here we can see the use of context variable keys in the available
parameter as well as the has_order_in_context
function as an alternative to context variables. You will notice that the function does the same as using a context variable key string in this case.
Initiate Swarm and run
Below is an abbreviated output from running the Swarm. It will be broken up so we can understand what’s happening.
The only hand-off available was to the authentication_agent as the user requires login. We’ve prevented going to the order management agent.
Our authentication function has been used to authenticate the user my username, ensuring an incorrect username, “barry”, didn’t trigger a login. This blocked any chance of handing off to the order management agent, again.
We tried to give them the two order ids that weren’t associated with the username “mark”. Using the shared context with the username allowed us to do that.
Eventually we’ve been able to get the order id and it has been recorded in the context variables.
Next, with the valid order id on hand, we move on to the nested chat.
Our nested chats queue ran, with the order_retrieval_agent
validating and retrieving the order and the order_summarizer_agent
taking those details and summarizing them before returning them to the Swarm.
Finally, with no more queries we return back to the triage agent and the workflow is complete.
Using the three enhanced features of AG2’s Swarm, we were able to control the flow effectively, minimising the impact of hallucinations and giving the customer a better service experience.
Visualizing the flow
Here’s the flow above.
At the beginning, we weren’t logged in and there was only one path.
After we logged in, we needed to get the order id.
With the order id, we can handle order enquiries and retrieve order details.