Build o Buy en Agentforce: Acciones listas, Flow, Apex y APIs

La respuesta resumida

Las acciones son el punto en el que un agente deja de hablar y comienza a actuar, concentrando la mayor parte del riesgo y del costo de mantenimiento. Existen cuatro métodos de implementación: acciones estándar, Flow, Apex y servicios externos a través de una API. La elección entre ellos no es una cuestión de capacidad —casi cualquier acción es posible en todos ellos—, sino de quién lo mantendrá, con qué rapidez se puede modificar y cómo se valida.

El orden de elección recomendado es de arriba a abajo: comenzar con una acción estándar, pasar a Flow cuando se requiera lógica de negocio, a Apex cuando la complejidad sea significativa y a Servicios Externos cuando la verdad resida fuera de Salesforce. Cada descenso en esta escala aumenta el costo de mantenimiento y, por lo tanto, requiere una justificación.

Tabla de decisión

La primera regla: descripción antes de la implementación

Antes de elegir una tecnología, se debe redactar la descripción de la acción. Esto puede parecer un procedimiento, pero es el elemento que determina si el agente ejecutará la acción correcta. El agente no lee el código: lee la descripción y toma una decisión en consecuencia.

Una buena descripción incluye tres partes: qué hace la acción, en qué situaciones usarla y, explícitamente, en qué situaciones no hacerlo. La tercera parte es la que a menudo se olvida y es la que evita que el agente active una acción de crédito cuando el cliente solo preguntó sobre la política de créditos.

Los parámetros deben ser mínimos y de tipo definido. Un parámetro de texto libre donde el agente debe ingresar un valor de una lista cerrada es una invitación a errores; una lista de valores definidos lo resuelve sin lógica adicional.

Cuándo Flow y cuándo Apex

Flow es la opción predeterminada para las reglas de negocio porque es visual y permite al propietario del proceso entender lo que sucede. En el caso de los agentes, una ventaja adicional es la velocidad de corrección: si se descubre que la acción no verifica una condición de elegibilidad, se puede corregir el mismo día.

Apex se justifica en cuatro situaciones: lógica con muchas ramificaciones que hace que Flow sea ilegible, procesamiento de grandes volúmenes en una sola lectura, la necesidad de un control preciso en el manejo de errores y transacciones, y una integración que requiere un procesamiento complejo de respuestas. Fuera de estas situaciones, Apex principalmente encarece el siguiente cambio.

La elección también está relacionada con la deuda técnica existente. Una organización que ya arrastra miles de líneas de Apex sin pruebas debe pensarlo dos veces antes de añadir otra capa; las consideraciones completas se encuentran en Flow vs. Apex.

Acciones con sistemas externos

Este es el ámbito donde los fallos llegan al usuario final. Se deben definir tres decisiones antes de la construcción: cuál es el tiempo máximo de espera, qué dice el agente cuando la llamada falla y si se permite reintentar.

La idempotencia es el concepto decisivo. Una operación de lectura se puede reintentar con seguridad. Una operación que crea un registro, envía un mensaje o cobra una tarjeta, un reintento puede generar duplicados. La solución es una clave única para cada solicitud que el sistema receptor identifique, o una renuncia consciente a reintentar.

La latencia es una consideración de experiencia, no solo técnica. Una llamada que dura unos segundos es aceptable en un canal de chat si el agente dice que está verificando; una llamada que dura más de eso requiere una ruta asíncrona: el agente confirma la recepción y actualiza cuando llega la respuesta.

Los patrones para abordar los fallos de integración se detallan en Manejo de errores de integración en Salesforce.

Permisos a nivel de acción

Cada acción debe estar limitada por un permiso separado. El error común es otorgar al agente un perfil amplio que cubre todas las acciones, y luego no hay forma de abrir una acción específica a un grupo determinado sin abrirlas todas.

Principio de trabajo: permiso mínimo para cada acción, validación dentro de la acción y no solo en las instrucciones para el agente, y verificación de que la acción respeta el contexto del usuario. No se debe depender de que las instrucciones eviten la activación; las instrucciones son una guía, no un control.

Cuándo dividir una acción

Una acción que realiza tres cosas es difícil de probar y de aprobar. Una señal para dividir: cuando una parte de la acción requiere aprobación humana y otra no, cuando diferentes partes requieren permisos distintos, o cuando un fallo intermedio deja el proceso en un estado inconsistente.

La división encarece ligeramente la orquestación, pero vale la pena: cada parte se prueba por separado, el agente puede detenerse entre las partes y los permisos son precisos. La regla práctica: una acción, una decisión.

La planificación de puntos de detención entre las partes se detalla en Human-in-the-Loop en Agentforce.

Escenario: una organización que pasó de Apex a Flow

Una empresa de servicios construyó seis acciones en Apex en una fase piloto, suponiendo que así obtendría control total. En dos meses, se hizo evidente que cuatro de ellas cambiaron de lógica tres veces cada una, no por errores, sino porque las reglas de negocio se fueron aclarando con el uso. Cada cambio requería un desarrollador, pruebas y un ciclo de despliegue de varios días.

En la segunda ronda, las dos acciones que permanecieron en Apex fueron aquellas con múltiples llamadas a un sistema externo y procesamiento de respuestas. Las otras cuatro se trasladaron a Flow, y el administrador de la plataforma asumió la responsabilidad de ellas. El tiempo promedio de corrección se redujo de días a horas.

La lección no fue que Apex sea malo, sino que en la etapa en que las reglas aún se están consolidando, el costo del cambio es más importante que el costo inicial de construcción.

Riesgos y acciones preventivas

Métricas para Acciones

Cuando se requiere acompañamiento en la planificación de la capa de Acciones y su adaptación a la arquitectura existente, el servicio Agentforce y AI es el camino práctico a seguir.

Lista de verificación para cada Acción

• ☐ Se redactó una descripción con "qué", "cuándo sí" y "cuándo no"
• ☐ Los parámetros son mínimos y de tipo definido
• ☐ Se seleccionó la implementación de más alto nivel que sea suficiente para la necesidad
• ☐ Se definió un permiso separado para la acción
• ☐ La validación reside dentro de la acción y no solo en las instrucciones
• ☐ Se determinó si la acción es idempotente y cuál es la política de reintentos (Retry)
• ☐ Se definió el tiempo máximo de espera y el mensaje de fallo para el usuario
• ☐ Las acciones con múltiples decisiones se dividieron
• ☐ Existe un escenario de prueba para el fallo y no solo para el éxito