Remove `termination_condition` from team's constructor

[ekzhu]

Because at the team-level, the termination should be some built-in logics of the team itself.

termination_condition should be task-related, so we use it with run.

[victordibia]

Wanted to use this thread from some generic discussion we can use to share some thoughts as we figure out the agentchat api (no need for immediate action).

When Should Termination Condition be determined?

I think a key question here is
Should termination condition be determined at

• Build time - termination condition is defined when the agents/teams are built.
• Run time - termination condition is defined when the task is run by the end user.

Termination Condition at Build Time

Some reasons why termination condition should be set at build time:

Termination condition for the team/workflow is intrinsically related to the design of core agent behaviour.

E.g., setting termination_condition = StopMessageTermination will only work with agents that actually produce a StopMessage and has a prompt that supports this (e.g. outputs a terminate string that causes a StopMessage to be returned). Similarly TextMessageTermination will only work if the agent has been designed to output that specific text. What this also means is that adding TextMessageTermination or StopMessageTermination at run time to an agent that does not support these things will do ... well nothing (assuming no checks). This perhaps increases the potential of runtime misconfigurations.

Note

For termination condition to work well, it seems the creator of the termination condition must be familiar with the agent design. Happy to get thoughts on if this is accurate for most circumstances. @ekzhu

Good developer experience benefits from separating instantiation and run

Most libraries separate instantiation and running for improved developer experience.

• pytorch: Define model layers in __init__() and use them in forward()
• fastapi and flask: Instantiate the app via app = FastAPI() and decorate your function via app.get(...)
• ell-ai: import ell and decorate your function via @ell.simple(model="gpt-4o")

In many cases, teams will be wrapped into stateless apis that take a task.
I expect usage (amongst other types of usage) that looks like this.

from fastapi import FastAPI
from stock_team import StockTeam

app = FastAPI()
team = StockTeam() # wires up all the agents into a round robin team

@app.post("/stocks")
async def plot_stocks(tickers: list[str]):
    return await team.run(f"Plot a chart of {tickers} stock price change YTD.")

In situations where the application requires state, the common approach is have the application maintain state (e.g, in a db) and teams offer a history object that can enable resuming state (best effort). This is what autogen studio does. All messages are serialized to a db, and to continue a conversation, best effort is done to repopulate agent history with messages from db.

Note

Ofcourse, a clear issue here is that setting termination condition at build time may make the workflow "inflexible". However, due to the tight coupling between agent design and termination condition, this might be something we have to live with? Happy to hear thoughts here too.

Termination Condition at Task Run Time

Cases where termination condition is set as part of the task.

I can see this happening in some user-in-the-loop scenarious where the user perhaps wants longer conversations e.g., using MaxMessageTermination , and increasing max_messages in a subsequent call to run helps. I just do not anticipate this often .

Happy to get thoughts.
@jackgerrits @afourney @gagb

[ekzhu]

Agree. Let's move the termination condition to the constructor and remove it from run.

We should also add a reset() method to group chat teams to reset the conditions