Más allá de Agentforce y Copilot Studio: cuándo elegir un runtime abierto y autoalojado

En resumen: las suites cerradas ganan dentro de su propio ecosistema, si todo tu mundo vive dentro de los muros de un solo proveedor. Cuando los datos están repartidos por varios sistemas, deben seguir siendo tuyos y quieres poder elegir el modelo, la respuesta es un runtime abierto y autoalojado (o usar ambos).

Una empresa hace su selección de AI agent, y la lista de finalistas sale sola: Agentforce, Copilot Studio, ServiceNow AI Agents. Las tres son fuertes y las tres tienen quien las recomiende.

Estuvieron a punto de firmar Agentforce, que era el que hacía la demo más bonita en el escenario de CRM. Justo antes del último paso, un arquitecto planteó una pregunta: “Las consultas de cliente que queremos que gestione el agent, la mitad hay que buscarlas en las oportunidades de Salesforce y la otra mitad en las entregas y los tickets de nuestro sistema propio. ¿Cómo accede Agentforce a esa mitad que está al otro lado del muro?”.

La respuesta del comercial fue “se puede hacer una integración”. Así que dedicaron seis semanas a montar una PoC de integración. La conclusión fue clara: sí se puede conectar, pero por cada sistema que añades al otro lado del muro hay que reescribir una sincronización, alinear los criterios una vez más y mantener una tubería que se acabará rompiendo; y ellos tenían siete u ocho sistemas al otro lado del muro. En ese instante el equipo cayó en la cuenta: el problema no era que Agentforce no fuera lo bastante bueno, sino que, igual que las otras dos, daba por supuesta una premisa que no se cumplía para esta empresa.

El coste de seis semanas y una PoC compró una lección que en realidad se podía haber pensado claramente desde el principio.

La premisa que no se dice en voz alta: tu mundo entero está dentro de un muro

La fortaleza de estas suites es, en esencia, ser “óptimas dentro del ecosistema”. Agentforce da por hecho que tus clientes, procesos y objetos ya están en Salesforce; Copilot Studio da por hecho que tu colaboración, documentos e identidad están en 365; ServiceNow da por hecho que tus procesos están sobre él. Cuando la premisa se cumple, de verdad ahorran quebraderos de cabeza: los datos ya están, los permisos ya están, la integración ya está, y el agent casi se conecta de pasada.

Pero esa premisa, para la mayoría de las empresas, no se cumple. La empresa real tiene esta pinta: el CRM de una marca, el ERP de otra, los tickets en una tercera, más un montón de sistemas propios y hojas de cálculo; quieren conservar la libertad de elegir modelo, porque los modelos cambian de aspecto cada año; y están sujetas a regulación, así que los datos no pueden salir del dominio sin más. Para una empresa así, “óptimo dentro del ecosistema” se convierte en una restricción, porque tu mundo sencillamente no está dentro del muro de ninguna de ellas. Que por cada sistema fuera del muro haya que reescribir una tubería es exactamente el muro contra el que chocó aquella empresa en su PoC.

Desplegado para comparar: no es quién es mejor, sino a quién le conviene cada uno

Dimensión	Suite cerrada (Agentforce / Copilot / ServiceNow)	Runtime abierto y autoalojado (ObjectStack / ObjectOS)
A quién conviene más	El negocio ya está muy concentrado en ese ecosistema	Los datos dispersos en varios sistemas, multistack, con autocustodia
Ubicación de los datos	Nube del proveedor	Tu propia infraestructura
Elección de modelo	Inclinada al propio o a un modelo atado	Cámbialo libremente; el modelo fuera, el runtime dentro
Propiedad de la definición de negocio	Crece dentro de la plataforma	Metadatos de protocolo abierto en tu repositorio (Apache 2.0)
Facturación	Por acción / por asiento	Por runtime e infraestructura, desacoplada del uso
Postura de partida	Primero meter el negocio en el ecosistema	Extender los sistemas existentes, sin exigir migrar primero

