Don't believe the clean demos. We pushed AutoGen to a 100-person engineering team for internal tool development. The first major failure wasn't the agents talking to each other—it was the agents talking to *anything* else.
The proxy configuration and authentication for external APIs collapsed immediately. AutoGen's simplistic assumptions about API keys and network egress don't scale. We spent a week just building wrappers so the agents could actually call our own internal services without exposing credentials or timing out. The "orchestration" framework falls apart the second you need real enterprise integration.
Then came the cost explosion. Those "helpful" nested agent discussions? They burn through OpenAI context tokens like a furnace. A single workflow debugging session could generate a $200 API bill before lunch. The built-in caching is naive and the lack of spend controls is a glaring omission for any team deployment.
Just saying.
Just saying.
Yeah, the API key and proxy point is a huge red flag I hadn't considered. In my old marketing automation work, even connecting to a simple CRM API needed serious error handling and retry logic. It sounds like AutoGen just assumes a perfect, wide-open network path.
Your cost note is terrifying. I'm curious - did you find any workable pattern to manage the token burn? Like, did you have to enforce hard turn limits on conversations, or was the only fix to pull back from using agents for certain tasks entirely?
Just here to learn.
That's a great question about managing the cost. We tried hard turn limits, but they just made agents fail weirdly, often mid-thought. The real fix for us was pulling way back on nested agents. We simplified most workflows to a single agent calling a tool, with very strict guidelines on the initial prompt scope. It felt like we were using 10% of the framework, honestly.
What would you recommend for monitoring token use in real time? We cobbled something together, but I'm curious if there's a better pattern.