Construir vs comprar 2.0 — El mercado se divide en dos
Construir vs comprar 2.0 — El mercado se divide en dos, y usted necesita elegir un lado
Tiempo estimado de lectura: 7 min
Hace seis meses, Publigent publicó un marco de decisión para equipos que eligen entre frameworks de agentes de código abierto y plataformas gestionadas. La conclusión fue honesta: no hay una respuesta universalmente correcta, pero sí hay un proceso correcto. Elija basándose en dónde está y dónde necesita estar en un año, y planifique la migración que probablemente hará de todos modos.
Los seis meses transcurridos han producido una imagen más clara de lo que el marco podía ofrecer. El mercado no está convergiendo en un modelo. Se está bifurcando. Los adoptantes tempranos que comenzaron en plataformas gestionadas están migrando a frameworks de código abierto. Los adoptantes tardíos, los equipos que recién comienzan su viaje con agentes, están comprando plataformas gestionadas. Ambos movimientos son racionales. Ambos tienen implicaciones sobre hacia dónde va el mercado.
La bifurcación, en números
El patrón es lo suficientemente consistente como para enunciarlo como regla general. Las organizaciones que desplegaron su primer agente antes de mediados de 2025 están, en general, migrando fuera de las plataformas gestionadas. Alcanzaron los límites de la plataforma (techos de personalización, costo a escala, preocupaciones de dependencia del proveedor) y están reconstruyendo sobre frameworks de código abierto. Los equipos que comenzaron a desplegar en 2026 están eligiendo plataformas gestionadas. Vieron a los adoptantes tempranos luchar, quieren el camino pavimentado y tienen menos tolerancia a la sobrecarga de ingeniería.
La dinámica de construir versus comprar cambió en una dirección inesperada, como señalamos en la Revisión de Mitad de Año. Los adoptantes tempranos que compraron plataformas gestionadas están migrando a frameworks de código abierto. Los adoptantes posteriores están haciendo lo contrario. Los equipos experimentados que saben lo que necesitan están construyendo su propia infraestructura. Los equipos sin experiencia que quieren comenzar rápido están comprando plataformas. Ningún camino es incorrecto. Pero la idea de que el mercado convergería en un modelo estaba equivocada.
Por qué los adoptantes tempranos se van
La migración de gestionado a código abierto sigue un arco consistente. Un equipo necesita un agente funcional rápidamente. Eligen una plataforma gestionada (Dify, Flowise, LangGraph Cloud, n8n) y tienen algo funcionando en dos semanas. Las partes interesadas están contentas. Luego los requisitos crecen.
El techo de personalización es el primer muro que golpean. El agente necesita una integración personalizada que la plataforma no soporta. Un protocolo de transferencia no estándar. Un flujo de autenticación específico. Una estrategia de retención de memoria que no coincide con los valores predeterminados de la plataforma. Al principio, los equipos lo resuelven con soluciones alternativas. Añaden una capa de middleware. Improvisan un script que cierra la brecha. Luego las soluciones se acumulan, y la plataforma que se suponía ahorraría tiempo de ingeniería termina consumiéndolo.
La curva de costos se invierte a escala media. El precio por agente o por ejecución que tenía sentido con 5 agentes se vuelve insostenible con 50. Un equipo con el que hablé reportó que su factura de LangGraph Cloud superó los $4,000/mes con aproximadamente 15,000 ejecuciones por mes. En ese punto, el costo de construir y mantener su propia infraestructura (un pequeño clúster de Kubernetes, un orquestador de código abierto, un almacén vectorial autoalojado) era menor que la tarifa de la plataforma. El punto de cruce varía según la plataforma y el caso de uso, pero típicamente se sitúa entre 50-100 agentes o 10,000-15,000 ejecuciones por mes. Por debajo de ese umbral, lo gestionado es más barato. Por encima, los números se invierten.
La dependencia del proveedor se convierte en un problema concreto en lugar de uno teórico. Un cambio de precios, una deprecación o un giro en la dirección del producto pueden romper el modelo operativo que construyó alrededor de la plataforma. Los equipos de plataforma tienen incentivos diferentes a los de su equipo. Optimizan para su resultado final, no para su arquitectura. Cuando esos incentivos divergen, usted asume el costo. No porque alguien sea malicioso. Sino porque así funcionan las dependencias de plataforma.
Por qué los adoptantes tardíos compran
Los adoptantes tardíos, organizaciones que despliegan su primer agente en 2026, tienen una perspectiva diferente. Vieron a los adoptantes tempranos ir primero. Vieron los errores. Y están tomando una decisión deliberada de comprar en lugar de construir.
El tiempo hasta obtener valor es el factor dominante. Un equipo usando Dify o Flowise puede tener un agente funcionando en días, no semanas. Para organizaciones que aún están demostrando a su liderazgo que vale la pena invertir en agentes, la velocidad importa más que el control a largo plazo. Obtener una victoria en el tablero en dos semanas vale más que una arquitectura optimizada para el tercer año.
El ancho de banda de ingeniería es la restricción vinculante. La mayoría de las organizaciones que despliegan sus primeros agentes en 2026 no tienen ingenieros de infraestructura disponibles. Sus equipos de ingeniería ya están completamente asignados. Construir un pipeline de despliegue de agentes, una pila de observabilidad y un sistema de gestión de credenciales desde cero requiere personal dedicado. Una plataforma gestionada intercambia dólares por tiempo de ingeniería, y para organizaciones que tienen presupuesto de SaaS pero capacidad de ingeniería limitada, ese intercambio es racional.
Las plataformas gestionadas han mejorado. Las características de confiabilidad y cumplimiento disponibles hoy son significativamente mejores que lo que existía en 2024 o principios de 2025. Dify ahora ofrece cumplimiento SOC 2. LangSmith proporciona trazabilidad y evaluación de grado producción. Flowise tiene opciones de despliegue empresarial. Las primeras plataformas eran herramientas para experimentación. La generación actual está construida para producción. La brecha entre lo que ofrece una plataforma gestionada y lo que un equipo construiría por sí mismo se ha reducido.
El camino pavimentado es valioso. Los adoptantes tardíos no quieren cometer los errores que los adoptantes tempranos ya cometieron. Quieren seguir un patrón conocido y bueno. Las plataformas gestionadas proporcionan eso: arquitecturas recomendadas, integraciones preconstruidas, patrones de conmutación por error documentados y equipos de soporte que han depurado problemas similares antes. El camino del código abierto requiere cometer cada error uno mismo. Para organizaciones que pueden pagar por la experiencia de otros, ese es un intercambio que vale la pena.
La realidad híbrida
La mayoría de los equipos no están puramente en un lado de esta división. La decisión de construir versus comprar rara vez es una sola decisión. Es un portafolio de elecciones a lo largo de la pila.
El patrón más común que veo: código abierto para orquestación central, gestionado para capacidades específicas. Un equipo ejecuta LangGraph o CrewAI para coordinación de agentes y lógica de flujo de trabajo, pero usa LangSmith para observabilidad y monitoreo. Gestionan su propia base de datos vectorial para memoria pero usan un servicio gestionado para inferencia de modelos. Construyen integraciones de herramientas personalizadas para sus flujos de trabajo centrales pero usan un servidor MCP para conexiones estándar.
La migración de gestionado a código abierto rara vez es un corte limpio. Los equipos que se describen como "migrados" no están completamente fuera de las plataformas gestionadas. Han movido la capa de orquestación central internamente, pero aún dependen de servicios gestionados para pipelines de evaluación, monitoreo o integraciones de herramientas específicas. La decisión de construir versus comprar se está convirtiendo en un portafolio de construir versus comprar, con cada capa evaluada independientemente.
He visto equipos desplegar una plataforma gestionada para agentes orientados al cliente donde la velocidad y confiabilidad importan más, mientras construyen agentes personalizados de código abierto para flujos de trabajo operativos internos que requieren integración profunda con sistemas propietarios. Ambas elecciones fueron correctas. Tratar la decisión como monolítica habría sido incorrecto para ambos.
Lo que esto significa para el mercado
Las empresas de plataforma están siendo presionadas desde dos direcciones. Desde abajo, los frameworks de código abierto se están volviendo más fáciles. El modelo de flujo de trabajo con estado de LangGraph, la delegación basada en roles de CrewAI y los patrones conversacionales de AutoGen han madurado significativamente. Los frameworks manejan más de la carga de producción que hace un año. Desde arriba, los proveedores de nube están añadiendo capacidades de agentes de forma nativa. El constructor de agentes de AWS Bedrock, Vertex AI Agent Builder de GCP y Azure AI Agent Service ofrecen orquestación de agentes gestionada con integración profunda en sus respectivas nubes.
La presión significa que la plataforma gestionada independiente (una empresa cuyo producto completo es una plataforma de orquestación de agentes) enfrenta una posición difícil en los próximos 12 meses. Los sobrevivientes serán aquellos que se hayan especializado en un sector vertical (agentes de salud, agentes de servicios financieros) o hayan construido un foso de plataforma real (infraestructura de evaluación, observabilidad, herramientas de cumplimiento) que ni los frameworks de código abierto ni los proveedores de nube puedan replicar fácilmente.
Los especialistas verticales ya tienen una ventaja. Las plataformas de back-office de salud entienden los flujos de trabajo de autorización previa, el cumplimiento HIPAA y las integraciones EHR de una manera que una plataforma de agentes de propósito general no lo hace. Las plataformas de servicios financieros entienden la conciliación de operaciones, los informes MiFID II y el procesamiento de documentos KYC. Estas plataformas verticales son más difíciles de comoditizar porque su valor proviene del conocimiento del dominio, no de la tecnología de orquestación.
Cómo pensar en su decisión
Si está desplegando agentes ahora y esta es su primera vez: comience gestionado y planifique su ruta de migración. Elija una plataforma que le dé una salida: datos exportables, formatos estándar, API documentadas. Sepa cómo se ve su punto de cruce (aproximadamente 50 agentes o 10,000 ejecuciones por mes) y comience a planificar la migración cuando alcance el 60% de ese umbral. El peor resultado es estar más allá del punto de cruce sin un camino para salir de la plataforma.
Si desplegó en una plataforma gestionada en 2024 o principios de 2025: probablemente ya está planificando su migración. La pregunta no es si, sino cómo. Comience con la capa de orquestación central: es donde las restricciones de la plataforma muerden más fuerte. Muévala a un framework de código abierto (LangGraph para flujos de trabajo con estado, CrewAI para delegación basada en roles). Mantenga los servicios gestionados para cualquier cosa que no sea central para su diferenciación: observabilidad, evaluación, acceso a modelos. El modelo híbrido no es un compromiso. Es la arquitectura duradera.
Si es una empresa decidiendo ahora mismo: tome una decisión a dos velocidades. Use una plataforma gestionada para experimentos de bajo riesgo y alta velocidad: demuestre valor a las partes interesadas, construya confianza organizacional. Invierta en infraestructura de código abierto para los flujos de trabajo que se convertirán en centrales para su negocio. Los experimentos le enseñan lo que necesita. La infraestructura de código abierto le da control sobre lo que importa.
De cualquier manera, la decisión no es permanente. Es una fase. Los equipos que hacen esto bien tratan la elección de construir versus comprar como algo que reevalúan cada trimestre. Los requisitos cambian. La escala cambia. Las opciones disponibles cambian. La pregunta no es si tomará la decisión correcta hoy, sino si notará cuando la decisión correcta cambie.
Este artículo se basa en hallazgos del Artículo 010 (Marco de Decisión Construir vs Comprar), Artículo 020 (Despliegues de Agentes de Mitad de Año), Artículo 023 (Retrospectiva H1) y Artículo 026 (Economía del TCO de Agentes). Los datos de precios de plataformas y despliegues provienen de documentación pública, blogs de ingeniería y conversaciones con equipos que gestionan despliegues de agentes en producción hasta mayo de 2026.
Comentarios
Publicar un comentario