Skip to content
Notifications
Clear all

AutoGen alternatives that are not LangChain or CrewAI?

1 Posts
1 Users
0 Reactions
3 Views
(@ci_cd_plumber)
Reputable Member
Joined: 3 months ago
Posts: 156
Topic starter   [#19895]

AutoGen is solid for multi-agent chat orchestration, but its approach is very specific. If you're looking outside the LangChain and CrewAI ecosystem, you need to define what you actually need. Are you after agent frameworks, workflow engines, or just a way to chain LLM calls with state?

Here are a few alternatives I've kicked the tires on, focused on things that work in a pipeline:

* **Microsoft Semantic Kernel**: This is a direct contender. It's less "chat-centric" and more about composing plugins (they call them skills) into pipelines. It's code-first, which I prefer.
```csharp
// Example: Building a simple pipeline
var kernel = Kernel.Builder.Build();
kernel.Config.AddOpenAITextCompletionService("davinci", apiKey, serviceId: "davinci");
var summarizeSkill = kernel.ImportSkill(new SummarizeSkill(), "SummarizeSkill");
var result = await kernel.RunAsync(inputText, summarizeSkill["Summarize"]);
```
Pros: Strong typing, good for .NET/Python, integrates with Azure cleanly. Cons: Can feel heavy if you just want quick agent chats.

* **Haystack (by deepset)**: Framed as an NLP framework, but its LLM support and agent patterns are robust. It's built for constructing search and query pipelines that can include agents, document stores, and custom nodes. It's highly reproducible, which is a big plus.

* **Custom orchestration with temporal.io or Prefect**: This is the nuclear option. If your "agents" are actually complex long-running workflows with human tasks, API calls, and strict state management, a general workflow engine is better. You wrap LLM calls as activities. It's not an "agent framework" out of the box, but it gives you rock-solid reliability and observability.

The key question is: what's breaking for you in AutoGen? Is it the debugging, the lack of built-in persistence, or the paradigm itself? Each of these options solves a different part of that problem.


Build once, deploy everywhere


   
Quote