La historia es un compuesto y los detalles son ilustrativos. Un equipo de RevOps hereda un flujo de enrutamiento de leads con catorce nodos de decisión: territorio por país de facturación, segmento por número de empleados, una excepción para cuentas nominales, una excepción para partners y un reparto rotativo como último recurso. Una herramienta nueva promete sustituirlo todo por un agente que "lee el lead y decide". El piloto parece ir bien durante un mes. Entonces un director regional pregunta por qué tres leads enterprise acabaron en la cola de pymes. Nadie sabe responder. El flujo anterior se podía rastrear nodo a nodo; el razonamiento del agente vivía en un prompt y en una ventana de contexto que ya no existían. Además, cada lead esperaba ahora una llamada al modelo que costaba dinero, para una decisión que antes no costaba nada. El equipo volvió a los catorce nodos.
El problema no era el agente. El enrutamiento nunca fue un problema agéntico.
La evidencia pide criterio, no abstinencia. El benchmark CRMArena-Pro de Salesforce AI Research (mayo de 2025), construido sobre diecinueve tareas validadas por expertos en ventas, servicio y configuración, precio y presupuesto (CPQ), encontró que los principales agentes aciertan cerca del 58% de las veces en tareas de un solo turno y cerca del 35% cuando la tarea requiere varios turnos, con una conciencia inherente casi nula sobre los datos confidenciales. El benchmark TheAgentCompany de Carnegie Mellon, según informó The Register en junio de 2025, encontró que el mejor modelo completó de principio a fin el 30,3% de las tareas de oficina simuladas. La predicción de Gartner de junio de 2025 señala los costes crecientes, el valor de negocio poco claro y los controles de riesgo insuficientes como motivos de cancelación, y advierte que buena parte del mercado practica el "agent washing": asistentes de IA, RPA y chatbots rebautizados sin capacidades agénticas sustanciales.
Aun así, los agentes están llegando a producción. La encuesta State of Agent Engineering de LangChain (1.340 participantes, realizada entre noviembre y diciembre de 2025) encontró que el 57% tiene agentes en producción, y el 32% cita la calidad como principal barrera. Gartner prevé que al menos el 15% de las decisiones laborales del día a día se tomarán de forma autónoma mediante IA agéntica en 2028, frente a cero en 2024. La pregunta es qué flujos merecen uno.
Esta es una decisión de arquitectura, no de herramientas ni de talento. La guía de ingeniería de Anthropic, Building Effective Agents, traza la línea con claridad: los flujos de trabajo son "sistemas en los que los LLM y las herramientas se orquestan mediante rutas de código predefinidas", mientras que los agentes "dirigen dinámicamente sus propios procesos y el uso de herramientas". Su consejo es buscar "la solución más simple posible y aumentar la complejidad solo cuando sea necesario", porque los sistemas agénticos "a menudo sacrifican latencia y coste a cambio de un mejor rendimiento en la tarea". Anushree Verma, de Gartner, lo expresa en términos operativos: usar agentes cuando hacen falta decisiones, automatización para los flujos rutinarios y asistentes para la recuperación simple de información.
Dónde se rompe
Los equipos se equivocan en ambas direcciones. Cuatro patrones se repiten en los stacks de ingresos.
Un agente donde corresponde una regla
El enrutamiento de leads, la asignación de territorios, los cambios de etapa del ciclo de vida y los temporizadores de SLA son deterministas por diseño. Las entradas son campos estructurados (BillingCountry, NumberOfEmployees, Named_Account__c), la salida es un propietario o una etapa, y el negocio quiere la misma respuesta cada vez. Un agente ahí añade latencia, un coste de modelo por registro y una decisión que nadie puede reproducir. Si la lógica se puede escribir como una tabla de decisión, debe escribirse así; el motor de reglas para la asignación de territorios muestra cómo se ve eso aplicado a la propiedad de cuentas.
Un flujo estático ahogado en ramas
El fallo opuesto es igual de común. Un flujo de traspaso o de triaje empieza con cinco ramas y crece hasta sesenta, cada una parcheando un caso límite: un campo de texto libre "¿cómo nos conociste?", un mapeo de lista de selección para cada nombre de campaña nuevo, condiciones anidadas sobre Lead_Source_Detail__c que solo entiende un administrador. Cada rama es un riesgo de regresión, y la cola larga sigue cayendo en una cola por defecto. Cuando el número de ramas crece con el número de entradas, el flujo te está diciendo que necesita criterio en un nodo, no más reglas.
Autonomía sobre objetos irreversibles
Algunas escrituras son baratas de deshacer: una tarea, un borrador, una alerta de Slack, un campo marcado para revisión. Otras no: un correo enviado a una cuenta estratégica, un valor de Discount__c en un presupuesto, un Amount modificado en una oportunidad comprometida, una condición contractual, una fecha de renovación que dispara la facturación. Dar a un agente acceso de escritura al segundo grupo sin una puerta de aprobación convierte una tasa de éxito del 35% en varios turnos en un incidente de cara al cliente. La reversibilidad, no la dificultad de la tarea, debe limitar la autonomía. La matriz de riesgo y reversibilidad para puertas de aprobación explica dónde deben ir esas puertas.
Agentes que leen entradas volátiles sin contrato
Los agentes se ganan su lugar con entradas desordenadas y cambiantes: transcripciones de llamadas, comportamiento en la web, ofertas de empleo, cargas de enriquecimiento de varios proveedores. Pero si el agente devuelve texto libre que un flujo posterior analiza con coincidencia de cadenas, cada actualización del modelo o cambio de esquema de un proveedor rompe algo en silencio. La solución es un contrato de salida estructurada (un esquema JSON con valores enumerados y un campo de confianza) validado antes de que nada toque el CRM, el mismo patrón descrito en estabilidad de esquemas para agentes de IA.
Arquitectura de referencia
El marco de decisión puntúa cada flujo en tres ejes, de 1 a 5. La complejidad de ramificación (B) mide cuántas rutas distintas necesita la decisión y si se pueden enumerar: 1 es una sola condición, 5 es una decisión cuyas rutas no se pueden listar de antemano. La volatilidad de los datos (V) mide cuán estructuradas y estables son las entradas: 1 son campos limpios del CRM que rara vez cambian, 5 es texto no estructurado o datos de terceros cuya forma cambia de un mes a otro. La reversibilidad (R) mide cuán barato es deshacer un resultado erróneo: 1 es algo de cara al cliente o financiero y difícil de revertir, 5 es interno y se deshace con un clic. Los umbrales siguientes son un punto de partida sugerido, no un benchmark.
agentic_demand = B + V # 2..10 if agentic_demand <= 4: mechanism = "static workflow" elif agentic_demand <= 7: mechanism = "static spine + model step at the judgment node" else: mechanism = "agentic orchestration candidate" # Reversibility caps autonomy, whatever the mechanism if R <= 2: autonomy = "recommend only; human approves every action" elif R == 3: autonomy = "act on low-risk actions; human approves the rest" else: autonomy = "act within budget and scope; sample for QA"
La banda intermedia es la que más importa. La mayoría de los flujos de ingresos que "necesitan IA" en realidad necesitan una llamada al modelo en un nodo, envuelta en lógica determinista, y no un agente que planifique sus propios pasos. Esta es la puntuación aplicada a seis flujos habituales, como ejemplo ilustrativo con puntuaciones basadas en criterio, no en datos de clientes:
| Flujo (ilustrativo) | B | V | R | Mecanismo | Autonomía |
|---|---|---|---|---|---|
| Enrutamiento de leads entrantes por territorio y segmento | 2 | 1 | 4 | Flujo estático | Totalmente automatizado |
| Traspaso de operación ganada del AE a CS | 2 | 3 | 4 | Columna estática + paso de modelo (resumir las notas del acuerdo en un brief de traspaso estructurado) | Automatizado, el CSM puede editar |
| Triaje de solicitudes de demo en texto libre | 3 | 4 | 4 | Columna estática + paso de modelo (clasificar intención y encaje con una puntuación de confianza) | Automatizado por encima de un umbral de confianza |
| Detección de oportunidades estancadas y avisos a los comerciales | 2 | 3 | 5 | Columna estática + paso de modelo (redactar el aviso) | Automatizado |
| Investigación de cuentas basada en señales y primer contacto outbound | 4 | 5 | 3 | Orquestación agéntica | El agente redacta; envío bloqueado hasta superar la prueba con datos históricos |
| Recomendación de descuento en renovaciones | 4 | 3 | 1 | Flujo de aprobación estático con un paso de modelo como analista | Solo recomienda |
Solo uno de seis se gana un agente, e incluso ese empieza con puertas. Ejecutar los tres mecanismos en un mismo stack requiere cinco capas con contratos explícitos.
Componentes: eventos de registros del CRM (creación, cambio de campo, cambio de etapa), envíos de formularios, eventos de uso del producto, fuentes de intención y enriquecimiento, transcripciones de llamadas.
Contrato con identidad y calidad de datos: cada disparador incluye un tipo de evento, una marca de tiempo, un ID de registro y un esquema de entrada declarado, para que la capa de decisión sepa si recibe campos estructurados o texto no estructurado.
Componentes: resolución de identidad hacia una cuenta y un contacto canónicos; comprobaciones de campos obligatorios; normalización de listas de selección y de valores de país y sector.
Contrato con la capa de decisión: las entradas llegan resueltas y validadas, con un data_quality_flag cuando no lo están. A ningún mecanismo, estático o agéntico, se le pide compensar una cuenta duplicada.
Componentes: un registro que guarda las puntuaciones B, V y R de cada flujo y el mecanismo asignado; motores de reglas nativos como Salesforce Flow o los workflows de HubSpot para las rutas estáticas; una herramienta de flujos como n8n, Make o Workato para las columnas estáticas con pasos de modelo; un entorno de ejecución de agentes para los pocos flujos agénticos. Las herramientas por sí solas no hacen de esto un sistema, como explica el problema de la capa de orquestación.
Contrato con el sistema de registro: cada decisión, la tome quien la tome, escribe una salida estructurada (decisión, entradas usadas, confianza, mecanismo, run_id) que se valida contra un esquema antes de cualquier escritura.
Componentes: objetos del CRM con permisos a nivel de campo según el mecanismo; una lista de campos permitidos que cada agente puede escribir; los campos irreversibles (Amount, Discount__c, condiciones contractuales) se dirigen a objetos de aprobación en lugar de escribirse directamente.
Contrato con la activación: el registro muestra quién o qué lo cambió y por qué, y todo lo que queda por debajo del umbral de reversibilidad del flujo espera en una cola hasta que una persona lo apruebe.
Componentes: infraestructura de envío, creación de tareas, alertas de Slack, colas de aprobación y los propios agentes, cada uno con un presupuesto de acciones y un alcance.
Contrato con la dirección: cada acción se puede rastrear hasta una decisión, cada decisión hasta un mecanismo y cada mecanismo hasta una razón puntuada y documentada de por qué se eligió.
Secuencia de construcción
Seis pasos, cada uno con una prueba.
Inventaría los flujos que ya ejecutas
Enumera cada automatización que toca el motor de ingresos: flujos nativos, escenarios de herramientas de flujos, scripts programados y todo lo que un proveedor llame agente. Registra disparador, entradas, salidas y los campos que escribe cada uno. El método de solo lectura del playbook de diagnosticar antes de construir se aplica directamente. Prueba: ninguna automatización escribe en el CRM sin aparecer en la lista.
Puntúa B, V y R con quienes son dueños del resultado
Puntúa cada flujo con el responsable de RevOps y el responsable de negocio en la sala, porque la reversibilidad es un juicio de negocio, no técnico. Prueba: dos personas que puntúan el mismo flujo por separado quedan a un punto o menos en cada eje.
Reconstruye primero la columna determinista
En cada flujo, separa las partes que son reglas de verdad (tablas de enrutamiento, SLA, puertas de etapa) de los uno o dos nodos que necesitan criterio. Lleva las reglas a una tabla de decisión o a un flujo nativo. Prueba: la columna estática produce el mismo resultado que el proceso actual sobre los registros del trimestre pasado.
Inserta pasos de modelo detrás de un esquema
En cada nodo de criterio, añade una sola llamada al modelo con un contrato de salida estructurada: valores enumerados, un campo de confianza y una ruta alternativa cuando la confianza es baja o la validación falla. Prueba: las salidas malformadas o de baja confianza terminan en una cola de revisión y nunca en un campo del CRM.
Prueba con tus propios casos pasados antes de salir a producción
Ejecuta cada paso de modelo o agente sobre veinte de tus propios casos pasados, etiquetados por tu equipo, y compara la salida con lo que decidió tu equipo. Exigimos a todos los sistemas el mismo listón: 85 por ciento de aciertos sobre los propios casos pasados del cliente y ninguna acción insegura sin detectar, o no se lanza. Prueba: el resultado queda registrado por flujo, y todo lo que está por debajo del listón se queda en modo de solo recomendación.
Sube la autonomía de escalón en escalón
Solo los flujos que suman 8 o más en B + V se convierten en candidatos agénticos, y empiezan con puertas. Aumenta la autonomía solo después de un periodo completo de revisión con un registro de decisiones que muestre la tasa de error y la tasa de anulación, y nunca por encima del límite que permite la reversibilidad. Prueba: cada ascenso tiene un registro fechado de la evidencia que lo respalda.
Construir o comprar: compensaciones
Cada mecanismo corresponde a una forma distinta de construir. Las herramientas son ejemplos, no recomendaciones.
| Enfoque | Encaje | Coste de propiedad | Riesgo de fallo |
|---|---|---|---|
| Automatización nativa del CRM (por ejemplo Salesforce Flow o los workflows de HubSpot) | Flujos estáticos: enrutamiento, puertas de etapa, SLA, actualizaciones de campos sobre datos estructurados | El más bajo. Sin coste de modelo por registro, mantenible por un administrador, versionado dentro del CRM | Proliferación de ramas a medida que se acumulan casos límite; frágil cuando las entradas no están estructuradas |
| Herramienta de flujos con pasos de modelo (por ejemplo n8n, Make o Workato llamando a una API de LLM) | Columnas estáticas con uno o dos nodos de criterio: triaje, briefs de traspaso, clasificación, redacción | Moderado. Coste de modelo solo en el nodo de criterio; necesita a alguien responsable de esquemas y alternativas | Roturas silenciosas cuando cambian la salida del modelo o las cargas de los proveedores sin un contrato validado |
| Entorno de ejecución de agentes (un agente nativo como Agentforce, o un agente a medida construido sobre un framework como LangGraph) | Alta ramificación y alta volatilidad: investigación de cuentas, síntesis de señales de varias fuentes, outbound de varios pasos | El más alto. Los costes de modelo, orquestación, evaluación y supervisión crecen con la autonomía | Errores que se acumulan entre pasos, baja reproducibilidad y ampliación del alcance de escritura salvo que los permisos se apliquen en el CRM |
Operarlo en producción
Sigue cada flujo frente al mecanismo que se le asignó. En los flujos estáticos, vigila la proporción de registros que caen en la rama por defecto: si crece, la volatilidad ha aumentado y hay que revisar la puntuación. En los pasos de modelo y los agentes, vigila la distribución de confianza, la tasa de anulación y los fallos de validación.
Cada paso de modelo y cada agente tiene una alternativa estática: cuando la validación falla, la confianza baja o se agota un presupuesto de acciones, el registro vuelve a la ruta determinista o a una cola humana. Degradar un mecanismo debería ser un solo ajuste en el registro de mecanismos, de modo que un agente que se comporta mal pase a solo recomendación sin un nuevo despliegue.
Bastan tres frases: puntuamos cada flujo según cuánto se ramifica, cuán desordenados son sus datos y cuánto costaría un error; usamos reglas donde las reglas funcionan y agentes solo donde hace falta criterio; y nada de cara al cliente o financiero funciona sin aprobación hasta que haya demostrado su valía con nuestro propio historial.
Dónde encaja en el sistema
El marco decide cómo se construye cada sistema de VANDFORT, y la respuesta cambia según el sistema. Speed-to-Lead mantiene el enrutamiento en una columna estática, porque el enrutamiento tiene que ser rápido, determinista y auditable; los pasos de modelo cualifican el lead frente a tu ICP y redactan la primera respuesta, y nada se envía sin aprobación hasta que tú decidas lo contrario. El Handoff Orchestrator es el ejemplo de manual de la banda intermedia: disparadores, propietarios y plazos deterministas, con un paso de modelo que traslada lo que dijo el comprador al otro lado del traspaso como un brief estructurado, y nunca reasigna un propietario por su cuenta. El Signal-Based Outbound Engine es donde la orquestación agéntica se gana su lugar, porque la investigación de cuentas a partir de señales volátiles no se puede escribir como una tabla de decisión, y nunca envía sin aprobación. El Pipeline Hygiene Sentinel marca los registros estancados con reglas e indica por qué se señaló cada uno, pero nunca edita una oportunidad, y Renewal Radar escala y programa, pero nunca compromete al equipo con un descuento o una concesión. El mapa completo está en la página de sistemas.
La contención también es un modelo operativo. En un proyecto de ingeniería desplegada en el cliente, el ingeniero puntúa el flujo con los datos del propio cliente antes de elegir el mecanismo, y entrega un sistema cada vez. El árbol de decisión entre GTM engineer, RevOps y growth engineer ayuda a decidir quién es responsable de las puntuaciones. En prospección, el paso de las secuencias a los agentes con autonomía acotada aplica la misma escalera, y el modelo de coste por reunión cualificada muestra cómo contabilizar la supervisión y la corrección de errores antes de ascender a un agente.
Fuentes: Salesforce AI Research, CRMArena-Pro: Holistic Assessment of LLM Agents Across Diverse Business Scenarios and Interactions (diecinueve tareas validadas por expertos; arXiv, mayo de 2025). Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 (junio de 2025). Carnegie Mellon University, benchmark TheAgentCompany, según The Register (junio de 2025). LangChain, State of Agent Engineering (1.340 participantes, noviembre a diciembre de 2025). Anthropic, Building Effective Agents (diciembre de 2024).
