Diseñar agentes en Business Central
Diseñar agentes en Business Centralla guía profunda para consultores funcionales
Cómo diseñar, configurar y operar agentes de IA dentro del ERP. Análisis sin marketing: AI Development Toolkit, Sales Order Agent, Payables Agent, instrucciones, permisos, logs, casos de uso y dónde empieza realmente AL.
- Introducción
- Conceptos de IA
- De Copilot a agentes
- Copilot y agentes en BC
- AI Development Toolkit
- Capacidades del consultor
- Diseño paso a paso
- Instrucciones
- Permisos y seguridad
- Tareas y ejecución
- Logs y trazabilidad
- Adjuntos
- Estándar vs propio · AL
- Casos de uso
- Buenas prácticas · errores
- Hoja de ruta · conclusión
Pasamos de asistencia (Copilot) a delegación supervisada (agentes). Hoy ya hay productos GA (Sales Order Agent y Payables Agent) y un toolkit en preview para diseñar agentes propios.
Business Central lleva ya varios ciclos de release incorporando inteligencia artificial. Copilot resume registros, sugiere líneas de venta, ayuda con la conciliación bancaria, encuentra sustitutos de producto, autocompleta campos y permite chatear sobre los datos en lenguaje natural. Esa primera ola es asistencia: el usuario sigue al volante.
La segunda ola no es asistencia: es delegación supervisada. Microsoft está incorporando agentes autónomos que, con una identidad, un perfil y unos permisos propios dentro del ERP, son capaces de leer un correo, navegar páginas, abrir documentos, validar inventario y dejar un borrador de pedido o de factura listo para que una persona lo apruebe. Hoy esos agentes ya existen como producto general (el Sales Order Agent y el Payables Agent) y, además, Microsoft ofrece a partners y consultores un entorno para diseñar agentes propios: el AI Development Toolkit, antes conocido como Agent Playground en su versión inicial.
Este artículo está pensado para usuarios clave y consultores funcionales que quieren entender, sin humo, qué representa todo esto. Vamos a separar siempre tres cosas: lo que está documentado por Microsoft, lo que es interpretación funcional propia derivada de capacidades documentadas, y lo que requiere validación en sandbox o desarrollo en AL. Si una afirmación no encaja en ninguna de las tres, no aparecerá aquí.
Cada bloque etiquetado Documentado está respaldado por documentación oficial de Microsoft Learn, Release Plans o repositorios oficiales. Los bloques Interpretación son lecturas funcionales del autor a partir de capacidades documentadas. Los bloques Aviso destacan límites, riesgos o cosas que no se deben asumir.
Antes de hablar de agentes, conviene sentar un puñado de conceptos. No por academicismo: porque cuando un consultor diseña instrucciones, decide perfiles o interpreta logs, está aplicándolos sin ser consciente.
IA generativa y modelo de lenguaje
Un modelo de lenguaje (LLM) es un sistema entrenado para predecir secuencias de texto plausibles a partir de una entrada. Copilot y los agentes de Business Central se apoyan en Azure OpenAI Service, el servicio gestionado de Microsoft sobre el que corren los modelos. Esto introduce dos cuestiones reales: geografía (el servicio puede estar en una región distinta a la de tu entorno y requerir activar movimiento de datos entre geografías) y no determinismo (un mismo prompt puede producir respuestas diferentes).
Prompt, instrucciones y contexto
El prompt es la petición concreta que recibe el modelo. Las instrucciones de un agente son un prompt persistente que lo configura: definen su responsabilidad, sus reglas y su forma de actuar. El contexto es todo lo que el modelo ve además del prompt en el momento de decidir: la página abierta, los campos visibles, los mensajes anteriores. En BC, el contexto incluye literalmente lo que vería un usuario humano con ese perfil.
Grounding o anclaje a datos
Un modelo no tiene tu base de datos memorizada: necesita que se la anclen en cada interacción. En BC ese anclaje ocurre porque el agente navega por la propia interfaz del ERP como un usuario más, lee los datos visibles y combina esa información con sus instrucciones. Eso reduce el riesgo de respuestas desconectadas de la realidad de la empresa, pero no lo elimina del todo.
Alucinaciones y respuestas incorrectas
Una alucinación es una respuesta que parece coherente pero no se sustenta en datos. Microsoft lo dice con claridad en sus notas de transparencia: los sistemas de IA son no deterministas y la precisión total no es posible. Eso obliga a poner siempre revisión humana sobre cualquier acción significativa.
Copilot vs. agente de IA
Copilot es asistencia: tú haces clic, el modelo ayuda en ese punto y devuelve sugerencias para que tú decidas. Un agente es un compañero digital que recibe un objetivo y ejecuta una secuencia de pasos hasta cumplirlo (o hasta pedir ayuda). En palabras de la documentación, los agentes pueden interpretar objetivos de negocio expresados en lenguaje natural y traducirlos en pasos accionables, siempre dentro de los límites que les marcas.
Tarea, intervención humana y aprobación
La unidad de trabajo de un agente es la tarea (Agent Task). Cada tarea sigue un ciclo: se crea, el agente ejecuta pasos, se pausa cuando necesita ayuda y reanuda cuando una persona aporta información o aprueba. La intervención humana (human-in-the-loop) está integrada en el modelo: los agentes generan notificaciones para que un usuario revise, ajuste o apruebe antes de continuar.
Permisos, perfil, log y preview
El perfil (Profile/Role) define qué interfaz ve el agente: qué páginas, qué campos, qué acciones. Los permisos (permission sets) controlan a qué datos y objetos puede acceder. El log (Agent Task Log) registra cada decisión y cada paso. Preview significa, en lenguaje Microsoft, que la funcionalidad está disponible para evaluación pero no es producción soportada: puede cambiar, fallar y, en muchos casos, está restringida a sandbox.
La diferencia se ve mirando quién hace clic: en Copilot lo hace la persona y el modelo sugiere; en un agente, la persona da un objetivo y el agente hace la secuencia de clics, con supervisión humana en los puntos clave.
La forma más honesta de explicar la diferencia es mirar el quién hace clic:
- Funcionalidad tradicional: la persona hace clic, el ERP responde. La inteligencia está en el flujo programado.
- Copilot: la persona hace clic, el modelo sugiere; la persona acepta o descarta. La inteligencia está en el momento.
- Agente: la persona da un objetivo; el agente hace clics, lee, decide, escribe; la persona supervisa y aprueba puntos clave. La inteligencia está distribuida en una secuencia.
| Concepto | Qué hace | Ejemplo | Autonomía | Control humano |
|---|---|---|---|---|
| Funcionalidad tradicional | Ejecuta lo programado | Registrar pedido, lanzar batch | Nula sobre el contenido | Total: el usuario hace cada paso |
| Copilot | Sugiere, resume, autocompleta | Conciliación, sugerencias de venta | Baja: solo propone | El usuario revisa antes de guardar |
| Agente estándar | Procesos end-to-end con supervisión | Sales Order Agent, Payables Agent | Media: opera en bucle hasta aprobar | Aprobación obligatoria en pasos clave |
| Agente diseñado por consultor | Lo que tú definas en el runtime | Sales Validation Agent (plantilla) | Media, acotada por instrucciones | Tú decides dónde pedir intervención |
| Agente desarrollado en AL | Agente productivo distribuible | BCTech Sales Validation Agent app | Alta dentro de su contrato | Lo definido en código + aprobaciones |
Hoy hay tres niveles disponibles: capacidades de Copilot (incluidas en licencia), agentes estándar Sales Order y Payables (GA, consumen Copilot Credits) y agentes diseñados por consultor con AI Development Toolkit (preview, sandbox).
Capacidades de Copilot generalmente disponibles
Microsoft documenta una lista creciente de capacidades de Copilot dentro de BC. Las más relevantes para un consultor funcional son: Chat con Copilot (búsqueda en lenguaje natural y guía de uso), Analyze data in lists, Autofill, Bank account reconciliation assist, E-document matching con líneas de pedido, Suggest lines on sales orders, Suggest item substitutions, Suggest number series, Marketing text suggestions y Summarize en factbox.
Conviene saber que Copilot va incluido en la licencia de BC sin coste adicional para estas capacidades, mientras que los agentes sí consumen Copilot Credits y requieren modelo de facturación específico.
Modelo de facturación: Copilot Credits
Los agentes (tanto estándar como custom) consumen Copilot Credits. Microsoft documenta dos modos de facturación gestionados desde el Tenant Admin Center:
- Prepaid: bloques de créditos pagados por adelantado.
- Pay-as-you-go: facturación según consumo real (modelo de referencia público a 0,01 USD por crédito).
El consumo se mide por ejecución de tarea y se ve en los logs cuando el consultor tiene asignado el set AGENT - DIAGNOSTICS. Esa es la palanca para responder a la pregunta más frecuente del cliente: "¿cuánto cuesta un agente?". La respuesta honesta es: "depende del log, mira aquí".
Sales Order Agent (GA)
El Sales Order Agent automatiza la captura de pedidos de venta a partir del correo del cliente. Monitoriza un buzón compartido (Microsoft 365), identifica al cliente o contacto a partir del remitente, busca los productos en el inventario aunque la descripción del cliente sea imprecisa, comprueba la disponibilidad, prepara una oferta como PDF, mantiene conversaciones por correo cuando faltan datos y, una vez confirmada, convierte la oferta en pedido. Cualquier correo saliente requiere revisión humana antes de enviarse.
La precisión depende fuertemente de la calidad del maestro de productos: descripciones, atributos, categorías y textos extendidos. Microsoft avisa de que tras introducir nuevos datos puede tardar hasta 15 minutos en estar indexados. El agente cuenta con su propia ficha de usuario y trae el permission set SOA AGENT - EDIT (un set de sistema que no puedes modificar; sí puedes copiarlo y ampliarlo).
Payables Agent (GA, avanzado en preview)
El Payables Agent automatiza el procesado de facturas de proveedor. Monitoriza un buzón, captura los PDFs, extrae los datos con Azure Document Intelligence, identifica al proveedor (incluyendo coincidencia por NIF/VAT/GLN o búsqueda IA en el histórico), sugiere clasificación contable a partir de tu plan de cuentas y del histórico, y deja preparado un borrador de factura de compra para que el supervisor del agente apruebe.
Tiene límites duros documentados que conviene memorizar:
- Solo procesa correos con adjuntos PDF.
- Salta correos con más de 10 adjuntos.
- No procesa PDFs con más de 10 páginas.
- No procesa PDFs de más de 5 MB.
- Hasta 100 correos al día.
- Solo soporta inglés en su versión actual.
Si el proveedor no se identifica con confianza, el agente puede crearlo en estado bloqueado con los datos de OCR, a la espera de validación humana antes de poder operar con él. Esa decisión de diseño es muy interesante para un consultor: el agente no solo automatiza, también incorpora controles que un usuario apresurado podría saltarse.
Novedades del Wave 1 2026
El plan de release de 2026 wave 1 (versión 28) introduce mejoras concretas: panel de tareas dedicado para revisar todas las tareas de todos los agentes en un único lugar, revisión del contenido generado en la propia página donde se actúa, capacidad de detener todas las tareas de un agente, indicadores Created by/Modified by que dejan claro qué tocó la IA y, a nivel de plataforma, mejoras del MCP Server (Model Context Protocol) para integrar Copilot Studio con BC sin tanto pegamento custom. La cobertura de comunidad menciona también un Expense Agent y la disponibilidad general del diseñador de agentes en mayo de 2026.
Disponibilidad geográfica y por idioma: cada capacidad de Copilot y cada agente declara sus regiones e idiomas soportados. Copilot y agentes solo están disponibles en Business Central online, no en on-premises. La AI Development Toolkit y los agentes personalizados están en preview y limitados a sandbox; para diseño de agentes Microsoft documenta como prerrequisito un sandbox sobre versión 27.2 (con custom agent capability) o 27.4 según la fuente.
- Copilot (capacidades) → incluido en licencia · sin Copilot Credits.
- Sales Order Agent y Payables Agent → GA · consumen Copilot Credits · modelo prepaid o pay-as-you-go.
- AI Development Toolkit → preview · solo sandbox · BC 27.2/27.4 · solo inglés con plena precisión.
- Wave 1 2026: panel de tareas dedicado · revisión inline · stop-all · Created/Modified by AI · mejoras MCP Server.
Tres reglas que no se negocian: solo sandbox, el agente nunca tiene más permisos que su creador, y el agente solo ve lo que ve un usuario con su perfil. Si las recuerdas, no te equivocas con el toolkit.
El producto se llama AI Development Toolkit en su forma actual; en versiones tempranas se documentaba como Agent Playground o, en el plan de release, como agent design experience. Es un entorno integrado en BC que permite, sin escribir AL, crear un agente, darle instrucciones en lenguaje natural, asignarle un perfil y unos permisos, lanzar tareas de prueba e inspeccionar todo lo que hace. La documentación oficial deja muy claro a quién va dirigido: product owners, expertos de dominio, consultores y desarrolladores que quieren prototipar capacidades de IA.
Hay tres limitaciones de diseño que un consultor debe interiorizar antes de empezar:
- Solo sandbox: nunca producción. Esto incluye sandbox con copia de datos productivos, lo que es coherente con el carácter exploratorio.
- Herencia de permisos: un agente no puede tener más permisos que su usuario creador. Si tú no ves la página, el agente tampoco. Y al revés: si el agente tiene permisos sobre algo que tú no, esa acción se denegará en ejecución.
- Solo ve lo que ve un usuario con su perfil: el agente interactúa con la UI. No usa Tell me, no abre tablas directamente, no se inventa accesos. Si la página muestra dos sublistas, solo puede operar sobre una a la vez.
Relación con AI Development Toolkit y AL
El AI Development Toolkit es el mismo conjunto de herramientas que usan tanto la experiencia de diseño desde la UI como el SDK de AL. Cuando un consultor configura un agente desde el wizard, está usando capacidades del toolkit; cuando un desarrollador escribe AL, las mismas capacidades. La frontera entre prototipo funcional y solución productiva no es de tecnología, es de empaquetado, distribución y madurez: el toolkit en UI está pensado para prototipar; AL te permite empaquetar el agente como app y distribuirlo. La documentación pone esto en blanco sobre negro al hablar de "Convert an agent created in the UI to code".
Reparto de roles: el consultor funcional diseña instrucciones, perfil y permisos en sandbox; el administrador BC habilita capacidad y facturación; el desarrollador AL empaqueta el prototipo validado para producción. Cada cosa en su sitio.
Esta es probablemente la sección más importante del artículo, porque hay mucho marketing alrededor. Voy a separar lo que la documentación oficial confirma que un consultor puede hacer, lo que requiere apoyo del administrador, lo que requiere desarrollo y lo que simplemente no está disponible aún.
Lo que un consultor puede hacer directamente (con AGENT-ADMIN en sandbox)
- Crear un agente desde cero o desde la plantilla Sales Validation.
- Definir su nombre, display name, iniciales y descripción.
- Asignarle un perfil (role) existente o uno construido específicamente para él.
- Asignarle permission sets dentro del límite de los permisos del propio consultor.
- Redactar las instrucciones en lenguaje natural y descargarlas.
- Crear tareas manuales desde la página Agent Tasks para probar el comportamiento.
- Acompañar la ejecución y responder a las solicitudes de intervención.
- Revisar el Agent Task Log entrada a entrada para entender qué decidió y por qué.
- Ajustar instrucciones, perfil o permisos e iterar (el modelo es iterativo por diseño).
- Exportar e importar la configuración del agente para moverla entre entornos sandbox.
Lo que requiere coordinación con administración o seguridad
- Activar la Custom Agent capability en Copilot & agent capabilities (puede requerir SUPER o licencias específicas).
- Asignar al consultor el set AGENT - ADMIN y, si quiere ver costes y diagnósticos detallados, AGENT - DIAGNOSTICS.
- Configurar el modelo de facturación de agentes en el tenant (Copilot Credits, prepaid o pay-as-you-go).
- Configurar el movimiento de datos entre geografías cuando aplique.
- Modificar permission sets de sistema (no se pueden tocar; hay que copiarlos).
Lo que requiere desarrollo en AL
- Disparar el agente automáticamente desde un evento de negocio (recepción de correo en cuenta no monitorizada por agentes estándar, OnAfterInsert sobre una tabla, OnPost de un documento, una cola de tareas, etc.).
- Empaquetar el agente como una app distribuible en AppSource o como extensión interna (define enums, interfaces IAgentFactory e IAgentMetadata, registra capacidad, carga instrucciones como recurso embebido).
- Crear tareas de forma programática con Agent Task Builder y Agent Task Message Builder.
- Integrar el agente con flujos custom de aprobación.
- Llevar el agente a producción (la UI de diseño hoy es solo sandbox).
Lo que el consultor NO debería prometer hoy
- Que el diseño desde UI vaya a producción tal cual: no va.
- Que el agente personalizado funcione fuera del inglés con la misma precisión: el toolkit soporta oficialmente solo inglés en preview.
- Que un agente personalizado vaya a integrarse automáticamente con eventos sin AL: no, requiere desarrollo.
- Disponibilidad de la AI Development Toolkit en cualquier entorno: hoy es preview, sujeta a cambios y requiere versión y configuración compatibles.
- Consultor funcional: identidad, perfil, permisos mínimos, instrucciones, pruebas, iteración en sandbox.
- Administrador BC: capacidad activada, AGENT-ADMIN/DIAGNOSTICS, modelo de facturación, geografías.
- Desarrollador AL: empaquetado como app, disparos automáticos, distribución, producción.
- No prometer: producción desde sandbox · auto-trigger sin AL · plena precisión fuera de inglés.
Este es el flujo que un consultor sigue dentro de la experiencia documentada. Lo que sigue combina los pasos del wizard Create agent, las recomendaciones de Microsoft sobre instrucciones e iteración, y experiencia de proyecto.
Una instrucción se puede ignorar. Un permiso no. Por eso la regla es: deniega por permiso lo sensible y guía con instrucciones lo demás. Estructura recomendada: Responsibilities · Guidelines · Instructions.
Las instrucciones son, junto con perfil y permisos, el corazón de un agente. Son un texto en lenguaje natural que define qué responsabilidad tiene el agente, qué reglas debe seguir y qué pasos debe ejecutar. Microsoft propone una estructura de tres bloques que es muy útil porque obliga a pensar como un manual operativo:
Responsibilities · Guidelines · Instructions
- Responsibilities: el alcance. Qué se espera que haga el agente. Por ejemplo: gestionar recordatorios de cobro, validar pedidos abiertos, procesar abonos.
- Guidelines: reglas transversales. Por ejemplo: siempre solicitar revisión humana antes de registrar documentos o enviar comunicaciones externas.
- Instructions: pasos ordenados, con sub-pasos. Aquí entran los flujos concretos.
Por qué las instrucciones NO sustituyen a los permisos
Una instrucción es un consejo redactado a un sistema no determinista. Un permiso es una barrera del motor de Business Central. Una instrucción puede ignorarse; un permiso no. Por eso la documentación advierte explícitamente: las instrucciones no son una sustitución de los permisos. La regla de oro es denegar por permiso lo que sea sensible y guiar con instrucciones lo demás.
Palabras clave y patrones documentados
Microsoft documenta keywords específicas que el agente reconoce. Aparecen en la página oficial Instruction keywords for an agent (preview) y la comunidad ha consolidado patrones útiles:
- MEMORIZE: pedir al agente que recuerde un valor concreto entre pasos. Ejemplo documentado: Memorize the external document reference from the newly created sales quote for use in follow-up communications.
- Reply: indicar al agente que responda en una conversación.
- Request a review o Ask for assistance: pedir intervención humana.
- DO NOT, ALWAYS, MUST en mayúsculas: para enfatizar reglas críticas. Patrón documentado: DO NOT proceed until the requested date is entered.
Cómo redactar instrucciones que funcionan
La guía oficial de Write effective instructions insiste en algo muy útil: empieza por un borrador en lenguaje natural sin preocuparte del formato, después usa la propia IA para estructurarlo, prueba e itera. Recomendaciones concretas:
- Referenciar nombres reales de páginas, campos y acciones que el agente verá según su perfil.
- Validar entradas antes de operaciones críticas.
- Usar mayúsculas para puntos de validación críticos.
- No repetir información ya disponible en tooltips o descripciones de campo.
- Mantener instrucciones agnósticas al entorno: el control entorno-específico es el perfil y los permisos, no el texto.
- Inglés rinde mejor: el modelo se entrena prioritariamente con inglés. Puedes escribir en español, pero perderás precisión.
Doble capa: una acción se permite solo cuando los permisos del agente Y los del usuario que lanza la tarea la autorizan. Es una intersección, no una unión.
Si solo tuvieras que recordar una idea de este artículo, sería esta: el agente actúa con dos capas de control. La primera son sus propios permission sets. La segunda es el usuario que ejecuta la tarea. Solo se permite la acción cuando ambas capas la autorizan.
Microsoft lo expresa con tres ejemplos muy claros en la documentación de Set up agent permissions and profiles:
- El agente no puede borrar clientes ni registrar pedidos si el agente no tiene esos permisos, aunque los tenga el usuario.
- El agente no puede leer artículos si el usuario no los puede leer, aunque los tenga el agente.
- Los permisos son por compañía: si el agente no tiene permisos en una compañía, ni siquiera aparece en el role center de esa compañía.
Perfil (role)
El perfil es el filtro de UI. Definir un perfil específico para el agente es buena práctica documentada: control de acciones visibles, layouts, vistas y operaciones (insert, delete). El perfil define también el role center de partida cuando ejecuta una tarea. La razón es operativa: el agente no usa Tell me y solo opera sobre lo que ve. Si la página oculta el campo Balance, el agente no podrá usarlo, por mucho que las instrucciones lo mencionen.
Mínimo privilegio
El principio recomendado por Microsoft es least privilege: dar solo los permisos imprescindibles. Esto significa, en la práctica, partir de un permission set vacío y añadir lo justo, no copiar SUPER y quitar.
Quién revisa qué
- El consultor funcional revisa que el perfil deje visibles las páginas y acciones necesarias y nada más.
- El administrador revisa que el agente tenga AGENT - ADMIN bien aplicado, que los permission sets correspondan al alcance, y que los usuarios supervisores estén configurados.
- El negocio valida que las acciones que puede ejecutar el agente son aceptables a la luz del proceso real.
Aprobaciones de Business Central
Algo que la documentación señala explícitamente y que muchos pasan por alto: los flujos de aprobación de Business Central funcionan también para los agentes. Se pueden configurar para que un cambio hecho por el agente tenga que ser aprobado por otro usuario antes de aplicarse. Para casos sensibles, esto añade una segunda red sobre la red propia del agente. Para un consultor, integrar agentes con aprobaciones existentes es un quick win conceptual: aprovechas un mecanismo que el negocio ya conoce.
- Permisos = barrera; instrucciones = consejo. Lo sensible se deniega por permiso.
- Doble capa: una acción se permite solo cuando agente Y usuario la autorizan.
- Perfil acotado: el agente solo opera sobre lo que ve. Sin Tell me, sin acceso directo a tablas.
- Mínimo privilegio: partir de cero y añadir lo justo. Nunca SUPER menos algo.
- Aprobaciones BC: úsalas como segunda red sobre la propia del agente.
En preview, los agentes custom no se disparan automáticamente sin AL: tareas manuales para probar, Tasks AL API (Agent Task Builder) para integrarlos con eventos en producción.
Una Agent Task es una unidad de trabajo concreta. Cada tarea tiene mensajes asociados (entrantes, salientes, internos), un estado (running, paused, stopped, complete) y un log detallado. Hay dos formas documentadas de disparar tareas:
- Manualmente desde la página Agent Tasks, con la acción Create task. Muy útil para pruebas funcionales.
- Programáticamente a través de la Tasks AL API: codeunits Agent Task Builder y Agent Task Message Builder. Esto permite integrarse desde acciones de página (un botón Send to Agent), desde event subscribers (OnAfterInsert, OnPost, etc.) o desde job queues programadas.
Lo que un consultor funcional debe saber sin ser desarrollador: en preview, los agentes personalizados no se disparan automáticamente desde correo, eventos o tiempos sin AL. Microsoft lo dice expresamente. Para simular esos disparadores en pruebas, se pueden incluir cabeceras y cuerpos de correo dentro del mensaje de la tarea, lo cual es suficiente para validar comportamiento, no para promesas de producción.
El ciclo típico de una tarea con intervención humana es: creada → el agente empieza → toma decisiones consultando UI y memoria → llega a un punto que requiere revisión → pasa a Paused → un humano aporta información, edita el borrador o aprueba → Resume → continúa hasta finalizar o pausarse de nuevo. Cada paso queda registrado.
Sin AGENT - DIAGNOSTICS y sin lectura del Agent Task Log estás a ciegas. Si el agente falla, regla de oro: ajusta primero las instrucciones, luego perfil/permisos, y sólo al final el código.
El log no es un detalle: es la diferencia entre un agente auditable y profesional y un asistente que "a veces hace cosas raras". Microsoft documenta el Agent Task Log como herramienta principal de troubleshooting. Cada entrada describe lo que ocurrió: si fue un punto de decisión del agente, una intervención humana, un mensaje recibido, o una parada por incumplir restricción.
Qué permite ver el log
- La acción decidida en cada decision point.
- La página tal y como la vio el agente (con AGENT - DIAGNOSTICS), incluyendo qué elementos estaban visibles y qué valores tenían.
- La pila de páginas: qué pantallas tenía abiertas el agente cuando tomó la decisión.
- Las herramientas que tenía disponibles en ese momento (lookup, set field, invocar acción).
- Lo que memorizó.
- El coste en Copilot Credits de la ejecución.
Para un consultor funcional, el log es la herramienta de diagnóstico número uno. Si el agente no entra a una página, normalmente es perfil; si entra pero no actúa, normalmente son instrucciones; si actúa mal, suele ser un texto ambiguo o un nombre de campo repetido en cabecera y líneas. La regla de oro de la comunidad reconocida sobre BC agents lo dice claro: si el agente se equivoca, primero ajusta las instrucciones, no el código.
Los agentes pueden trabajar con adjuntos en sus tareas, pero con límites claros documentados:
- Tipos soportados: PDF, PNG, JPG, JPEG.
- El agente extrae texto de PDFs e imágenes; no trabaja con la imagen como tal.
- Los PDFs de hasta 10 páginas se procesan completos.
- Si necesitas escenarios más sofisticados (por ejemplo, un analizador custom de Azure AI Document Intelligence con campos específicos), Microsoft documenta la posibilidad de pre-procesar el documento en AL y pasar al agente solo los datos extraídos relevantes.
Para el Payables Agent específicamente, los límites añadidos (10 adjuntos por correo, 5 MB, 100 correos al día) marcan el dimensionado. Es información que el consultor debe llevar a cualquier conversación con un cliente que procese alto volumen.
Los agentes estándar son productos terminados con configuración acotada. Los agentes propios te dan libertad total dentro del runtime, pero la calidad depende de tus instrucciones, perfil y permisos.
- Buzón monitorizado M365
- Identifica cliente por remitente
- Busca productos en maestro
- Conversa si faltan datos
- Oferta → pedido tras confirmación
- Permisos: SOA AGENT-EDIT (sistema)
- No modificable bajo el capó
- Calidad depende del maestro de productos
- OCR con Azure Document Intelligence
- Identifica proveedor por NIF/VAT/GLN
- Sugiere cuentas según histórico
- Borrador para aprobación supervisor
- Vendor bloqueado si no se identifica
- Solo PDF · max 10 pág · 5 MB · 100/día
- Solo inglés actualmente
- No modificable bajo el capó
- Plantilla Sales Validation o desde cero
- Tú defines identidad, perfil, permisos
- Tú redactas Responsibilities/Guidelines/Instructions
- Soporta export/import entre sandbox
- Disparo manual o vía Tasks AL API
- Sin auto-trigger por eventos sin AL
- Inglés con plena precisión
- Producción → empaquetar como app AL
El consultor funcional debe entender que Sales Order Agent y Payables Agent no son configurables al mismo nivel que un agente propio. Son productos terminados con configuraciones acotadas: buzón monitorizado, aprobación de mensajes salientes, reglas de revisión, dominios permitidos en Sales Order, campos adicionales a auto-rellenar en Payables. Lo que pone bajo el capó (qué páginas usa, cómo razona) es responsabilidad de Microsoft.
Los agentes diseñados con la AI Development Toolkit son lo opuesto: tú defines todo dentro de las capacidades del runtime. Eso te da flexibilidad pero también responsabilidad: la calidad del comportamiento depende de la calidad de tus instrucciones, perfil y permisos.
Qué puede aprender un consultor mirando los estándar
- Patrón de revisión humana obligatoria en outputs externos (correos al cliente, registros contables).
- Estado bloqueado por defecto para entidades creadas con datos incompletos (Payables crea proveedores bloqueados).
- Buzón dedicado y aislado: el agente no comparte buzón humano para evitar lecturas cruzadas.
- Métricas y panel propio: cada agente estándar tiene su pestaña de métricas operativas.
- Plantillas de tarea: poder guardar tareas como plantillas para repetir patrones.
Esos cinco patrones se pueden replicar en agentes propios sin esperar a que la documentación los nombre. Es buena práctica derivada de capacidades documentadas.
La plantilla Sales Validation
Microsoft proporciona una plantilla oficial llamada Sales Validation Agent que valida pedidos de venta abiertos para una fecha de envío dada, comprueba reservas de inventario y libera los que cumplen criterios. Las instrucciones por defecto recorren cada pedido en orden estricto: abrir Statistics, verificar reserva de stock, comprobar shipping advice, decidir si liberar según las reglas. Es un excelente material de estudio para entender cómo Microsoft escribe instrucciones operativas. Y existe también el repositorio público BCTech con el agente packageado como app, que muestra el camino completo de prototipo a producto.
El diseño funcional sirve para prototipar, validar y demostrar valor. Para producción hoy entra AL: empaquetado como app, disparos automáticos por eventos, distribución por AppSource, versionado de instrucciones.
Hay una respuesta corta y honesta a esta pregunta: el diseño funcional vale para prototipar, validar la idea y demostrar valor. Para producción, hoy entra AL.
Las razones son:
- La AI Development Toolkit es preview y solo sandbox.
- Los agentes personalizados sin AL no se disparan automáticamente por eventos en el sistema.
- La distribución como app (control de versiones, canal AppSource o privado, despliegue automatizado) requiere desarrollo.
- El versionado de instrucciones, su carga como recurso embebido, su actualización en cada nueva versión del agente: todo eso es código.
El consultor funcional sigue siendo crítico en esta fase. Lo que el desarrollador necesita para empaquetar bien es exactamente lo que el funcional ha producido: instrucciones validadas, perfil acotado, permission set ajustado, casos de prueba con resultado esperado. Sin ese trabajo previo, el AL es un disparo a ciegas.
Esta sección no parte de la imaginación. Cada caso está respaldado por al menos una fuente oficial o de comunidad reconocida, y se etiqueta el grado de respaldo.
1. Validación de pedidos de venta abiertos para una fecha de envío
- Proceso BC
- Sales Order Processing, Reservations, Shipping Advice
- Rol
- Order Processor, Sales Coordinator
- Problema
- Volumen de pedidos abiertos donde solo una parte cumple condiciones para ser liberada al almacén; revisión manual lenta y propensa a errores
- Qué hace
- Recorre pedidos abiertos para una fecha, verifica reservas en Statistics, comprueba Shipping Advice, libera si procede; el resto queda como tarea para revisión humana
- Validar
- Que el perfil del agente vea Statistics, Sales Order List, Sales Order; que la regla de Shipping Advice = Complete se aplique correctamente
- Riesgos
- Liberaciones incorrectas si los datos de reserva están sucios; el agente solo ve lo que ve el perfil
- Producción
- Empaquetar como AL siguiendo el ejemplo de BCTech para un agente productivo distribuible
2. Captura de pedidos de venta a partir de correo
- Proceso BC
- Sales Quote, Sales Order, comunicación con cliente por correo
- Rol
- Sales Coordinator, Customer Service
- Problema
- Volumen alto de correos con peticiones de oferta o pedido; transcripción manual lenta y con errores
- Qué hace
- Identifica al cliente por remitente, busca productos por descripción, prepara oferta como PDF, mantiene conversación si faltan datos, convierte a pedido tras confirmación
- Validar
- Calidad del maestro de productos (descripciones, atributos, categorías, textos extendidos), buzón dedicado, configuración de revisión por tipo de remitente
- Riesgos
- Productos mal indexados producen pobres resultados; confianza falsa en correos malintencionados
3. Procesado de facturas de proveedor desde correo
- Proceso BC
- Inbound E-Documents, Purchase Invoice, registro contable
- Rol
- Accounts Payable, Bookkeeper
- Problema
- Entrada manual de facturas, identificación de proveedor, clasificación contable repetitiva
- Qué hace
- Captura PDFs, OCR con Azure Document Intelligence, identifica proveedor (incluso con NIF/VAT), sugiere cuentas según histórico, deja borrador para aprobación
- Validar
- Plan de cuentas y maestro de proveedor limpios, idioma de descripciones consistente con cuentas, dimensionado bajo los límites de 100 correos/día y 10 páginas/PDF
- Riesgos
- Sugerencias incorrectas si datos maestros pobres; en preview avanzado, casamiento con pedido de compra y prioridad por confianza aún en evolución
4. Comprobaciones de crédito antes de aceptar pedido
- Proceso BC
- Credit Limit, Customer Card, Payment History
- Rol
- Sales Coordinator, Credit Controller
- Problema
- Aceptar pedidos sin verificar límite ni historial deriva en bloqueos posteriores
- Qué hace
- El agente comprueba si el cliente excede su límite, mira el historial de pagos y notifica al equipo con sugerencia de condiciones de pago alternativas
- Validar
- Que el perfil exponga Customer Card y Customer Ledger Entries; que las instrucciones referencien campos exactos
- Riesgos
- El agente no debería decidir cambiar términos por sí mismo; debe siempre request a review
- Producción
- Disparo automático desde OnAfterInsert de Sales Header requiere AL
5. Reposición desde requisition worksheet
- Proceso BC
- Requisition Worksheet, Items, planificación
- Rol
- Buyer, Planner
- Problema
- Revisión periódica manual de líneas de reposición
- Qué hace
- El agente revisa el worksheet, valida líneas según reglas y deja la lista lista para procesar
- Validar
- Que el perfil vea Requisition Worksheet y campos clave; reglas de aceptación claras en instrucciones
- Riesgos
- Ejecutar el agente programado de forma recurrente requiere AL; en preview, no hay scheduler nativo para agentes custom desde UI
Otros escenarios que aparecen razonables a la luz de las capacidades documentadas (recordatorios de cobro, revisión de datos maestros incompletos, seguimiento de vencimientos, borradores de comunicación) se podrían explorar como prototipos. No los desarrollo aquí porque no tengo respaldo documental directo y prefiero no presentarlos como funcionalidad disponible.
Las prácticas que siguen están respaldadas por documentación oficial, comunidad reconocida o son recomendación profesional explícita.
Documentadas por Microsoft
- Empezar por procesos concretos y acotados, no por flujos críticos completos.
- Usar la estructura Responsibilities / Guidelines / Instructions.
- Aplicar mínimo privilegio: solo los permission sets necesarios.
- Crear un perfil específico para el agente.
- No duplicar en instrucciones lo que ya está en tooltips o descripciones de página.
- Validar entradas antes de acciones críticas.
- Iterar instrucciones antes de cambiar perfil o permisos; cambiar permisos antes de cambiar código.
- Probar con datos representativos (incluyendo casos límite).
- Usar buzones dedicados, mejor compartidos e internos, para los agentes que monitorizan correo.
- Mantener instrucciones agnósticas al entorno (control entorno-específico vía perfil/permisos).
Recomendadas por comunidad reconocida
- Escribir un documento separado de "casos límite" por cada instrucción principal y probarlos antes de declarar el agente listo.
- Evitar campos con caption duplicado en cabecera y líneas (confunden al agente).
- Mejorar mensajes de error: texto que explique por qué y cómo arreglar facilita que el agente se autorrecupere.
- Si el agente falla, antes que tocar AL, ajustar instrucciones, reducir ruido en el perfil o aportar contexto explícito.
Recomendaciones del autor
- Tratar el agente como un becario: confianza acotada, supervisión documentada, aumento progresivo de responsabilidad solo cuando los logs lo justifican.
- Asignar siempre un propietario funcional nominal a cada agente productivo (la persona del negocio que responde por su comportamiento).
- Versionar las instrucciones fuera de Business Central (descarga periódica, control en repositorio interno).
- En cada propuesta a cliente, etiquetar capacidades como GA, Preview, Interpretación o Desarrollo necesario. La transparencia paga.
- Confundir Copilot con agentes. Copilot ayuda en una página; agentes ejecutan secuencias.
- Confundir agente estándar con agente diseñado. Sales Order Agent y Payables Agent no se modifican; un agente propio sí.
- Confundir prototipo en sandbox con solución productiva. La toolkit es preview; producción requiere AL.
- Dar permisos amplios para compensar instrucciones débiles. Las instrucciones se pueden ignorar; los permisos no. Compensar al revés es lo correcto.
- No revisar logs. Sin AGENT - DIAGNOSTICS y sin lectura del Agent Task Log estás a ciegas.
- No probar excepciones. Si el agente solo se prueba con casos felices, los casos infelices los descubre el cliente.
- No documentar decisiones. Por qué este perfil, por qué esta regla, por qué este límite: todo debe quedar escrito.
- Prometer disponibilidad geográfica o por idioma sin verificar. Cada capacidad publica sus regiones e idiomas soportados.
- Asumir que el agente puede usar Tell me o saltar a tablas. No lo hace. Solo navega UI visible.
- Diseñar instrucciones que dependen de campos no visibles en el perfil. Sí, pasa. El agente intentará y fallará.
Esta es una propuesta del autor basada en lo investigado. Lo etiqueto explícitamente como recomendación profesional, sin presentarla como guía oficial de Microsoft.
- Formación de fundamentos: AI generativa, Copilot, agentes, conceptos de prompt e instrucciones.
- Lectura de documentación oficial: AI Development Toolkit, Sales Order Agent, Payables Agent, Sales Validation Agent, transparency notes.
- Identificación de procesos candidatos: con negocio, listar procesos repetitivos, acotados y con datos limpios.
- Selección de un caso piloto: pequeño, reversible, no crítico, con métricas claras.
- Sandbox preparado: versión 27.2/27.4 según necesidad, custom agent capability activada, permisos AGENT - ADMIN y AGENT - DIAGNOSTICS al consultor, modelo de facturación de Copilot Credits decidido.
- Diseño funcional del agente: identidad, perfil, permisos mínimos, instrucciones en Responsibilities/Guidelines/Instructions.
- Pruebas con datos realistas: incluir escenarios negativos.
- Revisión de logs: identificar puntos de fallo, ajustar.
- Validación con usuarios clave: aceptación funcional documentada.
- Decisión: prototipo congelado para demo, prototipo descartado, prototipo trasladado a desarrollo AL para producción.
- Documentación y gobierno: propietario, métricas, criterios de revisión periódica.
MEMORIZErecuerda valor entre pasosDO NOTregla negativa críticaALWAYS·MUSTregla obligatoriaReplyresponder en conversaciónRequest a reviewpedir intervención humanaAsk for assistancedelegar duda
AGENT-ADMINdiseña y gestiona agentesAGENT-DIAGNOSTICSlogs detallados + costesSOA AGENT-EDITsistema · solo Sales OrderSUPERrequerido para activar capacidad
PDFúnicamentetipo de adjunto10 páginasmaxpor PDF5 MBmaxtamaño PDF10 adjuntosmaxpor correo100 correosal díacuota diariasolo inglésidioma soportado
BC 27.2+ custom agent capabilityBC 27.4según fuente / actualizaciónsandbox onlytoolkit no va a producciónBC onlineno disponible on-premisesWave 1 2026v28 · panel + MCP + stop-all
Los agentes representan, dentro de Business Central, una forma distinta de trabajar con el ERP. No es solo Copilot con esteroides, ni RPA con cara amable. Es un modelo donde personas y agentes colaboran sobre los mismos procesos, con identidades, permisos y trazabilidad propias para los agentes y con responsabilidad final siempre humana.
El consultor funcional gana protagonismo en este modelo, no lo pierde. Los agentes hacen visible una verdad que muchos proyectos olvidaban: el conocimiento operativo es un activo. Hasta ahora ese conocimiento vivía en cabezas, en personalizaciones aisladas y en hojas Excel sueltas. Las instrucciones de un agente lo capturan en lenguaje natural, versionable y auditable. Quien sabe redactar bien instrucciones, escoger un perfil mínimo y leer un log es quien acaba diseñando los agentes que la empresa usa de verdad.
La preview es una oportunidad. Lo que no es —y conviene repetirlo— es una herramienta para vender humo. Lo que está en preview se etiqueta como preview. Lo que requiere desarrollo se reconoce como desarrollo. Lo que es interpretación se presenta como interpretación. Si nos tomamos en serio esa disciplina, los próximos waves nos encontrarán preparados; si no, llegará algún cliente con expectativas que la documentación nunca prometió, y el daño afectará a todo el ecosistema.
Fuentes oficiales de Microsoft
- AI in Business Centrallearn.microsoft.com/dynamics365/business-central/ai-in-bc
- About Copilot in Business Central / Copilot FAQlearn.microsoft.com/.../copilot-overview
- Configure Copilot and agent capabilitieslearn.microsoft.com/.../enable-ai
- AI development toolkit overview (preview)learn.microsoft.com/.../ai-development-toolkit-overview
- Designing and coding agents (preview)learn.microsoft.com/.../ai-agent-playground
- Create and activate an agent (preview)learn.microsoft.com/.../ai-development-toolkit-agent-create
- Write effective instructions for an agent (preview)learn.microsoft.com/.../ai-development-toolkit-instructions
- Instruction keywords for an agent (preview)learn.microsoft.com/.../ai-development-toolkit-instruction-keywords
- Set up agent permissions and profiles (preview)learn.microsoft.com/.../ai-development-toolkit-permissions-profiles
- Agent permissions (preview)learn.microsoft.com/.../ai-development-toolkit-permissions
- Run an agent / Run a Playground Agent (preview)learn.microsoft.com/.../ai-agent-playground-run-agent
- Iterate and manage an agent (preview)learn.microsoft.com/.../ai-development-toolkit-iterate
- Attachment capabilities and limitations (preview)learn.microsoft.com/.../ai-development-toolkit-attachments
- Coding agents in AL (preview)learn.microsoft.com/.../ai-agent-sdk-overview
- Create a Sales Validation Agent (preview)learn.microsoft.com/.../ai-development-toolkit-sales-validation
- Sales Order Agent overview / Setuplearn.microsoft.com/.../sales-order-agent
- Payables Agent Overview / Setup / FAQlearn.microsoft.com/.../payables-agent
- Manage consumption-based billing for agent capabilitieslearn.microsoft.com/.../tenant-admin-center-manage-consumption-billing
- Transparency Note: Business Central agent playgroundlearn.microsoft.com/.../transparency-note-agent-playground
- FAQ: Designing agents (preview)learn.microsoft.com/.../ai-development-toolkit-faq
- Configure Business Central MCP Serverlearn.microsoft.com/.../configure-mcp-server
Microsoft Release Plan
- Envision and design AI agents in Business Central · 2026 release wave 1learn.microsoft.com/.../envision-prototype-custom-ai-agents-using-agent-designer
- Manage tasks from all agents in dedicated task pane · 2026 release wave 1learn.microsoft.com/.../manage-tasks-all-agents-dedicated-task-pane
- Use Sales Order Agent to automate sales order-taking · 2024 wave 2learn.microsoft.com/.../use-copilot-agent-capabilities-automate-sales-order-taking-process
- Automate payables processes with the Payables Agent · 2025 wave 1learn.microsoft.com/.../automate-payables-processes-payables-agent
Repositorios oficiales
- BCTech / Sales Validation Agent samplegithub.com/microsoft/BCTech/.../SalesValidationAgent
Comunidad reconocida
- Bert Verbeek · Agents in Business Central · MVPbertverbeek.nl/.../agents-in-business-central-part-1
- Tech Sphere Dynamics · A practical guide to creating agentstechspheredynamics.com/.../a-practical-guide
- Stefano Demiliani · Copilot Credits consumption · MVPdemiliani.com/.../how-many-copilot-credits-my-agent-consumes
- Stoneridge · BC 2026 Wave 1 New Tools and Featuresstoneridgesoftware.com/.../business-central-2026-wave-1
- Yun Zhu · Dynamics 365 Lab · BC27.4 Custom Agent · MVPyzhums.com/70502
- Katson · Meet Custom Agents in Business Central · MVPkatson.com/meet-custom-agents-in-business-central
