Tu equipo puede construir el agente. ¿Debe hacerlo?

La pregunta no es "¿sabemos construir un agente de IA?". Es "¿es diferencial mantener esta infraestructura dentro de seis meses?". En las reuniones casi nunca discutimos si el equipo puede hacer un prototipo. El debate empieza cuando el roadmap ya va justo y alguien dice "lo hacemos nosotros".

Esa frase es razonable. Muchos equipos SaaS sí pueden construir una primera versión. Lo que rara vez entra en la slide es el mantenimiento: permisos por tenant, trazas, techo de coste, evals y alguien de guardia cuando el modelo cambia. Lo desglosamos en el salto de demo a producción y en el TCO del agente. Aquí nos quedamos con la decisión: construir, comprar o partir.

El verdadero competidor es el desarrollo interno

El vendor de fuera no es el rival más frecuente. Lo es el equipo interno con un intern, un weekend y un "ya lo tenemos". Esa ruta produce demos excelentes. También produce sistemas que nadie quiere heredar en el mes 6.

No vamos a decirte que no sabes construirlo. Si tu equipo entrega producto cada semana, puede montar un agente que hable con tu API. La conversación útil es otra: ¿esa capa es lo que vuestros clientes pagan, o es fontanería que cualquier SaaS con agentes acaba repitiendo?. Gregor Hohpe lo resume en Buy vs. Build Revisited (AWS): "construir lo que te diferencia y comprar el resto" es un buen punto de partida, no el final de la decisión. El matiz que más se salta es el coste de oportunidad. Apartar a quien construye el producto para que reconstruya observabilidad, permisos y techos no sale al salario. Sale a lo que deja de enviarse.

Si el agente es el producto (el cliente te compra esa autonomía), construir tiene sentido. Si el agente es una función más dentro de un SaaS que ya tiene roadmap, construir la plataforma completa suele ser un segundo producto disfrazado de spike.

Qué sí puede (y debe) construir el equipo

Hay piezas que el vendor no debería poseer. Son las que hacen que el agente sea vuestro agente y no un chat genérico sobre un PDF.

El caso de uso y la métrica. Qué flujo, qué cuenta como éxito, quién es el usuario. Sin eso no hay build vs buy que valga: estás comprando o construyendo niebla.

Las tools sobre tu dominio. Endpoints, permisos reales, objetos de negocio, los errores que solo tu producto conoce. Eso es diferencial. Un harness genérico no sabe qué significa "cerrar una factura" en tu tenant.

El criterio de producto. Qué puede escribir el agente, qué pide confirmación, qué nunca toca. Eso no se delega a una plataforma. Se decide en casa.

Los datos y el golden set. Casos reales anonimizados, regresiones, el "así se ve un acierto". Quien posee esa evaluación posee la mejora. Quien no, depende del vendor y de la suerte.

Si tu equipo solo tiene tiempo para una de estas, que sea el caso de uso más las tools. El resto de la fontanería (identidad del agente, trazas, techo, rollback) es lo que más veces se subestima y más caro sale rehacer.

Qué suele ser commodity

Commodity no significa "barato" ni "tonto". Significa que no te diferencia frente al competidor que también está metiendo un agente en su SaaS.

Orquestación y runtime. Colas, reintentos, timeouts, sandboxes, el bucle de tool calls. Cada equipo lo acaba construyendo parecido. La diferencia está en operarlo, no en inventarlo.

Observabilidad de agentes. Trazas correlacionadas, versiones de prompt y modelo, coste por trayectoria. Hace falta. No es lo que el cliente elige al comparar dos productos.

Control de coste. Límites por tenant, por hilo, por día. Alertas. Kill switch. Sin esto el unit economics se rompe. Construirlo una vez para un agente está bien. Construirlo otra vez para el segundo ya es deuda.

Conectores y MCP sobre APIs estándar. Útil. Rara vez es el moat. Si tu ventaja es "tenemos MCP", cualquier competidor lo tiene el trimestre que viene.

La capa de modelos. Routing, fallback, cambiar de proveedor. Importante para no casarte con una API. No es el producto que vendes, salvo que vendas exactamente eso.

Comprar commodity no te quita ownership del caso. Te quita el trabajo de volver a montar el andamio cada vez que un ingeniero se va o el modelo cambia de precio.

Coste de oportunidad y roadmap saturado

El argumento "sale más barato hacerlo dentro" casi nunca compara las mismas cosas. Compara un prototipo interno con un producto externo. El prototipo no trae evals, on-call ni techo. El producto, si es serio, sí.

Hohpe insiste en el mismo punto: el coste real de construir no es la nómina de quien escribe el primer prompt. Es lo que ese perfil dejaría de entregar en el producto que hoy paga las facturas. En un SaaS con roadmap saturado, ese coste de oportunidad suele ser un múltiplo del gasto visible.

Tres síntomas de que "lo hacemos nosotros" está comiendo el trimestre:

El agente no tiene owner con nombre. Vive en un canal de Slack y en la cabeza de quien hizo la demo.

Cada semana de plataforma es una semana que no sale la feature que el cliente ya pidió.

El piloto lleva meses porque "falta una cosa más" y esa cosa es siempre fontanería: permisos, trazas, un techo, un rollback.

