3. Cada cual su sistema

Si el software congelado deja de ser la respuesta, algo ocupa su lugar, y todavía no tiene un nombre que todos usen. No se parece al desarrollo a medida, que también muere. La diferencia no es el tamaño del equipo ni la duración del proyecto. Es qué dispara el cambio. En el desarrollo a medida alguien especifica el negocio, alguien lo programa y el sistema queda quieto hasta el próximo proyecto, por barato que ese proyecto sea y aunque quien programe sea un agente. En el sistema propio nadie especifica de antemano: el trabajo llega, el agente lo atiende y lo que se repite lo cristaliza él. Lo describo con lo que veo.

¿Cómo se ve una organización que construye su propio sistema?

Como una plantilla que cobra vida. Mi amigo, el del sistema patrimonial, no le vende a cada familia un producto. Le instala un punto de partida: un sistema que ya registra los bienes, los contratos de arriendo, las cuentas por cobrar y los estados financieros de las empresas de la familia, y que ya genera los reportes y las alertas que necesita quien administra un patrimonio. Desde el día de la instalación, ese sistema empieza a dejar de ser la plantilla. Su dueño le pide cosas a la inteligencia artificial y la inteligencia artificial lo cambia: una vista nueva, un cruce entre el contrato y el estado de cuenta, una alerta que nadie había pensado. Al cabo de un año, dos familias que partieron de la misma plantilla tienen dos sistemas distintos, cada uno con su nombre. Eso es solo el primer paso: el agente cambia el sistema cuando se lo piden. Lo que viene después, y que cuento más abajo, es que el agente aprende el trabajo y lo cambia él.

Con el software comprado, el proveedor decidía qué se podía hacer y el cliente se adaptaba. Con el desarrollo a medida decidía el cliente, pero una vez, en la especificación, y cada cambio era un proyecto. Con el sistema propio decide el cliente mientras el trabajo ocurre: lo que antes era una solicitud de cambio, con su cotización y su espera, ahora es una conversación.

Pasa también a escalas que no se parecen a una familia. Conozco una empresa mediana que opera sobre un ERP comercial y piensa reemplazarlo. La pregunta de siempre habría sido cuál de los ERP de la competencia le conviene. La que le estoy planteando es si no le convendría construir el suyo, sobre sus datos, y evolucionarlo con agentes. Un operador de telecomunicaciones, como el del capítulo 7, puede hacerse la misma pregunta sobre el sistema que factura a millones de clientes.

El sistema patrimonial y la empresa del ERP, que son dos casos distintos, están todavía en ese primer paso, en que el agente cambia el sistema cuando se lo piden. El paso siguiente, en que nadie tiene que pedirlo, es el que el capítulo 7 todavía no puede mostrar medido.

¿Qué hacen los agentes en ese sistema?

Dos trabajos que conviene no confundir.

El primero es construir y cambiar el sistema. Antes lo hacía un equipo de desarrollo; ahora lo hace, cada vez más, un agente, guiado por alguien que sabe lo que el negocio necesita.

Que lo haga un agente admite dos lecturas, y solo una cambia las cosas. Les doy los nombres que AgencyDomains da a los dos lados de la Línea Nadella, porque es la misma distinción, llevada de la interfaz al sistema que está debajo.¹

La primera es la lectura agéntica. El agente es un programador más rápido: escribe el código que antes escribía una persona, y la organización sigue necesitando un equipo de desarrollo que lo dirija, lo revise y lo mantenga. Lo que sale del agente es una aplicación, y la aplicación persiste, como persisten en el mundo agéntico las herramientas de siempre con un agente adentro.

La segunda es la lectura agentiva, y es la de este libro. Nadie programa el sistema de antemano: la organización decide qué trabajo tiene que existir, y el agente lo forma. El agente atiende el trabajo razonando, y lo que se repite lo cristaliza en piezas propias que lo resuelven sin volver a pensarlo, como el experto que deja de deliberar lo que ya sabe hacer.² AgencyDomains describe esa mecánica: hoy el agente parte de una pieza existente y la configura para su caso. El canon prevé que pueda coescribirla y, en el límite, generarla entera, pero aclara que generar más no es avanzar: el agente maduro reutiliza lo que ya cristalizó y gasta su capacidad de generar en lo nuevo.³ Lo que la organización aporta en la lectura agentiva no es código. Es su saber: el experto del negocio le enseña al agente cómo se hace el trabajo, con una práctica de entrega que lo acompaña, y valida que lo aprendió, primero en prueba y después en operación real.⁴

