El open source ya no es gratis con agentes

Durante años repetimos una frase cómoda: el open source es gratis. Si no pagas licencias, si el código está disponible y si puedes instalarlo tú mismo, el costo parece cero. El problema es que esa cuenta nunca fue completa, y con agentes de IA deja de parecerlo por completo.

Cuando metes agentes en la pila, no solo consumes más cómputo. También multiplicas llamadas a modelos, ejecuciones de herramientas, lecturas y escrituras en bases de datos, tráfico hacia APIs externas, logs, trazas, revisiones humanas y soporte cuando algo falla. Lo que antes era una pieza de software relativamente estable ahora puede convertirse en una máquina de consumo continuo. El open source no dejó de ser valioso; lo que dejó de ser realista es tratarlo como si su costo fuera cero.

La trampa del costo cero

La idea de que el open source es gratis funciona mientras miras solo la licencia. Si el repositorio no cobra, si puedes hacer un fork y si el software corre en tu infraestructura, entonces parece que el gasto se limita al tiempo del equipo. Pero en la práctica siempre pagaste algo: instalación, mantenimiento, seguridad, actualizaciones, observabilidad y reemplazo cuando el proyecto se abandona.

Con agentes, esa factura sube porque el software ya no se usa como una herramienta puntual. Se usa como un sistema que decide, consulta, reintenta, llama a otras herramientas y vuelve a intentar. Un chatbot interno puede hacer una sola petición. Un agente de soporte puede disparar 8, 15 o 30 acciones en una sola interacción, dependiendo del flujo. Si cada paso toca un modelo, una base de datos o una API de terceros, el costo se acumula rápido.

Esto pega más fuerte en equipos que adoptan open source para ahorrar presupuesto inicial. En LatAm, donde muchas empresas cuidan cada dólar o cada peso, la tentación es fuerte: “usemos la versión open source y listo”. El problema es que la economía real del sistema aparece después, cuando ya tienes usuarios, incidentes y expectativas de disponibilidad.

Licencia gratis no significa operación gratis

Hay una diferencia entre no pagar por usar un repositorio y no pagar por operar un sistema. La primera es una decisión legal. La segunda es una realidad técnica y financiera. Si un agente depende de un stack open source autogestionado, tú pagas con infraestructura, tiempo de ingeniería y capacidad de respuesta.

Piensa en un caso simple: un equipo monta un agente interno sobre una base open source, lo conecta a Slack, a su CRM y a una base vectorial. Al principio lo usan 20 personas. Un mes después son 200. Ya no es una demo; ahora hay tickets, permisos, cuotas, errores de integración y preguntas de auditoría. El software sigue siendo open source, pero el costo operativo ya no es cero.

La trampa está en medir solo el costo de entrada. Un proyecto puede parecer barato durante la prueba de concepto y volverse caro cuando el uso crece 10 veces. Eso no es una excepción; es el comportamiento normal de sistemas que automatizan trabajo humano y se conectan a más servicios.

Qué cambia cuando entran agentes

Un agente no es solo una interfaz conversacional. Es un consumidor activo de recursos. A diferencia de una app tradicional, el agente puede ejecutar ciclos de razonamiento, recuperar contexto, invocar herramientas, validar resultados y repetir el proceso. Cada ciclo tiene costo, y muchas veces ese costo es invisible al usuario final.

Además, los agentes introducen una capa de incertidumbre operacional. No siempre hacen lo mismo con la misma entrada. Pueden cambiar de ruta, intentar más pasos de los previstos o chocar con límites de rate limiting. Eso complica el dimensionamiento. Si antes calculabas capacidad por número de usuarios o requests por minuto, ahora también debes considerar número de pasos por tarea, profundidad de razonamiento y frecuencia de reintentos.

En la práctica, el open source en la era agentic no solo compite por precio. Compite por estabilidad, trazabilidad y costo total de propiedad. Si tu equipo no mide esas tres cosas, el ahorro inicial se te puede ir en consumo, incidentes y horas de soporte.

Más herramientas, más puntos de falla

Un agente útil casi nunca vive solo. Se conecta a un LLM, a un buscador interno, a una base de datos, a una cola, a un sistema de tickets, a un CRM o a una API de pagos. Cada integración agrega valor, pero también agrega superficie de falla.

Eso significa más pruebas, más monitoreo y más manejo de permisos. Si una herramienta responde lento, el agente reintenta. Si un permiso está mal configurado, el agente falla en silencio o devuelve una respuesta incompleta. Si el modelo alucina una acción, alguien termina revisando el daño. El costo de soporte sube aunque el código siga siendo libre.

Hay otro detalle: los agentes tienden a producir más ruido operativo que una app tradicional. Generan prompts, respuestas intermedias, decisiones parciales y logs de tool calls. Si no defines bien qué guardar y por cuánto tiempo, terminas pagando almacenamiento y observabilidad por datos que casi nadie revisa, pero que sí debes conservar para investigar incidentes.

El consumo escala por tarea, no por usuario

Este cambio es clave. En software clásico, muchas veces podías estimar el costo por usuario activo. En sistemas con agentes, el costo real se parece más al costo por tarea completada. Un solo usuario puede generar una carga enorme si dispara agentes complejos repetidas veces.

Ejemplo concreto: un equipo de soporte usa un agente open source para resumir casos y proponer respuestas. Si cada ticket requiere 5 llamadas al modelo, 3 consultas a bases internas y 2 verificaciones de políticas, el costo por ticket no es trivial. Multiplica eso por 1.000 tickets al mes y ya no estás hablando de una demo, sino de una línea de gasto constante.