Time to market aquí no es vanidad. Es cuántos ciclos de aprendizaje pierdes mientras reconstruyes algo que no verá el usuario. Un híbrido bien partido (vosotros el caso, una plataforma la capa aburrida) suele acortar eso sin regalale el dominio al vendor.

Lock-in, open source y salida

El miedo al lock-in es legítimo. También está mal planteado si solo se aplica al software que compras.

Construir por tu cuenta también ata. Hohpe lo dice sin rodeos: migrar fuera de un sistema interno puede ser igual de duro, o peor, que salir de un paquete comercial. Te quedas preso de tu propio monolito, de las dos personas que lo entienden y de la deuda que la flexibilidad interna fue acumulando.

Comprar ata de otra forma: datos en un formato opaco, skills que no puedes exportar, un runtime que no corre fuera. La pregunta útil no es "¿hay lock-in?" (siempre hay). Es "¿cuál es la salida y en cuántas semanas?".

Una salida seria suele verse así:

Modelos intercambiables. No construir el producto alrededor de un único proveedor de inferencia.

Tools y skills como código vuestro. Si mañana cambias de harness, el contrato con tu API se viene con vosotros.

Trazas y evals exportables. Si no puedes llevarte el historial de fallos, no tienes aprendizaje: tienes un alquiler.

Opción de correrlo en tu infra. Hugging Face lo recuerda con claridad al hablar de modelos abiertos: un plan "privado" en una API alojada sigue ejecutándose en servidores de otro. Local o self-hosted significa hardware que controlas. No son lo mismo, y no deberías decidir arquitectura como si lo fueran. El post está en su blog sobre modelos abiertos en local.

Open source no es un talismán. Es una palanca de salida. Si el código que opera el agente se puede auditar y, llegado el caso, hospedar, el lock-in baja. Si "open" es solo el modelo y el resto es caja negra, el riesgo se ha movido de sitio, no ha desaparecido. En Devic esa palanca está en open source: el caso sigue siendo vuestro; la capa se puede inspeccionar y, cuando hace falta, operar dentro.

Matriz híbrida: cuatro cuadrantes, una decisión

Olvida el binario. La mayoría de equipos que llegan a producción no eligen build o buy. Eligen qué parte de cada uno.

Alta diferenciación, equipo permanente. Construid el agente y la plataforma. Sois una empresa de agentes que además tiene un SaaS, o tenéis platform engineering con mandato explícito. Comprar aquí os frenaría.

Alta diferenciación, equipo saturado. Construid el caso, las tools y el criterio. Comprad runtime, observabilidad y techos. Es el cuadrante más frecuente en un SaaS B2B que quiere un agente en producto este trimestre, no el año que viene.

Baja diferenciación, prisa. Comprad o, mejor, no lo hagáis todavía. Un agente de "preguntas sobre el manual" que no mueve métrica no justifica ni plataforma propia ni un vendor caro. Acota el caso.

Baja diferenciación, mantenimiento alto. Ni lo construyáis ni lo compréis como producto. Automatización determinista, un workflow, un copiloto de lectura. El TCO de un agente autónomo aquí suele ganar al valor.

La matriz no sustituye números. Si no puedes decir el coste por acción exitosa, estás eligiendo por ideología. Vuelve al business case de TCO antes de pelearte por el vendor.

Checklist: ¿construir, comprar o partir?

Antes de comprometer un trimestre, el equipo debería poder responder.

¿El agente es lo que el cliente os compra, o es una función dentro del producto que ya vendéis?

¿Hay un owner con nombre dentro de seis meses, no solo quien hizo la demo?

¿Qué parte es diferencial (caso, tools, datos) y qué parte es andamio (trazas, techos, runtime)?

¿El coste de oportunidad cabe: qué deja de salir del roadmap mientras lo construís?

¿Cuál es la salida? Modelos, skills, trazas, opción de self-host. En semanas, no en "ya veremos".

¿Estáis comparando un prototipo interno con un producto, o dos sistemas que se pueden operar?

Si faltan dos o más, no necesitas un vendor más barato ni un intern más rápido. Necesitas partir el problema. El enfoque híbrido no es indecisión. Es no reconstruir la fontanería para demostrar que podéis.

Cuándo Devic no encaja

Hay casos en los que no deberíais comprarnos, y conviene decirlos.

Si el agente es el producto y ya tenéis un equipo de plataforma que lo operará como P&L propio, construir es coherente. Una capa externa os sobra.

Si solo necesitáis un prototipo de un fin de semana para una demo interna, no hace falta plataforma. Hace falta un alcance estrecho y la honestidad de no venderlo como producción.

Si el flujo es estable, verificable y no requiere un modelo, una función determinista gana. Un agente ahí es teatro.

Si exigís un runtime que no exponemos o un modelo de datos que no podemos exportar a vuestra medida, no forcéis el encaje. El lock-in malo empieza cuando se ignora un "no" técnico.

Donde sí solemos encajar es el cuadrante saturado: el caso y las tools son vuestros, y no queréis volver a construir observabilidad, permisos y techo para cada agente. Eso es el harness de producto, con tool calls como unidad. Si la salida y el control de la infra mandan más que el time to market, el camino es open source.

Cuando tengas las respuestas del checklist, el resto es una decisión de arquitectura, no de orgullo. Y si quieres contrastarlas con vuestro API, vuestro margen y vuestro equipo real, se miran con esos números encima de la mesa, no con una slide de "lo hacemos nosotros".