Is agentlib trying to replace LangChain?

No. LangChain's center of gravity is retrieval and chains. agentlib's is the agent loop and mobile-native execution. If you need both, use LangChain for retrieval and agentlib for the mobile agent on top — they don't compete on the same axis.

Yes, but you bring the retriever. The pattern is: register a 'search' tool in /bin that hits your vector store; the agent calls it like any other tool. agentlib doesn't ship vector-store integrations because the right one is too project-specific to commit to one.

compare · vs LangChain

agentlib vs LangChain — agent SDK vs pipeline framework

Side-by-side: agentlib (mobile-native agent SDK) vs LangChain (Python/JS retrieval + chains, with agent primitives). Different centers of gravity.

LangChain is the framework most people first hear about. agentlib serves a different need. The honest comparison is: they’re solving different problems.

What each framework optimises for

LangChain optimises for:

Retrieval + transformation pipelines.
A broad ecosystem of pre-built integrations (vector stores, document loaders, output parsers, evaluators).
Mixed-mode workflows where retrieval and generation are interleaved.
Python and JavaScript backend deployment.

agentlib optimises for:

The agent loop itself — streaming, tool calling, hooks, snapshots, subagents.
Mobile-native execution — pure Dart, on-device models, lifecycle awareness.
Sandbox-safe Unix-shaped tool surface (Sh).
A small, stable API surface.

Different centers of gravity

LangChain started as a chain framework — connect a retriever to an LLM call to an output parser. Agent primitives grew on top of that. The result is a framework that’s powerful for pipelines but, by its own evolution, broad rather than deep on agent primitives.

agentlib started as an agent SDK targeting Flutter. It has the primitives the modern agent ecosystem has converged on — subagents, skills, snapshots, hooks, handoffs, MCP — and doesn’t try to also be a retrieval framework.

When LangChain wins

Heavy RAG. Hundreds of documents, custom chunking, ranker stacks, evaluator passes. LangChain is built for it.
Massive integration breadth. If you need that one specific document loader for an obscure file format, LangChain probably has it.
You’re already on LangChain. The cost of switching is high. If it works, keep going.

When agentlib wins

Mobile apps. LangChain doesn’t ship into a Flutter binary.
On-device models. LangChain has no concept of routing between local and cloud providers.
Lifecycle. Mobile-specific hooks (suspend, low battery, network change) don’t exist in LangChain.
Sandbox safety. No exec, no shell escape — agentlib’s Sh is in-process by design.

Combining them

If you have a LangChain RAG pipeline on the backend and a Flutter app on the front, agentlib in the app calls into the LangChain service like any other HTTP tool. The retrieval lives where it’s best supported; the device-side agent lives where it has to.

Bottom line

LangChain is great at retrieval-driven workflows in Python or JS. agentlib is great at mobile-native agent loops in Dart. They solve different problems. Pick by which problem you have — and don’t be afraid to use both.

Pick agentlib if…

Your agent runs inside a Flutter, iOS, or Android app.
You need on-device models or strict mobile lifecycle handling.
You want a focused agent SDK rather than a broad pipeline framework.
You need a stable API surface (LangChain has churned multiple times).

Pick LangChain if…

Your primary task is retrieval + transformation pipelines over a custom corpus.
You need a wide ecosystem of integrations out of the box.
You're already invested in LangChain and the LCEL graph language.
You want a Python or JS framework with a large community and lots of examples.

FAQ

Is agentlib trying to replace LangChain?: No. LangChain's center of gravity is retrieval and chains. agentlib's is the agent loop and mobile-native execution. If you need both, use LangChain for retrieval and agentlib for the mobile agent on top — they don't compete on the same axis.
Can agentlib do RAG?: Yes, but you bring the retriever. The pattern is: register a 'search' tool in /bin that hits your vector store; the agent calls it like any other tool. agentlib doesn't ship vector-store integrations because the right one is too project-specific to commit to one.