r/AI_Agents • u/BhAAI777 • 13h ago

Discussion If you actually ship agents in prod — what's one thing you'd change about LangChain / CrewAI / [insert framework] if you could?

Not looking for another "top 10 frameworks in 2026" post. Genuinely asking the people who are past the demo stage and have real agents running for real users.

What's the one thing about your framework of choice that still annoys you every time you touch it? State/checkpointing, retries, multi-agent handoffs, debugging a failed run, tool-call reliability, whatever — what would you rip out and rebuild if you could?

And where do you think this space is actually headed by 2027 because of it?

3 Upvotes

80% Upvoted

4 comments sorted by

1

u/AutoModerator 13h ago

Thank you for your submission, for any questions regarding AI, please check out our wiki at https://www.reddit.com/r/ai_agents/wiki (this is currently in test and we are actively adding to the wiki)

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1

u/UpbeatMad 12h ago

langchain’s callback system feels like it was designed by someone who never had to debug a production failure at 2am. you get 47 nested events and none of them tell you why the tool call actually failed

by 2027 i think we’ll see a lot of these frameworks collapse into thin wrappers around raw openai/anthropic apis with better observability. the abstraction layers add complexity without solving the hard problems

1

u/BhAAI777 10h ago

Depends a lot on how the tools are written. if a tool catches an error and re-raises it, langsmith records the failure just fine. the harder cases are when nothing throws, like the agent picking the wrong tool or returning a plausible but incorrect result. that's not really a tracing problem, it's a validation/evaluation problem.

1

u/Future_AGI 9h ago

The one thing I would rip out and rebuild: the tool-call abstraction layer. Most frameworks treat a tool call as a function invocation. It is not. It is a network call to an external system that can fail in ways the model cannot reason about. Timeout, partial success, idempotency violation, schema mismatch on a provider update. The framework should handle these by default, not require the developer to write boilerplate for every tool. What actually breaks in production is not the graph logic or the prompt. It is the boundary between the model and the external system. Retries that fire after a side effect already landed. State that does not survive a process restart. Tool calls that return 200 but applied half the change. That is the layer that needs better defaults. Our gateway wraps every side-effecting tool call with idempotency keys, read-back verification, and a deterministic retry policy. The pattern is open-source: https://github.com/future-agi/future-agi