Alright, so you saw some hype about AutoGen and want to see if it's actually useful for a real, simple task. Let's cut through the fluff. Classifying customer feedback is a classic starter project, and everyone's favorite framework loves to tout its "agentic workflows" for this. I'm here to tell you the bare minimum you need to get something that works, without getting tangled in their overly-complex examples.
First, forget the multi-agent debate scenarios for a simple classifier. You need one AssistantAgent with a clear system prompt and a UserProxyAgent to run the code. That's it. The real trick is forcing AutoGen to use local models or a specific API endpoint without defaulting to OpenAI, because the docs sure love to assume you're fine with that vendor lock-in. Here's a config that actually works for using a local Ollama instance.
```python
from autogen import AssistantAgent, UserProxyAgent
config_list = [
{
'model': 'llama3.2:latest', # or whatever you're running locally
'api_base': 'http://localhost:11434/v1',
'api_key': 'ollama', # literally just 'ollama', it's a placeholder
}
]
llm_config = {
"config_list": config_list,
"timeout": 120,
}
assistant = AssistantAgent(
name="classifier",
system_message="You are a classifier. You will receive customer feedback. Classify it into one of: BUG, FEATURE_REQUEST, COMPLAINT, or COMPLIMENT. Return only the category.",
llm_config=llm_config,
)
user_proxy = UserProxyAgent(
name="user_proxy",
human_input_mode="NEVER",
code_execution_config={"work_dir": "feedback", "use_docker": False},
)
```
Now, the workflow. You don't need a group chat. You just initiate a chat from the user proxy to the assistant with your feedback text. The catch? AutoGen loves to make the AssistantAgent try to write Python code for everything. You have to beat it over the head with that system prompt and explicitly tell it not to write code. Even then, sometimes it gets "helpful." Be prepared to tweak.
```python
feedback_samples = [
"The app crashes every time I click the save button.",
"I'd love a dark mode theme.",
"Your customer service representative was incredibly rude.",
"This product has changed my workflow for the better!",
]
for feedback in feedback_samples:
user_proxy.initiate_chat(
assistant,
message=f"Classify this feedback: '{feedback}'",
)
```
You'll get your classifications, but you'll also likely get a bunch of extraneous reasoning text unless your system prompt is brutally strict. This is where the "under an hour" claim falls apart—you'll spend most of that time fighting the agent's instincts to be "helpful" rather than just doing the simple task.
The result works, but it's a glorified LLM call wrapped in several layers of abstraction. For a production pipeline, you'd strip out AutoGen and call the model directly. This exercise is useful only to see if the framework's patterns are worth the overhead for more complex logic. For me, it usually isn't.
Just my 2 cents
Just my 2 cents
While I appreciate the focus on a minimal setup, your approach completely sidesteps the underlying infrastructure that makes this viable beyond a laptop demo. Configuring an agent to hit a local Ollama instance is fine for initial prototyping, but it falls apart when you consider latency, scalability, and model management in a real pipeline.
For any serious use, the LLM endpoint should be a managed service, either from a cloud provider or a self-hosted inference platform like vLLM or TGI, deployed on Kubernetes. You'd then expose it via an internal load balancer, and your AutoGen config would point to that cluster-internal service endpoint with proper retry logic and connection pooling. Relying on a localhost call locks you into a single point of failure.
Also, you haven't addressed how you'd version or roll back the model used by the `AssistantAgent`. Hardcoding `'llama3.2:latest'` is a recipe for drift and inconsistent classifications. This is where a model registry and injecting the model tag via an environment variable becomes critical.
Boring is beautiful
>the real trick is forcing AutoGen to use local models or a specific API endpoint without defaulting to OpenAI
This is the key unlock, 100%. The API config is where the magic happens, but your snippet cut off the `timeout` value and you're missing the `api_type` field. If you don't set `api_type: "openai"`, it'll still try to ping Azure endpoints first and fail. Here's the corrected `llm_config`:
```python
llm_config = {
"config_list": config_list,
"timeout": 120,
"api_type": "openai"
}
```
Also, you'll want to pass `llm_config` to *both* the `AssistantAgent` *and* the `UserProxyAgent`, not just the assistant. If you don't, the user proxy will just hang waiting for human input instead of executing code. Took me an hour to figure that one out 😅
pipeline all the things
Yes, the `api_type` field is so crucial! It's a common tripwire. I've found that for some local endpoints, you might also need to explicitly set `api_key` to a dummy placeholder like `"none"` in your config list to stop it from looking for a real OpenAI key.
And good call on applying `llm_config` to both agents. That one had me stuck for a while too, thinking the user proxy was just being stubborn. 😅 It makes sense when you realize the user proxy needs the config to know *how* to get the code-execution approval from the LLM.
One thing to watch: if your local model is a bit slow, bumping that timeout even higher (like 300) saved me from a lot of silent failures.
Automate everything.