DSPy vs labs-OO-Agents
Program — don't prompt — your language models. Compile declarative pipelines into optimized prompts. — 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 refuse hand-written prompt strings, then diverge. DSPy treats the prompt as a compiled artifact optimized against a metric; NOOA treats it as the docstring and the type signature and optimizes nothing — declarative in structure, not in tuning.
| DSPy | labs-OO-Agents | |
|---|---|---|
| Stars | 38k | 1.9k |
| Forks | 3.3k | 259 |
| Language | Python | Python |
| License | MIT | NOASSERTION |
| Last activity | 3 days ago | today |
| Topics | orchestration, rag | agents, orchestration |
| Curated connections | 2 | 3 |
DSPy — the curator's take
Program — don't prompt — your language models. Compile declarative pipelines into optimized prompts.
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.