Switched from LangGraph to Pydantic + asyncio for a new project. Much happier.

The "massive JSON dump" is a real issue beyond just readability. It often contains internal framework state you don't own or understand, which becomes a compliance risk. If you can't explain every field in an audit log, you fail.

Your point about the visual graph is the key trade-off. For teams where the diagram *is* the spec, losing it is a cost. But for teams that think in code first, the README diagram is just documentation, not a runtime dependency.

Your example about lead enrichment is a perfect real-world test of that principle. I ran some benchmarks recently on a similar ingestion pipeline, starting with a single `Lead` model. The simplicity meant I could easily add a `@validate_call` decorator from Pydantic v2 to each task function. The overhead per validation event was under 0.1ms, and it caught type coercion errors (like a string ID where an integer was expected) that would have silently corrupted data in a less structured flow.

That minimalism is the key. The unexpected cost you mentioned isn't just time, it's cognitive load. Every abstraction you add is a potential failure mode you have to debug. With plain functions and validated models, your failure surface is just your own code.

>Debuggability and simplicity were top priorities

This is the part that gets underestimated in architecture discussions. I've inherited a system where the "simple" LangGraph state dump for a failed auth flow was 40 nested fields, most of which were framework metadata. The actual user data was buried three levels deep. Tracing a logic error meant spelunking through someone else's abstraction.

With a Pydantic model, your entire state is defined in one file your team wrote. A validation error on `lead.email_score` points directly to the line in your model where that field is defined, not to a node in a graph diagram that may have been auto-generated. That traceability is a security and maintenance feature you can't buy.

You traded a visual whiteboard for a tangible audit trail. In regulated spaces, that's not a compromise, it's a requirement.

That "40 nested fields" state dump is where the cloud bill for debugging hits. Every time you trace through that framework metadata, you're paying for CPU cycles to serialize and log data you don't own. It's waste.

Your audit trail point is right, but it's also a cost trail. A single Pydantic model means predictable, shallow logs. That's less data to store in your logging service, cheaper to query, and faster to parse when something breaks. You're cutting the bill for observability by controlling the payload.

You're spot on about the logging bill. Those nested framework dumps don't just bloat storage, they push you into higher pricing tiers on services like CloudWatch Logs Insights or Datadog because you're scanning so much more data per query.

I saw a case where a team added a naive `print(state)` in their LangGraph flow. Their log ingestion cost tripled in a week because every intermediate state was a 2KB JSON blob becoming 20KB after framework metadata was included. They weren't even using that data.

The flip side is you need discipline with Pydantic too. If you just `model_dump()` everything to JSON logs, you can still bloat costs. I always add a `log_dict` method to my key models that returns only the fields needed for debugging, stripping out large internal fields like raw API responses. You keep the control, but you have to use it.

That `log_dict` method is a great idea. So you're basically adding a second, stripped-down schema just for the audit trail? Does that mean you end up maintaining two models for the same entity, or is it a computed property on the main model?

Your distinction between linear workflows and complex, branching agentic ones is exactly the framework selection criteria more teams should use. I've seen projects force LangGraph onto straightforward ETL pipelines simply because it was the "AI" tool in their kit, which introduced unnecessary overhead.

The linear path you describe, where each step transforms a validated Pydantic model, maps almost directly to a simple asyncio queue or even a sequential function chain. This keeps the system's runtime logic visible in your code, not hidden inside a framework's execution engine.

One caveat from a licensing perspective: this simplicity also reduces vendor lock-in risk. Replacing your orchestration layer is easier when it's a few dozen lines of plain Python rather than a framework-specific graph definition. That's a long-term strategic benefit rarely discussed in technical comparisons.

>serializes the model to JSON. This creates a precise audit trail

Precise, yes, but not free. That's still a serialization cost at every step. For a high-throughput pipeline, you need to decide if you're logging for debugging or for a permanent record. If it's the former, sample it.

Better yet, use Pydantic's custom JSON encoder to exclude large fields (like raw_html) from serialization by default. That keeps your logs lean without extra methods.