Este post es para CTOs e ingenieros que están evaluando “cómo construir un agente que aguante producción”. Sin marketing, sin “trust us”, con nombres concretos.
Layers
Pienso el stack en cinco capas:
- Modelos — qué LLM(s) y modelos auxiliares corren
- Memoria — vector DB, RAG, caching
- Orquestación — máquinas de estado, flujos durables
- Observabilidad — trazas, costos, evals
- Infraestructura — dónde corre todo
1. Modelos
Combinamos:
- Un modelo grande para razonamiento general: Claude Sonnet por defecto. Algunos casos usan GPT-5 o Gemini. La decisión depende de pricing por caso de uso, latencia tolerable y compliance del cliente.
- Modelos pequeños fine-tuneados para tareas específicas: clasificación de intención, extracción de entidades, scoring. Típicamente Llama-3-8B o Qwen-2.5-7B fine-tuneados en datos del cliente, corriendo en GPU local.
- Embeddings: Cohere Embed cuando latencia tolera red externa, modelos locales (E5, BGE-M3) cuando importa.
El punto: no usar un modelo grande para todo. Es lento y caro. Routing inteligente entre modelos por tarea baja el costo entre 5-10x.
2. Memoria
- Vector DB: pgvector cuando ya hay Postgres en el stack del cliente. Weaviate o Qdrant cuando el volumen lo exige (decenas de millones de vectores). Evitamos Pinecone por costo en escala.
- RAG: chunking semántico (no fijo), hybrid search (vector + BM25), reranking con cohere-rerank o un modelo local. La diferencia entre RAG malo y bueno está casi siempre en el reranker.
- Caching: Redis para respuestas frecuentes idénticas. LRU para contextos costosos de regenerar.
3. Orquestación
- LangGraph para máquinas de estado conversacional. Cuando el agente tiene >5 estados y necesita backtracking, valen los millones.
- Temporal para flujos durables. Generar un PDF + enviar por WhatsApp + actualizar SAP + esperar confirmación humana es un workflow durable, no una request HTTP.
- Inngest o BullMQ para colas de tareas asíncronas más simples.
Lo que NO usamos: LangChain como capa de abstracción para todo. Lo usamos puntualmente para algunos componentes, no como spine del sistema.
4. Observabilidad
Tres ejes:
- Trazas: Langfuse self-hosted. Cada conversación queda con su árbol de llamadas, prompts, costos, latencias.
- Costos: dashboards con costo por conversación, por modelo, por feature. Sin esto, los costos de LLM explotan sin avisar.
- Evals: corremos suite de evaluación automática sobre cada deploy. Si un cambio degrada accuracy en >2% en cualquier categoría, el deploy se bloquea.
5. Infraestructura
- Tier 1 (cliente regulado): nuestro datacenter en Colombia con GPU dedicadas de IA. Inferencia y RAG en suelo nacional.
- Tier 2 (cliente comercial): Vercel/Cloudflare en edge + APIs de modelos en cloud público.
- Tier 3 (workloads pesadas): GPUs dedicadas (nuestras o del cliente) para fine-tuning y evaluación batch.
El patrón meta
El error más común que vemos cuando equipos arrancan con agentes:
- Eligen un framework grande (LangChain, LlamaIndex, etc.).
- Construyen sobre él.
- Llegan a producción.
- Encuentran que el framework no maneja bien sus casos edge.
- Pelean contra el framework durante meses.
Nuestra heurística: usar pequeñas piezas componibles en lugar de un framework grande. SDK del modelo + librería de vector DB + librería de orquestación + librería de observabilidad. Cuatro dependencias chicas en lugar de una grande que pretenda hacerlo todo.
Lo que no se ve
El 70% del trabajo en un agente en producción no es código del agente — es:
- Limpiar la data de RAG (que viene de PDFs viejos, sistemas legacy, Word desorganizado).
- Construir el set de evals con casos reales.
- Definir el flujo de escalado a humano (cuándo, con qué contexto, hacia quién).
- Iterar prompts con métricas, no con feeling.
Si arrancas un proyecto y el equipo dice “5 semanas, sale”, probablemente está subestimando el 70% invisible.
¿Querés profundizar?
Si tu equipo está armando un agente y querés sparring técnico, hablemos 30 minutos. Sin slides, sin discovery genérico — código real, problemas reales.