Activate deactivate agents

[peterychang]

Why are these changes needed?

Create startup/shutdown functions

Related issue number

#4705

Checks

• I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
• I've added tests (if relevant) corresponding to the changes introduced in this PR.
• I've made sure all auto checks have passed.

[peterychang]

Getting this up for review. I'll see if any other agents need something done and add documentation for this after the holidays

[jackgerrits]

Let's keep it to deactivation initially since there is currently no clear use case for activation but there is for deactivation

[jackgerrits]

Also matter of preference, but I would prefer close

[jackgerrits]

Considering we just want shutdown, would be easier to just iterate _instantiated_agents here instead

[peterychang]

instantiated agents aren't necessarily activated. I was worried there would be code that could break in deactivate if it weren't set up in activate (I saw these functions as pairs)

[jackgerrits]

That's my point - I don't think we want to introduce two phase initialization here without a clear reason.

I dont view it as a pair because deactivate is more like a destructor

[husseinmozannar]

reminder to also update autogen studio code where close is called or create an issue so that victor updates it later

[peterychang]

Let's keep it to deactivation initially since there is currently no clear use case for activation but there is for deactivation

Is there a particular reason not to have the activation portion in place? The behavior for everything right now is just passing, and I could foresee situations where you want a separate initialization component outside the constructor

[jackgerrits]

Let's keep it to deactivation initially since there is currently no clear use case for activation but there is for deactivation

Is there a particular reason not to have the activation portion in place? The behavior for everything right now is just passing, and I could foresee situations where you want a separate initialization component outside the constructor

Initialization should happen in the agent's factory so the functionality is already provided and then just adds a different way to achieve the same thing without a clear use case.

[peterychang]

Let's keep it to deactivation initially since there is currently no clear use case for activation but there is for deactivation

Is there a particular reason not to have the activation portion in place? The behavior for everything right now is just passing, and I could foresee situations where you want a separate initialization component outside the constructor

Initialization should happen in the agent's factory so the functionality is already provided and then just adds a different way to achieve the same thing without a clear use case.

Ok. The task described activation as lazily being called on the first message to the agent. In that case, I'll just remove the activation portion and assume its part of the factory

[jackgerrits]

Let's keep it to deactivation initially since there is currently no clear use case for activation but there is for deactivation

Is there a particular reason not to have the activation portion in place? The behavior for everything right now is just passing, and I could foresee situations where you want a separate initialization component outside the constructor

Initialization should happen in the agent's factory so the functionality is already provided and then just adds a different way to achieve the same thing without a clear use case.

Ok. The task described activation as lazily being called on the first message to the agent. In that case, I'll just remove the activation portion and assume its part of the factory

Yep, let's assume instantiation==activation. Then deactivation is just destruction. Less book keeping and simpler

[jackgerrits]

@ekzhu what are your thoughts on this? I often see stop() and start() run multiple times in a sequence, this effectively breaks this.

@peterychang it might be better add close to SingleThreadedAgentRuntime and just do it on demand there?

[peterychang]

It seems a little redundant to have to call close() before stop() every time you want to stop the runtime. It also doesn't really take care of the `stop_when_idle' case, since shutdown will occur outside of the caller's control.

I'll separate out the call just to clean up the duplicate code though

[jackgerrits]

We have tests that start and stop the same runtime in sequence since the expectation is that you're just starting/stopping the processing loop - not killing the agents themselves.

autogen/python/packages/autogen-core/tests/test_routed_agent.py

Line 57 in 00a6558

async def test_message_handler_router() -> None:

These tests also call try_get_underlying_agent_instance after calling stop, so the expectation is the agents arent dead yet.

I think for this reason we would want stop and close to be distinct calls. The runtime can become a context manager then people don't really need to think about closing and makes it more idiomatic. Close can also call stop if it hasn't been called already as a nicety