Dejé de perseguir el hype de agentes IA y armé uno que solo hace lo que necesito

Si buscas "AI agents" hoy te encuentras con n8n, LangChain, AutoGPT, CrewAI, MCP, RAG, embeddings, vector DBs... y en algún punto la pregunta deja de ser "¿qué necesito resolver?" y pasa a ser "¿qué herramienta se supone que debo usar?". Ese ecosistema desborda, y no es casualidad: la mayoría del contenido está escrito por gente vendiendo la herramienta, no resolviendo un problema real.

Yo tenía un problema concreto: reviso a diario bases de datos MongoDB de mis sistemas, correos de Gmail y mensajes de WhatsApp, y quería cruzar esa información (más alertas de sismos, porque vivo en zona sísmica) sin escribir un dashboard nuevo cada vez que necesitaba una vista distinta. Esto es cómo lo resolví, sin n8n, sin frameworks pesados.

El problema real detrás del hype

n8n y herramientas similares son excelentes para flujos deterministas: "si llega un webhook, transforma el JSON, escribe en la DB". Pero mi caso no era eso. Necesitaba algo que pudiera:

• Consultar mongosh con una pregunta en lenguaje natural ("¿cuántas facturas sin pagar tiene el cliente X este mes?")
• Cruzar esa respuesta con correos recientes de Gmail
• Revisar si hay mensajes de WhatsApp relacionados
• Generar un reporte, sin que yo programe cada reporte nuevo a mano

Eso no es un flujo fijo de nodos. Es una tarea con estado y contexto, donde la forma de resolverla cambia según la pregunta. Ahí es donde n8n se queda corto y donde entra un agente real.

Lo que armé: Hermes

Hermes es un agente que corre en mi EC2, con:

• WhatsApp vía Baileys, en modo self (solo responde a mi número)
• Gmail vía OAuth
• MongoDB vía herramientas MCP (consulta directa a mis colecciones)
• Modelo deepseek-v4-flash vía OpenRouter (barato, suficiente para este caso de uso)
• Dashboard simple en un puerto local para monitoreo
• Corre en tmux, dos procesos: el agente y su gateway

La decisión de arquitectura que realmente importa

Aquí está el punto que casi nadie menciona cuando habla de agentes: el problema no es conectar herramientas, es que el agente no alucine ni divague. Y eso no se resuelve con más modelo o más contexto. Se resuelve con disciplina de diseño:

1. Contratos de entrada/salida estrictos

Cada herramienta que el agente puede usar (consultar Mongo, leer Gmail, mandar WhatsApp) tiene un contrato explícito: qué entra, qué sale, en qué formato. Nada de "el modelo decide el formato de la respuesta". Si le pido un reporte de facturación, el agente sabe exactamente qué estructura debe devolver, porque se la definí de antemano.

2. Catálogo de herramientas curado, no exhaustivo

No le di acceso a "todo MongoDB" ni "todo Gmail". Le di un catálogo pequeño y específico de operaciones que sé que necesito repetir. Menos opciones = menos espacio para que el modelo se equivoque eligiendo la herramienta incorrecta.

3. Prompts guardados, no reinventados cada vez

En vez de escribir un prompt nuevo cada vez que quiero un reporte, tengo prompts almacenados que Hermes reutiliza y ajusta según el contexto del día. Es la diferencia entre "programar una función" y "documentar una intención una sola vez".

Resultado práctico

Sin escribir un dashboard, sin definir flujos en n8n, sin mantener código de integración por cada fuente de datos, tengo reportes que cruzan MongoDB + Gmail + WhatsApp + alertas sísmicas, generados solo con prompts que ya viven en el sistema. Cuando necesito una vista nueva, ajusto un prompt, no escribo código.

Si estás empezando y te sientes desbordado por el ecosistema

Mi recomendación, después de pasar por esto:

1. No empieces por la herramienta. Empieza por la pregunta: ¿es un flujo fijo y determinista (n8n gana) o necesita razonar con contexto cambiante (agente real gana)?
2. No le des a tu agente acceso "a todo". Un catálogo pequeño de herramientas bien definidas vale más que una integración total con IAM abierto.
3. Diseña el contrato antes que el prompt. Si no sabes qué formato de salida esperas, el modelo tampoco lo va a saber.
4. Guarda tus prompts como si fueran código. Versiónalos, ajústalos, no los reescribas cada vez desde cero.

No hace falta entender todo LangChain ni memorizar los quince frameworks de moda para tener un agente útil. Hace falta resolver un problema concreto con las piezas mínimas necesarias.

---

¿Están resolviendo algo parecido con agentes propios en vez de plataformas low-code? Me interesa comparar enfoques.