deepagents vs labs-OO-Agents
LangChain's batteries-included agent harness on LangGraph — planning, sub-agents with isolated context, filesystem, shell, skills, human-in-the-loop and persistent memory out of the box. — versus — NVIDIA's object-oriented agent framework: an agent is a Python class — fields are state, docstrings are prompts, and a `...` method body becomes an LLM loop that acts by writing Python.
Both are 'write an agent in Python' frameworks with opposite ergonomics: deepagents is batteries-included on LangGraph, labs-oo-agents makes the class itself the agent â fields are state, docstrings are prompts.
| deepagents | labs-OO-Agents | |
|---|---|---|
| Stars | 30k | 2.2k |
| Forks | 4.1k | 295 |
| Language | Python | Python |
| License | MIT | NOASSERTION |
| Last activity | 2 days ago | 2 days ago |
| Topics | agents, orchestration | agents, orchestration |
| Curated connections | 12 | 4 |
deepagents — the curator's take
The fastest route to a serious long-horizon agent if you accept LangChain's stack: planning, sub-agents, context offloading and HITL gates work out of the box, and any LangGraph graph plugs in as a sub-agent, so custom orchestration composes instead of forking. NOT for simple tool-calling loops — LangChain's create_agent is lighter — and the opinions run deep: if you're fighting the harness, you wanted LangGraph directly. Model-agnostic in theory; tuned around frontier tool-callers in practice.
labs-OO-Agents — the curator's take
The bet is that agent code should be ordinary code: no prompt registry, no hand-written tool schemas, no graph DSL — one class you subclass, type-check, trace and refactor like the rest of the repo. The `...` body is the whole trick: leave a method unimplemented and the runtime hands it to an LLM that acts by writing Python in a REPL with `self` in scope, so composition and state sharing are just attribute access, and methods with type annotations are already callable tools. Use it if your team thinks in typed Python and wants agents to survive a refactor. NOT the pick if you want a visual builder, a managed runtime or a big integration catalogue — it is a library with a paper behind it, and the CLI, ACP, memory and bench pieces are separate distributions.