Tuve que elegir un framework de agentes para mis proyectos Python. No para experimentar — para producción real, donde los tokens cuestan plata y el código lo tengo que mantener yo solo.
Esto es lo que encontré.
Las opciones que evalué
- PydanticAI v1 — del equipo de Pydantic, sale en diciembre 2024
- LangChain / LangGraph — el “estándar de facto” según Twitter
- smolagents (HuggingFace) — minimal, código-primero
- OpenAI SDK directo — sin abstracción, máximo control
No hice un benchmark de laboratorio. Porté el mismo agente a cada opción y medí lo que importa: latencia P95, tokens consumidos, y líneas de código para leer en un code review.
Por qué LangChain perdió
LangChain tiene un problema de capas. Cada operación pasa por cadenas de abstracciones que añaden overhead aunque no lo pidas.
Los números de mi benchmark:
| Métrica | LangChain | PydanticAI |
|---|---|---|
| Overhead por tool call | +10–30ms | ~0ms |
| Tokens “fantasma” por llamada | ~2,400 | 0 |
| LOC agente equivalente | ~280 | ~160 |
Los “tokens fantasma” son el problema más silencioso. LangChain inyecta contexto interno en cada llamada — historial de cadena, metadatos de tools, trazas — que el LLM procesa pero que tú no pediste. A escala, eso se nota en la factura.
LangGraph es diferente: es un grafo de estado explícito, bien diseñado para flujos multi-paso con intervención humana. Pero para el caso común — agente que llama tools y devuelve resultado — es sobrediseño.
Por qué PydanticAI ganó
Una línea lo resume: es FastAPI pero para LLMs.
Si ya usas FastAPI + Pydantic v2 en tu backend (yo sí), PydanticAI no te pide que aprendas otro modelo mental. Los agentes se definen con decoradores, las tools son funciones tipadas, las respuestas son modelos Pydantic. El mismo vocabulario.
from pydantic_ai import Agent
from pydantic import BaseModel
class Resultado(BaseModel):
respuesta: str
confianza: float
agente = Agent(
'openai:gpt-4o-mini',
result_type=Resultado,
system_prompt='Eres un asistente de análisis de datos.',
)
resultado = await agente.run('¿Cuál es la tendencia principal?')
print(resultado.data.confianza) # typed, no dict soupNo hay magia. El output es un objeto Python real, validado por Pydantic en el momento que llega del modelo.
Números finales:
- Latencia P95: −44% vs LangChain en el mismo agente
- Consumo de tokens: 2.7× menos por llamada
- LOC: ~160 vs ~280 (40% menos código para mantener)
La excepción: LangGraph sigue en un caso
Tengo un flujo con aprobación humana en el medio — el agente llega a un punto de decisión, pausa, espera input del usuario, y continúa. Ese patrón es exactamente para lo que LangGraph fue diseñado: estado persistente entre pasos, branches condicionales, HITL explícito.
Para ese caso específico, LangGraph es la herramienta correcta. No lo saqué del stack, lo dejé donde tiene sentido.
La regla que uso: si el flujo necesita interrupt() o un estado que persiste entre sesiones de usuario, LangGraph. Para todo lo demás, PydanticAI.
Lo que aprendí
El error que veo seguido: elegir el framework más popular en lugar del que alinea con el stack que ya tienes.
PydanticAI no ganó porque sea “mejor” en abstracto. Ganó porque mi stack ya es FastAPI + Pydantic + PostgreSQL + Python 3.12. Meter LangChain hubiera sido traer un segundo modelo mental al codebase — más superficie de error, más onboarding, más deuda cognitiva.
Cuando evalúes un framework, la pregunta no es “¿cuál tiene más stars?” sino “¿cuál habla el mismo idioma que el resto de mi código?”
Decisión tomada en mayo 2026. Stack en uso activo. Si cambia algo relevante, actualizo el post.