Agent demos are easy. An agent that reliably completes a multi-step workflow on a client's real data, on a schedule, without a human watching, is a different problem entirely. This is a collection of the failure modes that showed up repeatedly while building agentic systems with LangGraph and CrewAI to automate SaaS client workflows.

The gap between "works" and "works unattended"

A demo succeeds once. A production agent needs to succeed the overwhelming majority of the time, and fail legibly the rest of the time. The single highest-leverage change across every one of these projects was adding structured intermediate state — writing down what the agent decided and why at each step — rather than letting the whole run live inside a single opaque chain of tool calls. When something goes wrong three weeks later, that log is the difference between a five-minute fix and starting from scratch.

Where LangGraph earns its complexity

LangGraph's explicit graph structure feels like overhead compared to a simple loop, right up until a workflow needs conditional branching, retries with backoff, or a human-in-the-loop checkpoint. For anything past "call three tools in sequence," the graph structure pays for itself, because it makes the control flow inspectable instead of implicit in prompt text.

The place this framework earns its keep most clearly is state persistence across long-running workflows — checkpointing agent state so a multi-hour or multi-day process can resume after an interruption rather than restarting from the beginning.

Where CrewAI earns its keep

CrewAI's role-based abstraction — defining agents by role, goal, and backstory, then letting a process orchestrate handoffs between them — matches a specific class of problem well: workflows that mirror how a small human team would actually divide the work. Content pipelines, research-then-synthesis tasks, and QA-review loops all map naturally onto that structure. It's a worse fit for tightly coupled, single-decision-at-a-time workflows, where the role abstraction adds ceremony without adding clarity.

The reliability tax

Every agentic workflow that moved from prototype to production paid a "reliability tax" that isn't visible in a demo:

  • Tool-call validation. Never trust that a model-generated tool call has valid arguments. Validate and retry with corrective feedback before it ever executes against production data.
  • Idempotency. Any step with a side effect — sending an email, writing to a database, calling an external API — needs to be safe to retry, because retries are not optional at scale.
  • Cost ceilings. An agent stuck in a reasoning loop will happily burn tokens indefinitely unless something outside the agent enforces a hard budget.
  • Escalation paths. The system needs a defined "I don't know, ask a human" exit, and it needs to actually take that exit instead of guessing when confidence is low.

None of this is exotic engineering. It's the same discipline that any unattended production system needs — the agent framework doesn't remove the need for it, it just changes where the discipline has to be applied.

What this bought

Across these client engagements, the net effect of applying that discipline was roughly a 50% reduction in manual effort on the automated workflows, with the largest wins coming from routine multi-step SaaS tasks that previously required a person to babysit every step. The gains came less from the agent being clever and more from the surrounding system being boring, observable, and safe to retry.