AutoGen Development

Microsoft has been consolidating its agent work: AutoGen 0.4 remains the mature, supported framework for conversational multi-agent systems, while the newer Agent Framework merges ideas from AutoGen and Semantic Kernel into a unified surface. Our position is pragmatic — if you have an AutoGen estate, we maintain and extend it; for new builds we assess both and isolate framework-specific code behind your own interfaces either way. Betting your architecture on any single vendor framework unmodified is the risk; the design patterns transfer. Concretely, your tool implementations, system prompts, termination logic and eval sets survive a framework port — that is most of the investment — so we protect those first.

AutoGen’s distinctive strength is conversational problem-solving with code execution — agents that write, run and debug code against data, which suits analysis, data engineering and research workloads. CrewAI is faster to a business-readable role-based system; LangGraph gives you explicit state graphs with checkpointing and precise interrupt semantics. For a deterministic business process we would usually steer you away from AutoGen; for a workload where agents genuinely need to compute their way to an answer, it is often the strongest option. The 0.4 async core also matters if you are on .NET-adjacent infrastructure or need agents that run concurrently and stream progress. We build on all three.

With the right constraints, yes — and without them, no. The failure mode of conversational systems is unbounded dialogue: agents politely agreeing in circles while the meter runs. Production AutoGen systems need explicit termination conditions, message and token budgets, tool surfaces that keep agents inside their role, and an eval suite that measures both success rate and turns-to-solution. We also match the pattern to the problem — open-ended GroupChat for genuinely exploratory tasks, tighter sequential topologies for anything that must behave predictably. The honest framing: conversational multi-agent is a research-grade technique that we productionise with guardrails, not a default pattern we reach for when a pipeline would do.

Agent code executes in Docker containers with no host credentials, resource limits, and a network policy that allows only what the task requires — usually nothing external at all. Filesystem access is a mounted scratch volume, and secrets are injected per-tool at the tool layer rather than being visible to generated code. Code that touches production data or triggers external actions goes through a human approval step. We also cap execution time per run and log every executed snippet to the trace, so there is a complete record of what the agent ran — which matters both for debugging and for any security review. The operating assumption is that generated code is untrusted, and the sandbox is engineered accordingly.

Yes. The 0.4 model-client abstraction supports OpenAI, Azure OpenAI, Anthropic, Google and local models through community clients, and different agents in the same team can run on different models. In practice we exploit this for cost: the orchestrator and the agent doing the hard reasoning get a frontier model, while summarisation and formatting roles get a small cheap one. Per-agent model assignment is a config-level change, so we tune it against eval results rather than guessing. For deployments with data-residency requirements, the code-execution roles can run entirely against a self-hosted model while non-sensitive coordination roles use hosted APIs.

The strongest fits we see: data analysis agents that write and execute code against warehouses; research systems where agents debate and verify each other’s findings; document-processing pipelines where extraction code is generated per document type; and internal copilots for engineering teams that need to run scripts safely. The weakest fits are simple linear automations and anything with a hard real-time latency budget — conversational coordination costs turns, and turns cost both time and tokens. If your workload is "look up a record and update it," that is a workflow, not a conversation, and we will build it as one.