Economía de agentes: cómo conectar IA y gestión empresarial

La conversación sobre agentes de IA suele empezar por lo que podrían hacer. Para una empresa, la pregunta útil es otra: ¿qué contrato, credencial y revisión necesita cada acción? Sin esas tres piezas, una demostración llamativa no se convierte en un proceso fiable.

Un asistente puede explicar cómo preparar una factura. Un agente conectado a herramientas puede consultar un cliente, proponer los campos de una operación o enviar una solicitud a una API. Esa diferencia aumenta la utilidad, pero también el impacto de una instrucción ambigua. Por eso conviene separar claramente lectura, propuesta y ejecución.

De la conversación a una herramienta concreta

Un sistema de IA no debería “entrar en el ERP” de forma genérica. Debe seleccionar una herramienta con un nombre, una descripción y unos argumentos definidos. Después, el sistema empresarial valida la autenticación, procesa la solicitud y devuelve un resultado estructurado.

Ese contrato permite responder preguntas esenciales:

• ¿la operación solo consulta o también modifica datos?;
• ¿sobre qué cuenta y recurso trabaja?;
• ¿qué campos son obligatorios?;
• ¿qué errores puede devolver?;
• ¿quién revisa el resultado antes del siguiente paso?

Cuanto más sensible sea la acción, menos útil resulta una promesa de autonomía genérica. Crear un borrador, emitir un documento y enviar una comunicación son decisiones distintas. Un flujo responsable las modela por separado.

MCP como capa de herramientas

MCP ofrece un protocolo común para que un cliente descubra herramientas y les pase argumentos. No reemplaza la lógica del ERP ni convierte una salida del modelo en un dato correcto por defecto. El servidor expone el contrato; la aplicación mantiene sus reglas; la persona conserva la decisión sobre los cambios que lo requieran.

Frihet publica un servidor MCP oficial cuyo contrato actual incluye 157 herramientas agrupadas en 17 familias, 11 recursos y 10 prompts. Las familias abarcan clientes, facturas, gastos, productos, presupuestos, webhooks, CRM y otras áreas registradas en el manifiesto de producto.

La disponibilidad de una herramienta indica que existe una operación programática. No implica que cualquier cliente tenga acceso automático, que todos los campos puedan inferirse o que el resultado deba confirmarse sin revisión.

API y webhooks: otras piezas del mismo sistema

Frihet también publica una API REST documentada con autenticación por API key. Una integración puede utilizarla directamente cuando necesita un flujo determinista. El sistema de webhooks, con 94 tipos de eventos y verificación HMAC-SHA256, permite notificar cambios a otros servicios.

Cada superficie tiene una función distinta:

• MCP: descubrimiento e invocación de herramientas desde un cliente compatible.
• API: integración programática controlada por código.
• Webhooks: notificación de eventos para iniciar otro proceso.

Combinar estas piezas requiere diseñar el flujo. Un webhook no crea por sí solo la acción posterior; un agente no obtiene permisos por conocer el nombre de una herramienta; una API key no decide qué operaciones son apropiadas.

Un modelo de control en tres niveles

Nivel 1: consultar

Las primeras tareas deberían ser reversibles y de lectura: localizar un cliente, listar facturas por estado o revisar gastos de un periodo. Comprueba que la respuesta corresponde con la cuenta, filtros y fechas esperados.

Nivel 2: preparar

El agente puede reunir argumentos y presentar una propuesta: campos de una factura, filtros de un informe o texto de un borrador. En este nivel todavía no cambia el registro principal. La persona revisa información fiscal, importes, destinatarios y contexto.

Nivel 3: ejecutar

Una escritura en el ERP, un envío externo o una acción con consecuencias financieras necesita una confirmación explícita conforme al proceso del negocio. El resultado debe quedar visible y cualquier error debe tener una vía de corrección.

Ejemplo: preparar una factura sin perder control

Una petición puede incluir cliente, concepto, cantidad y fecha. El cliente MCP selecciona la herramienta y muestra los argumentos. Antes de ejecutarla, el usuario verifica la identidad del cliente, moneda, impuestos y numeración. Tras la respuesta, comprueba el registro creado antes de emitir o enviar el documento.

Este patrón reduce pasos de navegación y mantiene el control en los puntos que importan. No presupone que la IA conozca el contexto fiscal ni que una conexión de herramientas sustituya la revisión profesional.

Checklist para evaluar software preparado para agentes

1. ¿Publica una API o herramientas documentadas?
2. ¿La autenticación se puede revocar y separar por entorno?
3. ¿Distingue lectura de escritura?
4. ¿Muestra argumentos antes de ejecutar?
5. ¿Devuelve resultados y errores estructurados?
6. ¿Permite insertar aprobación humana?
7. ¿Existe documentación para integrar y detener el flujo?

La economía de agentes no obliga a entregar el negocio a un sistema autónomo. Obliga a diseñar mejores contratos entre personas, modelos y software. Un ERP preparado es el que permite conectar herramientas de forma explícita, revisar decisiones y conservar responsabilidad sobre los datos.