A 2023 AutoGen Tutorial: Local Agent Setup and Code Execution

I previously introduced AutoGen and now want to walk through a local Python setup, line by line. The idea is to have AI agents communicate and use tools or code on a user’s behalf. This video dates from October 2023: its library interfaces and model choices are historical, and a later AutoGen version may require different code.

I describe AutoGen as a way to assemble customizable agents that collaborate on tasks. An assistant can generate a response or code, while another agent can represent the user and potentially run that code. These capabilities depend on the configuration and do not mean the agents can reliably accomplish any task.

For the demonstration I use VS Code, Anaconda and an OpenAI account. I create a project folder and `app.py`, open the terminal and create a conda environment named `autogen` with Python 3.11.4. I activate it and check that the interpreter selected in VS Code matches the environment.

I install the package then shown as `pyautogen` and import `autogen`. Do not treat that historical command as a recommendation to install its latest release: Microsoft says it no longer administers that package and later releases are not from Microsoft. Its migration guide explains supported package choices and major API changes.

The legacy configuration list names a model, initially GPT-3.5 Turbo 16k, and an API key. I generate and paste a key in the video, saying I will revoke it before publication. For a real project, keep credentials in an environment variable or secret manager and out of source control and recordings; the key in the footage is not reproduced here.

The `llm_config` includes a request timeout, a seed for the version’s caching behavior, the configuration list and a temperature of zero. I use a low temperature for a coding example. Temperature affects sampling, not a guaranteed measure of creativity or correctness.

Caching can avoid repeated API calls when a matching request is found, saving time and cost. I show a cache associated with seed 42 and clear it to force fresh runs. Cache behavior depends on request matching and version: later AutoGen documentation distinguishes its `cache_seed` from a model provider’s sampling `seed`.

I create an `AssistantAgent` with a name and the model configuration. Multiple assistants can be given distinct roles, such as a CTO and CEO, using system messages. This particular example uses one assistant and one user proxy; naming roles alone does not make them independent experts.

The `UserProxyAgent` acts on the user’s behalf and may send replies or execute generated code. The older tutorial shows three human-input modes: `ALWAYS`, `TERMINATE` and `NEVER`. In the legacy documentation, `TERMINATE` can prompt on a termination message or when the automatic-reply limit is reached, not only when a task is genuinely complete.

I set `max_consecutive_auto_reply` to 10 and define a termination-message check. The cap limits an unproductive exchange and its cost, though it is not a guarantee that a task is complete. The `web` working directory holds the demonstration’s generated files.

The proxy’s code-execution setting allows generated code to run, which has real consequences for files and the environment. A working directory is not a security boundary. Review generated code and restrict execution; the legacy AutoGen documentation recommends Docker isolation for code execution, or it can be disabled.

I write a task asking for an article summary, then start the conversation with the user proxy’s `initiate_chat` method, passing in the assistant and the task as the message. The 2023 API shown is an example of the older design; newer AutoGen versions changed the agent and execution interfaces.

The initial GPT-3.5 run does not complete the article task. Instead, the agents exchange unhelpful messages. I point to the limit of 10 automatic replies as a useful guard against an excessively long conversation, and show the cache created by the run.

For a simpler test, I switch to GPT-4, clear the cache and ask for Python to output the numbers 1 through 100 and store the result in a file. The agent produces `numbers.txt` containing the numbers. That works as a file-writing task, but it is not the code file I intended.

After accidentally exiting before giving feedback, I revise the prompt to explicitly ask for the code to be saved in a file. I clear the previous outputs and rerun it. This time the demonstration produces a Python file in the working directory, showing why the exact instruction and the actual artifact both matter.

I add a second task asking the agents to change the code from outputting 1–100 to 1–200, and initiate another conversation. For this run I switch human input to `NEVER`. That removes the approval opportunity in the workflow; it does not make automatic code execution risk-free.

The second run does not follow my intended instruction exactly: the existing Python file remains, and the agents create a text file with numbers through 200 and code to update it. I attribute part of the mismatch to an insufficiently precise prompt, while the observed result also shows that generated agents can misunderstand a task.

I suggest moving the model and API key into environment variables or a separate configuration file, keeping secrets out of commits, and organizing the agent definitions. The example can be extended with other tasks or agents, but current users should follow version-specific documentation and verify generated code and outputs.