Mejor software de ERP agentivo: qué buscar

Por qué no hay clasificación aquí

Imagina la lista corta. Cuatro proveedores, cuatro propuestas y la palabra agentic en cada portada. Uno es un conjunto establecido con un asistente agregado el año pasado. Uno es un producto más nuevo construido alrededor de su propio agente. Uno es una plataforma que permite a cualquier agente conectarse a través de un protocolo abierto. Uno es una herramienta de flujo de trabajo con un modelo de lenguaje en el medio. Los cuatro se demuestran bien. Dos de ellos aún esperarán a una persona en la pantalla para cualquier cosa que cruce un límite de módulo, y no descubrirás cuáles son esos dos en las propuestas.

Una lista clasificada no puede ayudar con eso, por una razón que no tiene nada que ver con la calidad de los productos. La agenticidad es una propiedad de la arquitectura, y si una arquitectura determinada es adecuada para ti depende de qué módulos utilices, qué agente ya usa tu equipo, cuáles son tus umbrales de aprobación y cuánto necesitas ver en el registro. Esos son tus hechos, no los de un revisor. Lo que viaja entre empresas es el conjunto de pruebas, así que esta página te proporciona las pruebas y te pide que hagas la clasificación.

Prueba 1: protocolo abierto, tu agente desde afuera

La primera prueba es si un agente que el proveedor no construyó puede operar el sistema. El estándar abierto para esto es el Model Context Protocol, que los clientes de agentes convencionales utilizan: Claude agrega un servidor MCP remoto como un conector personalizado con un inicio de sesión OAuth; ChatGPT hace lo mismo en modo desarrollador con soporte completo de lectura y escritura; los agentes de codificación y los agentes internos construidos sobre los SDK del proveedor se conectan de la misma manera. Un producto que habla MCP puede ser operado por cualquiera de ellos. Un producto que solo funciona con su propio asistente no puede ser operado por nadie más, y esa decisión se ha tomado por ti.

La evidencia que se debe solicitar es la respuesta del servidor a una solicitud de herramientas/lista, que bajo el protocolo es la lista legible por máquina de todo lo que el agente puede hacer. Debería verse algo así, repetido para cada acción en el sistema.

{
  "tools": [
    {
      "name": "contacts.search",
      "description": "Find contacts by name, email or company.",
      "inputSchema": { "type": "object", "properties": { "query": { "type": "string" } }, "required": ["query"] }
    },
    {
      "name": "invoices.create",
      "description": "Create a draft invoice from billable lines. Fails if the caller cannot raise invoices.",
      "inputSchema": { "type": "object", "properties": { "customer_id": { "type": "string" }, "lines": { "type": "array" } }, "required": ["customer_id", "lines"] }
    },
    {
      "name": "purchase_orders.approve",
      "description": "Approve a purchase order within the caller's approval limit.",
      "inputSchema": { "type": "object", "properties": { "purchase_order_id": { "type": "string" } }, "required": ["purchase_order_id"] }
    }
  ]
}

Una respuesta ilustrativa de herramientas/lista en la forma que define la especificación de MCP. Los nombres y la cobertura variarán según el producto; lo que importa es que la lista exista, esté tipificada y sea lo suficientemente larga para cubrir los módulos que utilizas.

Tres cosas que verificar en la lista. Es larga, porque un ERP tiene cientos de acciones y una lista de veinte significa que el asistente alcanza veinte funciones. Está tipada, con un esquema JSON para cada entrada, porque eso es lo que permite al servidor validar las llamadas en lugar de interpretar prosa. Y cambia cuando un usuario más restringido inicia sesión, lo que es el puente hacia la segunda prueba.

Prueba 2: permisos por usuario en cada llamada

An agent that can do more than the person it represents is a liability, not a feature. The second test is whether permissions are enforced per user and per call, not per product or per session. The protocol allows a server to vary the tool list by the authorisation presented and requires servers to implement proper access controls, but it cannot enforce either on the vendor's behalf. The good implementations filter the list before the agent sees it and then check again when each tool runs, because a filtered list is a courtesy and an execution-time check is a control.

La evidencia es una negativa en vivo. Inicia sesión como un usuario que no puede aprobar órdenes de compra, pide a su agente que apruebe una, y observa lo que sucede. La respuesta correcta es una negativa clara en el momento de la llamada, registrada, mientras el resto de la solicitud sigue completándose. Las respuestas incorrectas son una aprobación que se procesa, un error que revela lo que la herramienta habría hecho, o una sesión que falla en abrir porque la verificación solo estaba en la pantalla.

