AutoGen separates agent conversation from execution control

Microsoft Research’s September 25 introduction of AutoGen puts a conversational interface around a practical developer task: coordinating language models, people and tools. The Python framework is in preview, with configurable agents that exchange messages rather than requiring every workflow to be written as a fixed sequence. Microsoft announcement

Its launch-day code shows why “human involvement” and “code execution” need separate configuration. An agent can ask a person for input while still being configured to execute the next suggested program. Conversely, an assistant can generate code without being the component that runs it.

File photo: Microsoft buildings, efes, 2015. CC0 1.0, via Wikimedia Commons. Recompressed and responsively cropped; not the AutoGen launch.

The assistant and the proxy have different defaults

In the September 25 repository snapshot, AssistantAgent uses a language model but disables code execution by default. UserProxyAgent does the reverse: its model-based replies are disabled, while code execution is enabled and its human-input mode defaults to ALWAYS. The two can therefore form a feedback loop in which one proposes code and the other returns its output. Assistant, user proxy

But ALWAYS describes how often the proxy asks, not a requirement for a typed approval before every program. The prompt lets a person press Enter to skip their reply and continue automatically. Unless the incoming message meets the termination condition, that empty response can lead into the code-execution handler.

The same implementation provides TERMINATE and NEVER modes for different involvement patterns. It also accepts a custom termination test and a per-sender automatic-reply limit. In this snapshot, a positive limit governs the TERMINATE and NEVER paths; ALWAYS continues to ask on each message. These controls don’t prove that a task succeeded or impose a global spending ceiling. Reply handling

Where code runs is another choice

The execution utility distinguishes running in the current environment from launching a Docker container. Its actual default depends on whether the Python Docker package can be imported. With Docker disabled, or when the process already detects itself inside a container, it runs a subprocess in the current environment.

When it creates a container, it mounts the configured working directory with read-write access. That makes files available to the task, but also means “containerized” doesn’t describe a workspace isolated from all persistent files. These are implementation details developers can inspect, not a security certification from this report. Execution utility

The distinction extends to time limits. The utility documents a default execution timeout, but its current-environment Windows branch explicitly doesn’t enforce one. A conversation’s automatic-reply limit and a program’s execution timeout therefore govern different parts of the workflow.

Configure the workflow, not just the agent’s role

The useful connection is that role, participation and execution environment are independent settings. Naming an agent a user proxy doesn’t make it human-only; asking for feedback doesn’t disable automatic execution; choosing a container still leaves a deliberate file-sharing boundary.

The launch repository separates its licensing too: code is MIT-licensed, while documentation and other content use CC BY 4.0. Those grants don’t include Microsoft trademark rights. The source snapshot identifies itself as version 0.1.1; this report examines its controls without claiming to have run the framework or measured its performance. Pinned README