Que construir y cambiar el sistema se haya vuelto barato, o innecesario, es la razón de fondo de todo lo que cuenta este libro.

El segundo es operar el sistema: atender una consulta, rastrear una orden que se cayó, preparar una conciliación, proponer una corrección. El agente lo hace trabajando sobre las reglas del negocio, sin reemplazarlas. Lo determinista, como calcular un impuesto o aplicar una tarifa, queda en flujos definidos que hacen siempre lo mismo, y el agente se ocupa de lo que nadie previó. Dicho en una frase, que el capítulo 7 apoya en lo que publican los operadores de telecomunicaciones: el agente orquesta los flujos, no los reemplaza.

Esta distinción importa más de lo que parece. Quien imagina un sistema agentivo como un modelo de lenguaje que decide todo, con libertad, tiene razón en tenerle miedo. Un sistema bien construido no funciona así.

¿Qué cuesta que el agente atienda el trabajo?

Si el agente atiende el trabajo razonando, y razonar con un modelo de frontera es caro, el sistema propio podría salir más caro que el software que reemplaza. La respuesta es que no todo el trabajo pide el mismo razonamiento, y AgencyDomains lo ordena en tres peldaños.⁵

Abajo está lo que se repite igual. El agente lo cristaliza en Botlets, código que se ejecuta sin consultar ningún modelo y que cuesta lo que cuesta cualquier programa. Arriba está el razonamiento pleno, que AgencyDomains llama cognición plena, reservado para lo que es de verdad nuevo.

En el medio está lo que se repite en su forma pero pide juicio en cada caso: clasificar un reclamo, decidir si una alerta merece despertar a alguien, leer una factura que nunca se había visto. Ninguna regla escrita de antemano lo resuelve bien, y tampoco merece el modelo más caro. Para eso el canon tiene una segunda especie de pieza, el Agentlet: hermano del Botlet, con un encargo declarado y un modelo dimensionado a la tarea, no el más grande, con un presupuesto por ejecución. Su imagen es la enfermera de triaje de una sala de urgencias: no resuelve de memoria, porque cada paciente es distinto, pero tampoco llama al jefe de medicina para cada uno. Cuando no está segura, escala.

Los Agentlets son, como los Botlets, del agente: los forma y los mantiene él, con la misma salvedad que hice para los Botlets. Y el sistema maduro empuja el trabajo hacia abajo en la escalera: lo que empezó pidiendo juicio y resulta tener un núcleo que siempre se resuelve igual, el agente lo cristaliza en un Botlet. Lo que de verdad es interpretativo no baja: se queda en el peldaño del medio, porque por naturaleza no madura hacia el código. Que el Agentlet sepa cuándo no está seguro es, según el propio canon, un problema abierto; mientras tanto se compensa con umbrales prudentes, que escalan de más antes que de menos. Y como toda su inferencia pasa por la plataforma del agente, cada decisión queda medida, con su presupuesto y su rastro, bajo las mismas capas de control del capítulo 6. Decide con una probabilidad, no con una explicación: para lo que debe poder justificarse, escalar es una decisión de diseño, no un fracaso.

El peldaño del medio podría abaratarse mucho. Hay ya un modelo, de un solo proveedor, de una clase que no genera texto: recibe el caso y un conjunto de preguntas con respuestas de opción cerrada, como sí o no, o una de varias categorías, y devuelve decisiones con una probabilidad asociada a cada una, en fracciones de segundo y por una fracción del costo de un modelo de frontera, según su proveedor.⁶ La probabilidad es lo que lo volvería útil aquí, si es honesta, es decir, si cuando dice «90 %» acierta nueve de cada diez veces: por encima de un umbral, el Agentlet decide; por debajo, escala. Si esas promesas resisten la medición, el costo de que el agente atienda el trabajo deja de ser la objeción y se vuelve el argumento. Todavía no lo he medido.

