El próximo usuario de ERP puede no ser humano

Cada pantalla es una suposición sobre quién está mirando

Considera lo que es un ERP desde el lado de su usuario. Detrás de la marca hay un conjunto de tablas y reglas: clientes, artículos, pedidos, facturas, movimientos de stock y las restricciones que las mantienen consistentes. Delante de eso está la parte en la que se gastó la mayor parte del dinero: varios miles de pantallas que presentan esas tablas a una persona unos pocos campos a la vez, en un orden que una persona puede seguir, con etiquetas que una persona puede leer y botones que una persona puede encontrar.

Cada una de esas pantallas codifica una suposición sobre quién está al otro lado. La suposición es que es una persona con una memoria de trabajo limitada, por lo que el formulario se divide en pestañas. Una persona que lee de izquierda a derecha, por lo que el campo importante va en la parte superior izquierda. Una persona que puede retener aproximadamente siete cosas en mente, por lo que el panel de control tiene seis mosaicos. Una persona que cometerá errores de escritura, por lo que hay validación al enviar. Una persona que se cansa, por lo que el camino común tiene menos clics. Todo esto es un buen diseño para el usuario que tenía el diseñador, y durante cuatro décadas ese usuario fue el único que existió.

La consecuencia es que la interfaz es una representación con pérdida del modelo de datos para un tipo de lector. El modelo sabe que una factura tiene líneas, un cliente, una fecha de vencimiento y un estado; la pantalla muestra las líneas en una pestaña, el cliente en otra y el estado como un color. El trabajo que toca cinco registros significa cinco pantallas, y la persona lleva el hilo entre ellas en su cabeza. Ese hilo es la mayor parte de lo que una empresa paga a su personal administrativo para mantener.

El nuevo usuario tiene herramientas, no manos

Un agente de IA que opera un sistema empresarial no recibe nada de eso. Lo que recibe, cuando se conecta a través del Model Context Protocol, es el resultado de una solicitud para listar herramientas: para cada una, un nombre, una descripción escrita para que un modelo la lea, un esquema para sus entradas y, opcionalmente, una anotación que indique si la herramienta solo lee, si puede destruir algo y si llamarla dos veces es seguro. El agente elige una herramienta, la llama con argumentos escritos, lee el resultado y elige de nuevo. El resumen del protocolo es que es una forma estandarizada de conectar aplicaciones de IA a sistemas externos, como un puerto común conecta dispositivos, y los principales clientes ahora lo hablan: Claude, ChatGPT, Cursor y VS Code entre ellos.

Mira lo que este usuario no necesita. No necesita que la factura se divida en pestañas, porque puede retener todo el registro a la vez. No necesita que el campo importante esté en la parte superior izquierda, porque no hay izquierda. No necesita seis mosaicos, porque puede pedir el número que quiere. No se cansa, y no hay clics. Cada concesión que hizo que la pantalla fuera buena para una persona es, para este usuario, irrelevante o un obstáculo.

Y mira lo que necesita en su lugar, que la pantalla nunca proporcionó. Necesita que la descripción de cada acción sea precisa, porque la descripción es la totalidad de su comprensión. Necesita que el esquema sea completo, porque no puede ver un ejemplo. Necesita saber qué acciones son seguras para reintentar. Necesita que el resultado diga qué ocurrió y qué puede hacer a continuación. Para este usuario, la documentación es la interfaz, y nombrar es diseño: una herramienta amplia con una descripción de dos líneas es un producto peor que la misma capacidad como tres herramientas con nombres claros y descripciones honestas, independientemente de cómo se vean las pantallas encima de ellas.

El desvío a través de la pantalla no durará

La primera respuesta a un nuevo usuario siempre es vestirlo como el antiguo. La automatización de procesos robóticos hizo esto durante una década: un bot inicia sesión con una cuenta de servicio y controla las pantallas como si tuviera manos, encontrando el botón por su selector o sus coordenadas. La versión actual le da a un modelo de lenguaje una captura de pantalla y un cursor. El uso informático de Anthropic hace exactamente eso, y su documentación es cuidadosa al indicar dónde pertenece: existe para los casos en los que no hay una interfaz más ajustada disponible, te dirige a una herramienta de navegador cuando el trabajo se mantiene dentro de una página, y pide a una persona que confirme cualquier cosa con consecuencias reales significativas, incluidas las transacciones financieras.

El disfraz es caro de llevar. Una pantalla no le hace promesas a una máquina, así que cada cambio realizado para la persona rompe la automatización que finge ser una. Cada capa entre el agente y la acción, la captura de pantalla, la suposición de qué píxel es el botón, el texto escrito que puede o no haber caído en el campo correcto, es un lugar para equivocarse, y un modelo ya es un lugar para equivocarse. La conducción por pantalla es el puente que construyes mientras el sistema subyacente no tiene nada mejor, y los proveedores de los bots lo dicen ellos mismos: ahora describen al robot como una capa de ejecución que un agente invoca para los sistemas que aún la necesitan.

