Twelve months ago we picked LangGraph as the spine of the Apragya agent runtime. The choice was load-bearing: it shaped how we model state, how we recover from worker crashes, how we attribute cost per node. With another year of production traffic behind us, here's what held up and where we'd take a different swing.
What worked: explicit state, branching, and checkpoints
The graph model forced us to name every node, every transition, and every checkpoint. That sounds bureaucratic until a customer-facing agent fails halfway through a 14-step approval workflow. Because the graph knew exactly where it was and what it had read so far, we could resume from the failing edge with the same input - not from scratch. Nine months later that single property is responsible for ~96% of our "agent finished even though something blew up mid-run" success rate.
What we'd do differently: control plane vs. data plane
We let the graph carry too much business data through its state object. As tenants scaled past 10k runs/day, the state blobs ballooned and Redis became the bottleneck. The fix - in progress now - is to keep only routing + checkpoint metadata in the graph and store the real payloads in tenant-scoped object storage referenced by id.
- Keep graph state small - pointers, not payloads.
- Decouple per-node cost attribution from the in-graph state so reporting queries don't fight the runtime.
- Pin every checkpoint to a tenant-scoped row in postgres for hard auditability, not just a redis blob.
A graph runtime makes the easy stuff trivial and the hard stuff legible. The trick is not letting it become a database.
What's next
Next quarter we ship a control-plane / data-plane split, swap our checkpoint store for postgres+S3, and open-source the per-tenant cost meter that drives our AIU dashboard. If you're running agents in production and have an opinion about any of this, we'd love to compare notes - we read every reply to our weekly post-mortem thread.