Esta tabla no tiene una columna que sea “todo correcto”.

Primero, dos jarros de agua fría: muchas veces deberías elegir la suite

Dejémoslo claro de entrada, para que esto no se convierta en una promoción de un solo lado. El autoalojamiento abierto no es la elección más noble, es la elección preparada para una situación concreta, y la situación de muchas empresas encaja precisamente con la suite.

Primero, si tu mundo de verdad está básicamente dentro de un muro. Si el 90% de tu negocio está en Salesforce, no te importa que los datos salgan del dominio y no piensas cambiar de modelo, entonces Agentforce probablemente sea la solución óptima. Asumir la carga real y presente de migrar y operar para conjurar el riesgo, aún no materializado, de “no quedar bloqueado” no sale a cuenta.

Segundo, si no tienes un equipo de plataforma. Este es el clásico “construir vs. comprar”. Abierto y autoalojado significa que tienes que operarlo tú: parchear, garantizar la disponibilidad, gestionar bien las actualizaciones. La experiencia gestionada de la suite —“listo para usar, alguien coge el teléfono si algo falla, con un SLA que cubre”— para una empresa sin un equipo de plataforma dedicado suele valer más y dar menos quebraderos de cabeza que “el control total”. El control tiene un coste operativo, y un control que nadie puede sostener es una carga.

Pero “comprar la suite” ahorra menos trabajo del que crees

Ahora bien, en el lado de “comprar” hay una factura que se suele dejar sin contar: el impuesto de integración.

En el presupuesto de la suite está escrito el dinero de los asientos o las acciones, pero no está escrito esto: cada uno de tus siete u ocho sistemas fuera del muro necesita una tubería de integración; al construirla hay que alinear los criterios, y una vez construida hay que mantenerla al ritmo de las actualizaciones de ambos lados, porque si una de las dos puntas cambia un campo, la tubería puede romperse en silencio. Aquella PoC de seis semanas de la empresa del principio midió justamente la entrada de ese impuesto. Así que “comprar la suite + un montón de integraciones frágiles”, por fuera es buy, pero en el fondo sigues haciendo build, y haciendo el build de la parte menos valiosa y más frágil.

Si metes ese impuesto de integración en el TCO, la conclusión de “comprar da menos quebraderos de cabeza” solo se sostiene cuando tienes muy pocos sistemas fuera del muro, o cuando esos sistemas, de entrada, no necesitan que el agent los alcance. Cuanto más disperso es el panorama, más pesado es el impuesto, y más se le come la ventaja del “menos quebraderos de cabeza” de la suite.

En realidad puedes usar los dos: el híbrido no es nadar entre dos aguas

Esto lleva a una opción que el debate de selección ignora desde hace tiempo: no tiene por qué ser una pregunta de respuesta única.

La arquitectura más pragmática suele ser híbrida: en el ecosistema que de verdad usas de forma intensiva, sigue usando su suite —que el agent comercial de Salesforce haga lo que mejor sabe hacer Agentforce—; pero en esa capa transversal a los sistemas, que necesita criterios unificados y autocustodia de los datos, usa un runtime abierto y autoalojado como tejido conectivo. Este último no sustituye a la suite, hace eso que la suite, por su estructura, no hace bien: recoger el negocio disperso en varios muros en una definición unificada que posees tú, con permisos y auditoría.

Dicho de otro modo, el runtime abierto puede ser el tejido conectivo por encima de tus varios sistemas (incluidas esas suites), en lugar de otro muro al que tengas que mudarte. Reconocer esto convierte la selección de “a qué proveedor apostar” en “qué parte con la suite y qué parte con lo abierto”, y así es como aterrizan al final la mayoría de las empresas reales.

El autoalojamiento abierto, ¿qué te da en realidad?

Si perteneces a la columna de la derecha, o si lo que vas a hacer es justamente esa capa de conexión transversal a los sistemas, entonces “abierto + autoalojado” no te da romanticismo, te da capacidades concretas. Lo que mejor lo ilustra es su postura ante los sistemas existentes, que es justo donde se atascó la empresa del principio.

