EPISODIO 1: EL INICIO: CUANDO LA IA EMPIEZA A HABLAR CON TU ERP

Como siempre, empecemos por el origen del universo, no? 😉

El Model Context Protocol (MCP) define el formato y las reglas para el intercambio de solicitudes y respuestas, de modo que un agente o una aplicación basada en LLM pueda interactuar con un sistema externo de forma estructurada. En lugar de utilizar APIs o integraciones personalizadas, MCP ofrece un marco unificado que estandariza los accesos. En síntesis, es un conector que le permite a los modelos de IA hablar con otras aplicaciones, de manera segura.

En D365FnO, tenemos el Dynamics 365 ERP MCP, un servicio que implementa MCP, y proporciona un marco dinámico para que los agentes (en nuestro caso lo utilizamos con Copilot Studio) realicen operaciones sobre datos y accedan a la lógica de negocio de las aplicaciones.

Entonces, MCP es el mecanismo que hace posible que un agente pase de “responder sobre FnO” a trabajar con FnO mediante herramientas, usando datos reales y  respetando el contexto definido, y por supuesto sin olvidarnos de la seguridad.

Seguramente habrán visto la siguiente imagen:

El verdadero valor de un agente no es solo “responder preguntas”, sino hacer trabajo de forma controlada. Nuestro agente conectado al MCP de FnO puede consultar información, navegar por el contexto correcto y ejecutar acciones disponibles (siempre dentro de permisos y reglas definidas) de manera autónoma.

En la práctica, los agentes se suelen implementar en un espectro de capacidades:

El agente usa herramientas para leer datos reales del ERP, “razona” las preguntas, y devolver resultados estructurados (listas, resúmenes, comparativas).

Por ejemplo el prompt: he recibido un cobro de Orange por X dinero y no sé a qué transacciones puede estar pagando, necesito que revises todas las facturas abiertas del cliente en todas las empresas y me digas cuáles son las que paga.

Acá el agente no solo consulta: toma acciones a pedido del usuario y ayuda a reemplazar pasos/tareas repetitivas.

En un escenario bien diseñado, podemos crear transacciones.

Por ejemplo seguimos nuestro ejemplo con el prompt: créame un diario de cobros que liquidar las facturas de Orange, con el Banco X, sólo en USMF.

En este nivel el agente pueda planificar y ejecutar revisiones recurrentes, detectar excepciones y escalar casos. Así también, es capaz de “entender” las funcionalidades y aprender cuando solicitamos un determinado comportamiento.

En este punto no le decimos lo que queremos que haga, es capaz de detectar qué debe hacer y ejecutarlo de manera independiente. Eso sí, es importante entender que en Finance debemos trabajar con cuidado, porque hay control interno, permisos de usuarios y riesgos: Por ejemplo, debemos cuidarnos de los pagos o salidas de dinero sin aprobaciones, registro de transacciones de manera autónoma, cierres de períodos contables, visualización de datos sensibles.

El agente puede orquestar varias tareas, pero es importante que delegue y/o nos avise cuando necesite autorización.

Espero que ya se estén entusiasmando con la serie, porque en el próximo capítulo entran en escena los protagonistas: Episodio 2: El reparto: Instrucciones, Modelos & Herramientas 👉🏻


Deja un comentario