Construir tu propia capa de agentes o comprarla: la cuenta que nadie te pasa

Si tu equipo ya tiene un agente andando en su propio código, esta decisión ya te llegó o te va a llegar: seguir construyendo hacia abajo, o comprar la capa y dedicar el equipo a lo que te distingue.

No hay una respuesta buena para todos. Hay una pregunta que sí sirve, y no es «cuál es mejor».

La parte que sale en una tarde, y la que no

Conectar un modelo a un puñado de funciones propias funciona rápido. Ese primer prototipo suele estar andando el mismo día, y es exactamente por eso que la decisión se toma mal: se estima el proyecto con el tiempo del prototipo.

Lo que toma meses es lo que rodea al agente cuando deja de ser un prototipo:

• El canal, con sus reglas. Si va a atender WhatsApp, la línea tiene que estar conectada por la API oficial, y ahí aparece la ventana de 24 horas: dentro de ella el agente responde libre, fuera de ella solo salen plantillas aprobadas antes. Esa regla no es de la plataforma que uses, es del canal, y termina reordenando el diseño entero.
• Las herramientas contra cada sistema. No la primera, que siempre es fácil: la número catorce, contra un ERP que devuelve el error dentro de un cuerpo con código 200.
• Los permisos, por herramienta y no por usuario. Un agente que solo puede leer no puede romper nada. Uno que puede escribir necesita límites explícitos, y esos límites tienen que existir en el código, no en el prompt.
• La idempotencia. Un agente que se reintenta y crea el pedido dos veces no falla: cobra dos veces. Es el tipo de error que no se ve en pruebas y se ve en el reclamo.
• La traza. Qué herramienta llamó, con qué parámetros, qué devolvió y cuánto tardó. Sin eso, depurar un comportamiento raro es leer conversaciones a mano.
• La medición del consumo. Si el modelo lo pagas tú y el uso lo hace tu cliente, necesitas saber cuánto consumió cada quién antes de la factura, no después.

Ninguna de las seis es difícil. Juntas son un producto, y es un producto que tu cliente no te compra: te lo exige como requisito para poder comprarte lo otro.

La pregunta que sí decide

¿Esa capa es lo que te diferencia, o es lo que tienes que atravesar para llegar a lo que te diferencia?

Si tu producto se vende porque orquesta agentes mejor que los demás, construir es lo correcto y comprar te quitaría justo la parte que vale. Es el caso de quien vende una plataforma de agentes.

Si tu producto se vende por tu conocimiento del sector, por tus datos, por tu red de clientes o por un flujo que solo tú entiendes, la capa es infraestructura. Y la infraestructura se compra por la misma razón por la que no montas tu propio proveedor de correo transaccional: no porque sea imposible, sino porque el mes que gastas ahí no lo gastas en lo que sí te diferencia.

Lo que cambió, y por qué importa ahora

Hasta hace poco había un argumento fuerte a favor de construir: cualquier capa que compraras te ataba a un proveedor, porque cada fabricante inventaba su forma de exponer herramientas a un modelo.

Eso se movió. El Model Context Protocol pasó en diciembre de 2025 a gobernarse dentro de la Agentic AI Foundation, bajo la Linux Foundation, con varios fabricantes grandes en la mesa. La consecuencia práctica es que un servidor MCP dejó de ser una apuesta por el roadmap de una empresa y pasó a ser una interfaz que varios clientes distintos ya saben consumir.

Para esta decisión eso significa dos cosas concretas: comprar ata menos que antes, y construir tu propio protocolo propietario rinde menos que antes.

Lo que ya está construido, y suele ser el argumento entero

Si haces la lista de lo que te falta, casi siempre aparece algo que no es «capa de agentes» sino un conector.

Y ahí hay una asimetría que conviene mirar antes de abrir un repositorio: buena parte del software con el que se opera en América Latina no tiene servidor propio de su fabricante ni aparece en los catálogos grandes de automatización. El CRM inmobiliario, la transportadora, la facturación local, el ERP que usa media industria del país. Construir esos conectores no es difícil, es lento y aburrido, y cada uno hace menos de lo que su nombre sugiere: el de una transportadora puede cotizar y rastrear sin generar guías, y el de un ERP puede ser de solo lectura a propósito.

Por eso cada ficha de nuestro catálogo publica dos listas: las herramientas que existen de verdad, con su nombre, y lo que la integración no hace. La segunda es la que sirve para estimar, y es la que casi nadie publica.

Un camino intermedio que casi siempre gana

Comprar la capa no es renunciar a escribir código. En nuestro caso, lo que un equipo externo puede hacer hoy está publicado y tiene un límite escrito:

• Un servidor MCP remoto que se autentica con una llave de API, para que tu agente (o Claude, o Cursor) opere la plataforma.
• Una API REST con llaves de alcance granular, y un SDK de TypeScript generado del mismo contrato, para cuando el que escribe el código eres tú.
• El trabajo contra los sistemas locales lo hace un Met: tu agente lo ejecuta y el Met usa los conectores que ya tiene activos. Invocar cada herramienta del conector una por una desde afuera está diseñado y todavía no está publicado, y lo decimos así en vez de prometerlo.

Ese reparto suele ser suficiente para salir al mercado, aprender con clientes reales qué es lo que de verdad te diferencia, y construir eso. El orden inverso, construir la capa completa primero y descubrir después qué te diferenciaba, es el que cuesta el año.