Lo que el software tiene que convertirse

Si el argumento hasta ahora es válido, la forma del software nativo de agentes se deriva de ello, y es más que una API adicional. Cinco propiedades deben ser verdaderas al mismo tiempo.

• Cada acción es una herramienta. No la docena que el proveedor pensaba que eran seguras, sino toda la superficie que una persona puede alcanzar a través de las pantallas: crear, leer, mover, aprobar, enviar, conciliar. Cualquier cosa menos, y el agente tiene que recurrir a la pantalla por el resto.
• Cada llamada lleva una identidad. El agente actúa como una persona específica, a través de un inicio de sesión normal, y las herramientas que se le ofrecen se filtran según el rol de esa persona antes de que las vea y se comprueban de nuevo cuando se ejecutan. Un agente con acceso total al sistema es un fallo de diseño, no una característica.
• Pregunta por diseño. Algunas acciones se ejecutan; algunas se mantienen para una persona; algunas son rechazadas directamente. El protocolo mismo dice que siempre debe haber un humano en el bucle capaz de denegar una llamada a la herramienta, y los principales clientes preguntan antes de una escritura por defecto. El software debe hacer que las categorías sean explícitas en lugar de esperar que el modelo sea educado.
• El gasto tiene un límite. Donde el razonamiento del sistema cuesta dinero, o donde una herramienta compromete dinero, hay un límite por conexión que el sistema impone y el modelo no puede eludir.
• El registro es el producto. Cada llamada, sus entradas y su resultado, bajo la identidad que la realizó, es revisable de la misma manera que las acciones de una persona. Para un agente, la trazabilidad es cómo se construye la confianza, una semana a la vez.

Una sexta propiedad es menos un requisito que una consecuencia. Cuando el trabajo se realiza a través de herramientas, el registro se mantiene como un subproducto: el agente que factura, persigue y concilia deja exactamente la factura, el seguimiento y la conciliación que una persona habría escrito, sin necesidad de escribir. Las pantallas sobreviven, para mirar, revisar y decidir. Dejan de ser el único lugar donde puede ocurrir el trabajo.

La objeción que vale la pena tomar en serio

La objeción más fuerte concede que los agentes pueden hacer el trabajo y señala que a veces lo hacen mal, con confianza, en una escritura. Esto es cierto, y la documentación honesta lo dice: ChatGPT trata cualquier herramienta sin una anotación de solo lectura como una escritura y requiere confirmación por defecto; Claude pide aprobación antes de invocar una herramienta de un conector personalizado y advierte que un servidor malicioso puede llevar instrucciones ocultas. Los clientes tienen razón al ser cautelosos, y un negocio también debería serlo.

Pero observa dónde debe residir la cautela. No puede residir en el modelo, que es la parte que podría estar equivocada. Debe residir en el software, que es exactamente donde el buen software ya lo ha colocado para los usuarios humanos. Validación, permisos, umbrales de aprobación, deshacer, auditoría: cada uno de esos existe porque el usuario anterior también cometió errores, con confianza, en una escritura. El software nativo de agentes toma esa antigua disciplina en serio en cada acción en lugar de en las pocas que el diseñador de la pantalla recordó, y la aplica a un usuario que llamará a cien herramientas antes del almuerzo.

Una segunda objeción es el determinismo. Algunos trabajos deben producir la misma salida para la misma entrada, de manera demostrable, cada vez. Ese trabajo debe permanecer como un flujo de trabajo fijo, y el agente debe llamar al flujo de trabajo como una herramienta en lugar de improvisarlo. El juicio no reemplaza las reglas aquí; el sistema necesita ambos, expuestos a un usuario que pueda diferenciarlos.

Quién lo construye y para quién

La última consecuencia es la que el emprendedor debería notar. Si el usuario del software puede ser un agente, el constructor también puede serlo. Un desarrollador describe la aplicación que quiere a un agente que ya tiene, el agente la construye utilizando un conjunto de herramientas de construcción, el desarrollador la valida localmente y la publica, y desde el primer día cada herramienta que la aplicación envía está disponible para cada otro agente en la plataforma. El negocio que la instala no aprende sus pantallas; su personal trae el agente que ya utiliza y describe el resultado. Esa es la disposición en la que se basa Sois, ofrecida aquí como una implementación del argumento en lugar de como su conclusión.

La conclusión es más simple. Durante cuarenta años, la pregunta que un diseñador de software se hacía era qué necesita ver la persona al otro lado. El siguiente usuario no ve. Lee un contrato y llama a lo que se le permite llamar, y lo hará en nombre de las mismas personas para las que se construyeron las pantallas. El software que trata a ese usuario como un ciudadano de primera clase se operará con fluidez. El software que mantiene la pantalla como su única puerta seguirá siendo operado, a través de una mirilla, por un agente que lleva un disfraz, hasta que sus propietarios se cansen del disfraz y se muevan.

Este artículo se revisa cuando cambian los productos que describe. Próxima revisión programada: 4 de diciembre de 2026.