Termination Conditions within Agents

[BenConstable9]

What feature would you like to be added?

Add Termination Conditions to the Agent's themselves, rather than the team manager. This would enable you to terminate the tool calling of an agent when a certain condition is met.

Why is this needed?

As observed, sometimes Agent's can get stuck in a loop where it is constantly tool calling and never exits back to the team manager. This scenario would prevent this.

[yeandy]

Can you give an example of how/why the agent gets stuck in a loop? Is it when the LLM's response always contains a FunctionCall in the content of its results? https://github.com/microsoft/autogen/blob/main/python/packages/autogen-agentchat/src/autogen_agentchat/agents/_assistant_agent.py#L247

Would it be useful to have conditions such as "max_tool_calls"? i.e. we want the agent to use the tool once and only once.

[jackgerrits]

An agent can request for the conversation to be terminated by emitting a StopMessage, however, it is up to the termination condition being used in the group chat manager to respect the request to stop. The StopMessageTermination termination condition does exactly this. If you wanted to combine agent based stop requests with another condition you can write a custom condition that build the desired logic.

We could explore creating and/or conditions to nest conditions but given the ease of creating a new one and the slim logic of the conditions themselves I feel like this is overkill at the moment.

[ekzhu]

The agent should give up control when it encounters issues like too many tool calls. In that case it should yield the control back to the team, either via a StopMessage or another message type to signal to the team that it has encountered an issue it doesn't know how to solve.

Then, from the team's orchestrator, e.g., the group chat manager, it makes a decision what to do with this message. A reasonable choice is to yield the control back to the application/user. This allows the application/user to have better control over individual agents' behavior, not just the team's. This logic of deciding to yield control back to the application/user should exist in the team's orchestrator.

Currently this can be done via the agent returning a StopMessage and the team is setup with StopMessageTerminationCondition. However, a missing logic is the notion of resuming the same agent that gave up control in the first place. E.g., for RoundRobinGroupChat, this will move the control to the next agent, not the one that gave up control. For SelectorGroupChat, it is possible to customize or prompt the orchestrator, but too tedious. It only works for Swarm but the logic is implicit as Swarm by default choose the previous speaker when resume.

[ekzhu]

To fix the problem with AssistantAgent's potentially infinite tool call loop, I agree with @yeandy that setting a parameter something like max_tool_calls=2 can help. If the agent exits the loop and the last message it produced is still tool call, make another inference to the model without the tools and generate a final response. We can make this response using a new message type so the team can make better decision.

Though I do think there is a separate issue of adding a notion of "resuming" an agent, and it is worth having.

Could be just adding a next_agent="agent_name" override to run and run_stream methods for group chats.