Por eso, cuando evalúas open source con agentes, debes mirar el costo de ejecución, no solo el costo de adquisición. Si no, el ahorro te engaña.

Los costos que casi nadie pone en la hoja de cálculo

La mayoría de los equipos sí calcula infraestructura básica. Pero deja fuera varios costos que aparecen tarde y duelen más. Estos son los más comunes:

• soporte de incidentes fuera de horario
• mantenimiento de dependencias y parches de seguridad
• evaluación de prompts, herramientas y permisos
• observabilidad de trazas, métricas y logs
• revisión humana de decisiones del agente
• control de acceso y auditoría
• migraciones cuando el proyecto upstream cambia o se abandona

A eso súmale el costo de coordinación. Un agente que cruza datos entre sistemas obliga a producto, seguridad, legal y operaciones a hablar más seguido. No siempre es un costo visible en cloud, pero sí es un costo real para el negocio.

La documentación oficial de proyectos como Kubernetes y PostgreSQL deja claro que la operación, el escalado y la administración requieren planificación y recursos, aunque el software sea libre. Puedes revisar, por ejemplo, la documentación de Kubernetes en https://kubernetes.io/docs/home/ y la de PostgreSQL en https://www.postgresql.org/docs/ para ver que el mantenimiento no desaparece por no pagar licencia.

Un ejemplo de costo total más realista

Imagina que montas un agente para atención interna con componentes open source. El stack corre en tus servidores o en cloud, y el equipo cree que el ahorro viene de evitar licencias propietarias. A la tercera semana, ya tienes estas líneas de gasto:

La cifra cambia según tu contexto, pero la lógica no: el costo no está en la licencia, está en la operación. Si el agente ahorra 40 horas de trabajo humano al mes, bien. Si solo ahorra 10 y te cuesta 1.700 dólares sostenerlo, ya no es una ganga.

Cómo evaluar open source con agentes sin autoengañarte

La forma correcta de mirar esto no es preguntar si el software cuesta cero, sino si el costo total de operar el sistema es razonable para el valor que entrega. Eso obliga a cambiar la conversación dentro del equipo.

Primero, separa el costo de experimentar del costo de escalar. Un piloto con 10 usuarios puede vivir con más fricción. Un sistema de producción con 5.000 usuarios no. Si no haces esa distinción, terminas justificando decisiones de producción con números de prueba de concepto.

Segundo, define métricas operativas antes de poner agentes en manos de usuarios reales. No basta con medir precisión o satisfacción. También debes medir número de tool calls por tarea, tasa de reintento, tiempo promedio de ejecución, costo por tarea y porcentaje de casos que requieren intervención humana.

Tercero, piensa en el equipo que va a sostener el sistema. El open source no elimina la necesidad de expertise. La cambia de lugar. En vez de pagar licencias, pagas con personas que sepan operar, observar, parchear y depurar el sistema cuando el agente haga algo raro.

Qué medir desde el día uno

Si vas a desplegar agentes sobre open source, estas métricas te ayudan a evitar sorpresas:

1. costo por tarea completada, no solo por request
2. número promedio de pasos por interacción
3. tasa de fallas por integración externa
4. porcentaje de respuestas que necesitan revisión humana
5. tiempo medio para detectar y corregir un incidente
6. consumo mensual de cómputo, storage y observabilidad

Con esas métricas puedes comparar alternativas de forma más honesta. Tal vez un stack open source te sale mejor que una solución cerrada. O tal vez no. Lo importante es que la decisión salga de datos y no de una idea romántica de gratuidad.

Cuándo sí conviene open source

Sí conviene cuando necesitas control, portabilidad y posibilidad de adaptar el sistema a tu negocio. También cuando tienes talento interno para operarlo y cuando el volumen todavía permite absorber el costo de mantenimiento. En algunos casos, open source te da más margen para experimentar sin quedar atado a una sola plataforma.

Pero conviene menos cuando tu equipo es pequeño, tu tolerancia a incidentes es baja o el agente va a tocar procesos críticos. Ahí el ahorro de licencia puede ser pequeño frente al costo de soporte y al riesgo de una mala decisión automatizada.

Riesgo operativo y deuda técnica en la era agentic

El riesgo no es solo que el agente falle. El riesgo es que falle de forma silenciosa, que degrade la experiencia o que haga algo costoso antes de que alguien lo note. En sistemas tradicionales, un bug suele romper una ruta. En agentes, un bug puede disparar una secuencia de acciones incorrectas y dejar rastros difíciles de entender.

Eso obliga a reforzar controles. Necesitas límites de ejecución, permisos mínimos, validación de salida, observabilidad y, en muchos casos, aprobación humana en pasos críticos. Todo eso suma costo. Y si no lo sumas, la deuda técnica aparece como incidentes, no como líneas contables.

También hay un tema de dependencia upstream. Muchos proyectos open source avanzan rápido, cambian APIs o descontinúan módulos. Si tu agente depende de una librería que cambia cada mes, el costo de mantener compatibilidad puede subir más rápido que el valor que entrega el sistema. No es un problema teórico; es el tipo de desgaste que termina ocupando sprints enteros.

A nivel de producto, esto cambia la conversación con negocio. Ya no basta con decir “es open source y no pagamos licencia”. Tienes que explicar cuánto cuesta cada tarea, qué riesgos asumimos y qué controles aplicamos. Si no puedes responder eso, probablemente todavía no entiendes el costo real.

Tabla resumen

Si quieres tomar una decisión más seria, piensa en open source como una base de capacidad, no como una promesa de ahorro infinito. En la era de los agentes, el valor sigue ahí, pero la factura también. La diferencia entre un buen negocio y un dolor operativo está en cuánto miras más allá del repositorio.