La suite quiere que tu mundo se mude a su muro; el runtime abierto da por hecho que tu mundo es disperso de origen, y su trabajo es lograr que los sistemas existentes soporten la IA de forma nativa, sin migrar primero. Los datos de cliente de aquella empresa estaban la mitad en Salesforce y la otra mitad en un sistema propio. En ObjectOS, conecta cada sistema como una fuente de datos, modela cada uno como objetos y los alinea en un único “cliente” gobernado mediante una clave compartida (el NIF):

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: 'Cliente',
  fields: {
    name: Field.text({ label: 'Nombre del cliente', required: true }),
    tax_id: Field.text({ label: 'NIF' }), // clave compartida para alinear "el mismo cliente" entre sistemas
  },
});

La diferencia se puede concretar en una sola pregunta. “¿Vale la pena invertir recursos en retener a este cliente?”:

• Antes: el agent, conectado a Salesforce, ve oportunidades activas y responde “vale la pena”; no tiene ni idea de que, en el sistema propio, las entregas de este cliente llevan tiempo retrasándose y los tickets se acumulan.
• Después: el agent se enfrenta a un único cliente unificado, mira a la vez oportunidades, entregas y tickets, y responde “las oportunidades pintan bien, pero el riesgo de entrega es alto; resolvamos primero el cumplimiento del servicio y luego hablamos de ampliar el pedido”.

El mismo modelo, la misma pregunta, y solo porque el “cliente” de abajo ya no está partido por el muro, la conclusión pasa de parcial a global. Y todo esto sin reescribir una tubería de sincronización por cada sistema fuera del muro: la definición de negocio son metadatos en tu repositorio, diff-eables y migrables; el runtime corre en tu propia infraestructura, fuerza los permisos y registra la auditoría; y el modelo puede venir de cualquier proveedor externo. No has entregado “la definición de tu propio negocio” a nadie para que la custodie.

Una pregunta honesta de elección

Así que esto no es “a quién hay que eliminar”, es “qué parte le encargas a quién”. Hazte tres preguntas:

1. Mi negocio, ¿está básicamente todo en un solo ecosistema, o disperso en varios sistemas?
2. ¿Puedo aceptar que los datos fluyan sin parar hacia la nube del proveedor? ¿Lo puedo firmar en términos de cumplimiento?
3. ¿Tengo o no un equipo para operar un runtime autoalojado?

Si las dos primeras respuestas tiran hacia “disperso, no”, y la tercera hacia “sí”, entonces lo que buscas, de origen, no es otra suite cerrada más potente, al menos no en esa capa transversal a los sistemas. Si las tres respuestas tiran hacia el otro lado, usa la suite con tranquilidad, que de verdad son buenas. Encajarte con honestidad en la casilla correcta, incluso usarlas mezcladas sin complejos, importa mucho más que perseguir qué proveedor tiene la función más nueva, y sale mucho más barato que pasar seis semanas haciendo una PoC para acabar de entenderlo.

Cierre

La suite cerrada gana en “óptimo dentro del ecosistema”, una ventaja muy real cuando su premisa se cumple, que no debe negarse. El runtime abierto y autoalojado gana en “seguir siendo válido cuando la premisa no se cumple”: cuando tu mundo es disperso, los datos hay que autocustodiarlos, el modelo hay que poder elegirlo libremente, la definición hay que tenerla en tus propias manos, y además puedes asumir la responsabilidad de operarlo tú.

Saber qué parte usar con la suite, qué parte con lo abierto, y qué precio pagas por cada una, importa más que la lista de funciones de cualquier proveedor. Si la empresa del principio se hubiera hecho antes esas tres preguntas, se habría ahorrado seis semanas y una PoC.

npm i -g @objectstack/cli && os start

Sin migrar, sin entrar en el muro de nadie, pon en marcha en cinco minutos, en tu propio entorno, un objeto unificado que cruce dos sistemas, y luego juzga si este camino se parece más a lo que buscabas.