El tiempo también cambia con el peldaño. Un Botlet responde en lo que tarda un programa. Un modelo de decisión, según su proveedor, en fracciones de segundo, pero solo cuando está seguro: cuando duda, escala, y la respuesta llega al ritmo del razonamiento pleno, que es mucho más lento. Para el trabajo que ocurre mientras el cliente espera, como aprobar una orden, clasificar un reclamo o contestar en un canal, esa diferencia decide qué puede resolver el agente en el momento y qué tiene que dejar para después. Tasar una llamada no está en esa lista: es de lo determinista, y lo resuelve un flujo definido.

Cambia además de quién depende el negocio. Los modelos de frontera viven en infraestructuras enormes, de unos pocos proveedores en el mundo. Un Botlet maduro no depende de ninguna: es código, y corre donde corre todo lo demás. Si uno joven falla, el trabajo vuelve al agente, que lo hace con el modelo de frontera, y por eso, según AgencyDomains, solo el Botlet maduro opera sin conexión.⁷ Un Agentlet nunca llega a ese punto: su juicio es estadístico y, cuando duda, escala al razonamiento pleno. Podría correr en el centro de datos de la empresa o en el propio sitio, como una sucursal o una antena, si hay un modelo dimensionado que alcance la calidad que el encargo pide; el canon exige declararlo, pero lo presenta como una frontera abierta, no como algo resuelto. Cuanto más trabajo baja por la escalera, menos depende el negocio de que un tercero lejano esté disponible, siga cobrando lo mismo o siga existiendo. No deja de depender del todo: lo nuevo, y todo lo que falla, sigue subiendo al modelo de frontera. Y el modelo de decisión del que hablé se ofrece hoy solo como servicio de quien lo hace, de modo que, mientras eso dure, el peldaño del medio cambia una dependencia por otra. La independencia la da la escalera bien construida, no él.

¿Por qué ahora y no antes?

Porque cayeron a la vez las tres cosas que lo impedían. Escribir software era caro y cambiarlo era lento; las dos cosas dejaron de serlo. Y el trabajo que nadie especificó no se podía automatizar, porque el software solo hace lo que alguien escribió de antemano.

Hay una cuarta condición, que vuelve todo esto posible a escala: los estándares. Una empresa que construye su propio sistema no tiene que inventar su modelo de datos ni sus interfaces, porque las industrias maduras ya los escribieron. En las telecomunicaciones, el TM Forum publica desde hace años una arquitectura de referencia, un modelo de información común y un conjunto de interfaces abiertas que cualquiera puede usar. No es cosa solo de las telecomunicaciones. En la banca, BIAN publica un mapa de los servicios de un banco, un modelo de sus objetos de negocio e interfaces abiertas, y los mensajes financieros convergen en ISO 20022. En los seguros, ACORD mantiene un modelo de información de la industria: la póliza, el producto, las partes, el siniestro. En la salud, HL7 FHIR define los recursos clínicos y cómo se intercambian. En la electricidad, el modelo común de información de la IEC describe la red y la empresa eléctrica, y en las aerolíneas, ONE Order, de IATA, reúne en una sola orden lo que antes eran varios registros de reserva.⁸ Sobre estándares, un componente se puede cambiar sin rehacer el resto, y eso separa un sistema propio de un callejón sin salida. Hoy esa promesa la sostienen dos estándares, el modelo de información y las interfaces abiertas, que la industria adoptó hace años. Los componentes intercambiables que el TM Forum también promete son la parte menos madura de su arquitectura: en marzo de 2025, el 58 % de los operadores y la mitad de los proveedores no esperaba poder cambiar de proveedor componente por componente antes de cinco años, y otro 21 % de los operadores y 35 % de los proveedores decía que no se podía saber.⁹

¿Entonces nadie vuelve a comprar software?

Se seguirá comprando. Cambia qué se compra y por qué: menos la aplicación que fija los procesos y más lo que no conviene construir en casa ni dejar que el agente aprenda solo. El resto de este libro trata de qué es eso, el núcleo de verdad, y empieza por lo que se pierde cuando se deja de comprar.