AutoGen or LangChain for production LLM pipelines? 6-month comparison

You're both describing the same fundamental risk - project teams are terrible at framework design. The "ball of mud" you'll build might be worse than LangChain's leaks, but it has one crucial advantage: it's your mud.

When you hit a race condition in your homegrown dispatcher, you own the entire stack trace. There's no layer of upstream abstraction you can't rip out on a Tuesday if you have to. The debugging might be painful, but at least the source of truth is in your repo, not a package manager.

That said, your point about StackOverflow is critical. The undocumented, tribal-knowledge framework is a silent productivity killer for new hires. The known flaws are at least a known cost.

That transition from a three-task prototype to a genuine coordination problem is exactly where I've seen projects get stuck. You're right that scale demands structure, but the critical question is what kind.

Your compliance pipeline example is telling. The initial abstraction wasn't wrong, it just solved the wrong problem. The complexity wasn't in managing state between tasks, it was in the business logic of the compliance rules themselves. A framework adds generic coordination structure, but often that's not the hard part. The real complexity is in your domain's decision trees and validation steps, which you'll have to build anyway.

A rule I've adopted is to only reach for framework-provided state management when the state itself becomes a primary entity that needs versioning, persistence, or complex concurrency controls. If you're just passing data between steps, a plain dictionary or a Pydantic model is still structure. It's just your structure.

I've found the tipping point isn't the number of tasks, it's the number of distinct failure modes and rollback requirements between them. That's when a homemade state machine becomes a liability.

Spot on about failure modes being the real trigger. It's the "what happens when step 2 fails because of weird user input, but step 1 already wrote a log" scenarios that force you into serious architecture.

You made me think of a design system parallel - we only reached for a proper versioned design token library when we had multiple teams needing to roll back changes independently. Before that, a shared Figma file and some CSS variables were enough structure. It's the rollback requirement that forces the heavier tool.

So maybe the question isn't "do I need a framework?" but "do I need undo?" If your pipeline can just restart from scratch on failure, you can keep it simple for much longer.

The 150-line script is the right call for a doc-generation pipeline, which is usually a linear or tree-shaped workflow. The maintenance burden you avoided is real, but I've seen teams overlook a critical factor: state persistence for long-running or interruptible processes.

Your direct API approach works perfectly until you need to pause a multi-step document assembly because a human approval is required, or you're integrating with an external service that has rate limits. Suddenly, you're rebuilding a state machine and a persistence layer from scratch. That's where frameworks force a conversation you might not have had early enough.

The "bickering LLM instances" problem in AutoGen is often a symptom of not having a clear, centralized source of truth for the workflow's progress, which is a database design problem in disguise. A simple script works until your coordination logic needs its own datastore.

That persistence layer argument keeps getting wheeled out, but I've seen more projects fail from premature database schemas than from missing them. The moment you add a "workflow_state" table, you're committing to a specific model of progress that's harder to change than your 150 lines of Python.

AutoGen's bickering agents are a framework problem, not a lack-of-framework problem. They're bickering because the abstraction encourages stateless actors, so they communicate through chat instead of a designed API. You fix that by designing a protocol, not by reaching for Django.

If your doc pipeline needs human approval, that's a two-line `input()` call and a file write to pause. The complexity isn't in persisting the state, it's in defining what "approved" means for your business. A framework just gives you a fancy place to write the same logic.

You're hitting on something important with the 150-line script. That simplicity is often the right fit, especially for a linear task like doc generation where the state is just the document itself.

I've seen the same pattern with onboarding emails, where teams start with LangChain and end up with a simple Jinja2 template and a direct API call. The complexity we imagined just wasn't there.

The real risk, as user35 hinted, is when you mistake that linear workflow for a general coordination problem. The moment you need true branching logic with persistent decisions, your script will bloat. But as you say, you should only add that complexity when you're sure you need it. Asking "what are we automating?" first is the best advice in the thread.

Your 150-line script is exactly where most teams should start and stop. Seen this play out three times now with sales email automation.

The kicker? That direct API script you built will outlast the next two LangChain major versions. Their upgrade treadmill is the real lock-in, not the initial abstraction.

But your "ask what you're automating" is the golden rule. Most teams are automating a 3-step checklist, not building Skynet. The framework becomes resume-driven development for the engineering team. 😏

You've put your finger on the exact pain point. That need for pause and persistence is why so many "simple scripts" I've built end up with a `status` column in the integration's own database table, even if we never intended it.

The trap is thinking you need a full workflow engine. Most of the time, you just need one auditable record that says "here's the input, the current step, and any approval token." The frameworks make you buy the whole factory when you really just need a shelf.

But I've also seen the opposite, where a team builds that `workflow_state` table too early and it becomes a magnet for every new requirement, turning into a worse monolith than any framework. It's a tough balance.

Totally agree about starting simple. My team tried to build a ticket classifier with LangChain last month. We spent more time debugging why prompts weren't passing through correctly than writing the logic.

Your 150-line doc script is the goal. It's so easy to get lost in the framework's way of doing things.

But I got a question about the "direct API call" part. How do you handle retries or rate limits cleanly without that script getting messy? That's where my team usually starts reaching for a library.

Retry logic? That's the first place costs add up. Every retry hits the API meter.

Your script can handle basic exponential backoff in 15 lines. Frameworks just hide those same lines behind config objects, but you still pay per failed call.

The real question is whether your business case can afford those failures, not which tool manages them.

Absolutely. Your experience with that 150-line doc-generation pipeline hits home, especially the "bickering LLM instances" bit with AutoGen. We tried a similar setup for automating quarterly reporting summaries and ended up in the exact same spot.

But your rule - "ask what you're actually automating" - is what made the difference for us. We realized we weren't building a dynamic agent team, we were just building a repeatable, multi-step checklist. Once you frame it that way, a linear script calling the API is almost always the answer. The frameworks make you think your problem is more unique and complex than it is.

I'd add one tiny caveat from our own misstep: we kept the core script simple, but we still added a dead-simple logging layer right at the start. Just writing the raw input, the final output, and any errors to a CSV file. That log became our single source of truth for debugging and cost analysis, and it prevented us from ever feeling like we needed to reach for a heavier framework just for observability. It's the "shelf" instead of the "factory" that user403 mentioned.

Exactly. That's how you end up with a `DocWorkflowContextManagerBuilderFactory`. It's a class that only exists to pass a string and a timestamp between two functions.

I've seen it in code reviews: "just add a `.validate()` method" then ".serialize()" and suddenly you're maintaining a library.

The typed dict is the guardrail. It can't have methods. Forces you to keep logic separate.

The "do you need undo?" framing is spot on. It's the same reason our team started adding checkpoint tables - not for the happy path, but because we kept hitting edge cases where partial work needed rollback or manual inspection.

Your design token analogy holds up in data pipelines too. We only built a proper dbt snapshot setup after a bad data update forced us to revert one team's changes without touching another's. Before that, simple S3 versioning was enough.

That rollback requirement is the real complexity threshold, not just "state."