Prueba 3: transparencia de presupuesto y costos

Un agente que razona sobre los modelos del proveedor consume algo cada vez que se ejecuta, y la tercera prueba es si puedes limitar ese gasto y ver a dónde fue. El mecanismo específico importa menos que las dos propiedades: un límite establecido por integración o por clave que el agente no puede exceder, y un registro por acción de lo que costó cada ejecución. Un producto que solo puede decirte el total mensual después del hecho no ha construido el medidor, y lo descubrirás cuando un bucle descontrolado o un nuevo usuario entusiasta llegue a la factura.

Hay una segunda pregunta de costo que las páginas de clasificación omiten por completo. Si el producto te permite traer tu propio agente, entonces cuando ese agente realiza el razonamiento, el proveedor puede no realizar ninguna IA en tu nombre y no cobrar nada por ello. Para un equipo que ya paga por Claude o ChatGPT, eso convierte el costo del agente en una línea que tú controlas en lugar de una línea que establece el proveedor. Pregunta a cada proveedor cuánto cobran cuando tu propio agente hace el razonamiento y anota la respuesta.

Prueba 4: auditoría que se lee como el registro de una persona

Cuando un agente realiza el trabajo, el registro se convierte en la forma principal en que un gerente lo revisa, por lo que la cuarta prueba es si la pista de auditoría registra las acciones del agente tan completamente como las de una persona. Lo mínimo es quién preguntó, qué agente actuó en su nombre, qué herramientas se ejecutaron, con qué entradas, con qué resultado y cuándo. La propia guía del protocolo indica que los clientes deben registrar el uso de herramientas para auditoría; el servidor debería hacer lo mismo desde su lado, porque es el servidor el que sabe qué cambió realmente.

La evidencia es el registro en sí, después de la solicitud de demostración. Ábrelo y verifica cuatro cosas: atribución a una persona, no a un usuario de integración genérico; la secuencia de llamadas a la herramienta, no solo los registros que terminaron cambiados; entradas y resultados, para que una acción incorrecta pueda ser rastreada a una entrada incorrecta; y rechazos, porque un modelo de permisos que no registra sus denegaciones no puede ser ajustado.

Prueba 5: un mercado, y lo que te dice

La quinta prueba es indirecta pero reveladora. Si una plataforma tiene un mercado de aplicaciones construidas por personas distintas al proveedor, y esas aplicaciones son operadas por agentes a través de la misma interfaz de herramienta que los módulos centrales, entonces la interfaz de herramienta es real, documentada y lo suficientemente estable para que los externos construyan sobre ella. Un mercado es la propia arquitectura del proveedor siendo probada por extraños todos los días. También responde a la pregunta práctica de qué sucede cuando necesitas una capacidad que el producto central no tiene: si esperas el plan de desarrollo, pagas por trabajo personalizado o instalas algo que ya existe.

La evidencia es una aplicación publicada de un tercero, instalada en tu espacio de trabajo de prueba, que aparece en la lista de herramientas del agente en la siguiente solicitud. Si el mercado existe pero las aplicaciones son todas del proveedor, o si instalar una no cambia lo que el agente puede hacer, la prueba solo se ha pasado a medias.

El tablero de puntuación

Lleva esto a cada demostración y complétalo el día de la presentación. Califica cada prueba como aprobada, parcial o fallida, e insiste en ver la evidencia en lugar de escuchar sobre ella. Un producto que falla la primera prueba es un producto con un asistente, sea lo que sea que diga la portada, y las otras cuatro pruebas se vuelven académicas.

Sois es una implementación contra la que puedes realizar estas pruebas, y dado que lo construimos, podemos decir cómo responde. Un espacio de trabajo es un servidor MCP; cualquier cliente compatible se conecta agregando la dirección del espacio de trabajo e iniciando sesión una vez a través de OAuth, sin necesidad de pegar un token. Las herramientas se filtran según el rol del usuario antes de ser ofrecidas y se verifican nuevamente cuando se ejecutan, y el acceso falla cerrado. El gasto puede ser limitado por integración, cada acción se registra, y cuando tu propio agente realiza el razonamiento, la plataforma no realiza ninguna IA en tu nombre y no cobra nada por ello. Los desarrolladores crean aplicaciones con su propio agente, validan localmente de forma gratuita y publican en un mercado donde cada agente conectado puede llamarlas. Realiza las mismas cinco pruebas contra él que contra los demás; para eso están.

Preguntas que la gente hace

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