Agentforce enablement.
Tools reales para que tu agente ejecute, no solo conteste.
Un agente Agentforce sin acceso a tus sistemas externos es un chatbot. Con MuleSoft expuesto como capa de tools, ese mismo agente consulta el ERP, ejecuta una transferencia, agenda en un calendario externo, dispara un proceso real. Todo con schemas estrictos, guardrails, observabilidad y escalamiento a humano cuando corresponde.
¿Qué resuelve Agentforce enablement con MuleSoft?
Vender Agentforce sin MuleSoft es vender el 30 por ciento del valor: el agente queda limitado a lo que ya vive en Salesforce. La capa de tools sobre MuleSoft conecta a Agentforce con el ERP, el WMS, el contact center, el sistema de pagos, los calendarios y cualquier backend interno o externo. Cada tool tiene descripción semántica, schemas estrictos, guardrails y observabilidad granular.
- APIs registradas como tools con metadata semántica para LLM.
- Validación estricta de inputs y respuestas estructuradas para que el modelo las interprete.
- Guardrails previos a la ejecución (rate limit, scope, compliance, business rules).
- Human-in-the-loop para acciones sensibles (refunds, cambios de plan, transferencias grandes).
Sistemas típicos involucrados
Las familias que conviven en una implementación Agentforce con MuleSoft.
CRM y AI
Salesforce Service Cloud, Sales Cloud y Agentforce con su Atlas Engine como capa de razonamiento.
Data Layer
Data Cloud y Snowflake como grounding y RAG cuando el agente necesita contexto histórico o segmentación.
Sistemas externos
ERP, billing, payment, calendarios, sistemas de HR y cualquier backend que el agente deba consultar o modificar.
Bus y observabilidad
Anypoint MQ, Kafka, Splunk, Datadog para mensajería asincrónica y trazabilidad de cada tool call.
Arquitectura objetivo
Agentforce ejecuta tool calls. MuleSoft Topic Center registra cada tool y aplica guardrails antes del backend.
+-----------------+
| Conversational |
| UI (Slack / |
| web / app) |
+--------+--------+
|
v
+-----------------+
| Agentforce |
| (Atlas Engine)|
+--------+--------+
|
Tool calling protocol
|
v
+-----------------+
| MuleSoft Topic |
| Center / Tool |
| Registry |
+--------+--------+
|
+------------+------------+----+--------+
| | | | |
v v v v v
+---------+ +-----------+ +---------+ +---------+
| erp-tool| | wms-tool | |mail-tool| | hr-tool |
| (sap-fi)| | (Manhattan| |(MS Graph| | ... |
+---------+ +-----------+ +---------+ +---------+System APIs
Las System APIs subyacentes no cambian. Siguen exponiendo cada sistema fuente con contratos limpios. Las tools se construyen por encima.
Process APIs (tools)
check-customer-credit-tool, schedule-callback-tool, process-refund-tool, get-order-status-tool. Procesos de alto nivel diseñados para tool-use, no APIs raw.
Experience APIs
agent-tools-eapi implementa el tool calling protocol consumido por Agentforce. Versionado independiente porque puede evolucionar rápido.
Flujo paso a paso
Una conversación de servicio donde el agente consulta y actúa, sin handoff humano.
- 1 El cliente escribe en chat: "hola, mi pedido SO-12345 dice que llega hoy pero no llegó".
- 2 Agentforce procesa el input. Decide que necesita información: invoca la tool get-order-status-tool con orderId=SO-12345.
- 3 MuleSoft valida el formato del orderId con un schema estricto. Si el LLM inventa un parámetro, devuelve un error legible que el modelo puede interpretar y reintentar.
- 4 La tool ejecuta order-tracking-pa, que orquesta sap-sd-sapi (estado en el ERP) y tms-tracking-sapi (tracking del transporte) en paralelo.
- 5 El gateway aplica guardrails previos a la ejecución: rate limit por sesión, scope del consumer, reglas de negocio (el cliente solo ve sus propias órdenes).
- 6 La Process API recibe el estado consolidado y devuelve a la tool una respuesta estructurada más un summary en lenguaje natural listo para presentar al usuario.
- 7 Agentforce formula la respuesta al cliente con el contenido devuelto por la tool, sin alucinar datos que no estén en la respuesta.
- 8 El cliente pide ser notificado cuando el paquete salga del hub. Agentforce invoca enable-shipment-notification-tool con {orderId, channel}.
- 9 Esta tool tiene un guardrail adicional: requiere validar que el canal está autorizado para el cliente. Una vez validado, actualiza preferencias en el CRM y configura el listener al evento package.outforDelivery.v1.
- 10 Cada tool call queda loggeado con session_id, agent_id, parámetros, resultado, latencia y costo, formando la base para optimización y auditoría.
- 11 Acciones sensibles (refunds grandes, cambios de plan, transferencias arriba de un umbral) escalan a human-in-the-loop en lugar de ejecutarse automáticamente.
Patterns aplicados
Los patrones específicos del tooling para agentes que sostienen la operación.
Tool calling protocol
Compatible con el estándar de Agentforce y con tool_use de Anthropic / OpenAI tools, para que las APIs viajen sin glue code.
Strict input validation
Schemas JSON estrictos en cada tool. El LLM puede generar parámetros inventados y la tool los rechaza con un error que el modelo entiende.
Guardrails como capa
Rate limit, auth, scope, business rules y compliance se aplican antes de tocar el sistema real, no después.
Observability granular
Cada tool call queda con session_id, agent_id, parámetros, latencia, resultado y costo asociado para análisis y auditoría.
Human-in-the-loop
Tools sensibles (refunds altos, cambios de plan, acciones financieras) escalan a un humano en lugar de ejecutar.
LLM-friendly errors
Errores devueltos como objetos estructurados con error, message en lenguaje natural y flag retryable que el modelo puede interpretar.
Cómo lo implementamos
Cinco fases del catálogo inicial de tools al programa Agentforce gobernado.
Tools candidatas y casos de uso
Inventario de tareas que hoy hace un humano y que son candidatas a tool. Mapeo de los sistemas backend que cubren cada tarea. Definición de qué tools requieren approval humano. Entregables: catálogo inicial de tools, matriz de riesgo por tool.
Contratos de tools y guardrails
Diseño de cada tool con descripción semántica para LLM, schemas de input y output, guardrails específicos, política de auth, niveles de auditoría. Plan de Topic Center y registro de tools.
Tools, gateway y observabilidad
Implementación de las Process APIs detrás de cada tool, registro en Topic Center, tests de tool calling con un agente de prueba. Observabilidad: dashboards de tool usage y costo por sesión.
Piloto controlado y hypercare
Deploy a un canal piloto con usuarios reales, monitoreo intensivo de calidad de respuestas y deflection rate. Ajustes de descripciones de tools cuando el modelo no las usa correctamente.
Expansión y optimización de costo
Incorporación de nuevas tools, refinamiento de descripciones, cache estratégico para tools de consulta caras, optimización de costo por conversación. Capacitación del equipo cliente para gobernar el catálogo de tools.
Requisitos del proyecto
Lo que tiene que estar disponible del lado del cliente para arrancar.
Datos mínimos
Definición de las tareas que se quieren delegar al agente, criterios de éxito por tarea, política de qué acciones requieren aprobación humana.
Licencias y capacidades
Salesforce con Agentforce activado, Anypoint Platform, conectores de los sistemas backend involucrados. Data Cloud opcional según el grado de grounding.
Integraciones típicas
CRM, ERP, billing, calendar, sistemas de mensajería (WhatsApp, email, push), payment provider, sistemas verticales según industria.
Pre-requisitos organizacionales
Sponsor del programa de IA en la organización, líder del canal de servicio o ventas que adopta el agente, política de privacidad y revisión legal de las acciones automatizables.
KPIs operativos
Las métricas que definen si la capa de tools está rindiendo. Sin números de mercado: cada cliente fija su baseline.
| KPI | Qué mide | Por qué importa |
|---|---|---|
| Tool success rate | Porcentaje de tool calls que terminan en respuesta válida, separado por tool. | Identifica tools con descripciones débiles o schemas mal diseñados. |
| Tool P95 latency | Latencia del 95 por ciento de las invocaciones, separada por tool. | La tool suma a la latencia ya alta del LLM. Cada milisegundo cuenta para la UX de la conversación. |
| Agent resolution rate | Porcentaje de conversaciones resueltas por el agente sin escalar a un humano. | Es el indicador de negocio que justifica la inversión en Agentforce. |
| Escalation reasons | Distribución de motivos cuando el agente escala (caso fuera de scope, error de tool, política). | Guía la siguiente ola de tools y de mejoras del prompt. |
| Cost per resolution | Costo total por conversación: tokens del LLM, tool calls e infraestructura. | Sin esta métrica, Agentforce escala y revienta el presupuesto. |
| Hallucination rate | Frecuencia con la que el modelo intenta usar parámetros inventados que la tool rechaza. | Indica calidad del prompt y de las descripciones de tool. |
Time-to-value: piloto con 5 a 8 tools en producción tras 10 a 14 semanas, con métricas observables a las 3 semanas siguientes.
Cómo se mide: dashboard de tool usage sobre Anypoint Monitoring, cruzado con telemetría de Agentforce y costo de tokens del LLM provider.
Preguntas frecuentes
Tres cosas: descripción semántica clara que le explica al modelo cuándo usarla, schemas de input estrictos que evitan parámetros inventados, y respuestas estructuradas con un summary en lenguaje natural listo para presentar. Una API REST típica no es una buena tool sin ese envoltorio. La capa de tools es justamente eso: una API expuesta como Process API con metadata diseñada para LLM consumption.
Con guardrails como capa antes del backend real. Cada tool tiene política de auth, scope (qué consumer puede invocarla), rate limit por sesión y por día, validación de business rules (umbrales de monto, autorizaciones), y la opción de escalar a human-in-the-loop. La tool nunca toca el sistema real sin pasar primero por esos controles.
La tool valida con schema estricto antes de ejecutar y devuelve un error legible por LLM. Por ejemplo: en lugar de un 500 técnico, devuelve un objeto con error, message en lenguaje natural y retryable: true o false. El modelo lee el mensaje, corrige y reintenta, o escala al usuario pidiendo el dato correcto.
No es obligatorio para la capa de tools, pero Data Cloud aporta cuando el agente necesita grounding o RAG sobre datos del cliente: historial, segmentación, embeddings semánticos. Con MuleSoft podés alimentar Data Cloud y consumirlo desde las tools. Cada caso decide si Data Cloud entra ya o más adelante en la fase Evolve.
Una API REST raw expuesta a un agente da problemas predecibles: el modelo no sabe cuándo usarla, inventa parámetros, recibe errores que no entiende, ejecuta acciones sin control y nadie observa lo que pasa. La capa de tools agrega descripción, schemas, guardrails, observabilidad, política de costo y human-in-the-loop. Es la diferencia entre un piloto que funciona en demo y uno que opera en producción sin sustos.
Tools reales para que tu agente ejecute, no solo conteste.
Hablemos del agente que querés poner en producción y diseñamos el catálogo de tools.