Crear un agente de IA puede llevarte 20 minutos. Hacer que funcione en una empresa puede llevarte meses. Lo escribí hoy en LinkedIn a partir de una imagen que me causó gracia, porque tiene bastante de cierto. Soy Juan Manuel Garrido, fundador de EGA Futura y cofundador de Vantegrate. Después de más de 30 años trabajando con software empresarial, sigo viendo lo mismo: cada nueva tecnología nos permite construir cosas más rápido, pero eso no significa que las empresas estén preparadas para usarlas.
Qué es un agente de IA, si lo simplificamos mucho?
La imagen lo resume con humor. En los dos extremos de la curva aparece la misma respuesta: un agente de IA es un LLM dentro de un bucle while. Al lado está el código. El modelo recibe una instrucción, decide qué hacer, usa una herramienta, mira el resultado y vuelve a empezar.
Listo. Tienes un agente. Y la definición no está tan lejos de la realidad: el motor puede ser sorprendentemente simple. Con un modelo, un par de herramientas y ese loop ya hay algo que responde, consulta y actúa. Para una demo alcanza y sobra.
Lo que el chiste no cuenta es dónde va a correr ese loop.
Qué pasa cuando el agente toca datos reales en Salesforce?
Imagina ese mismo agente conectado a Salesforce, con acceso a oportunidades, pedidos, facturas y contactos. Ahora espera a que intente actualizar un registro que tiene 4 Validation Rules, 3 Flows y un trigger de Apex que nadie se anima a tocar. Ahí se termina la magia de la demo.
Cada una de esas piezas tiene su lógica y sus efectos. Una Validation Rule puede rechazar el cambio a mitad de camino. Un Flow puede crear otro registro o mandar un mail que nadie esperaba. Y el trigger viejo hace lo que hace, aunque no esté escrito en ningún lado. Si en tu org conviven automatizaciones de distintas épocas, antes de sumar un agente conviene revisar cómo ordenar Workflow Rules, Process Builder y Flow en el mismo objeto.
Porque una cosa es mostrar un agente que responde preguntas y otra es dejarlo trabajando con datos reales.
Pongamos un caso. Le pides actualizar los precios de 500 productos. El agente interpreta mal una instrucción y modifica registros que no tenía que tocar. O peor, hace exactamente lo que le pediste, pero nadie contempló que esos precios estaban asociados a contratos vigentes. En el primer caso falló el agente. En el segundo falló el proceso, y el agente solo lo ejecutó muy rápido.
Por qué hay que resolver el proceso antes que el prompt?
No digo que los agentes no sirvan. Todo lo contrario. Me parece que estamos frente a uno de los cambios más importantes que vi en mis años desarrollando software empresarial. Lo que me preocupa es dónde está puesto el entusiasmo. Se habla muchísimo de modelos, prompts, MCP y agentes autónomos, y bastante menos de los procesos donde esos agentes van a trabajar.
Un ejemplo bastante común. Un vendedor necesita aprobar un descuento del 20% y su límite es 15%. El gerente está de vacaciones. Quién aprueba? En muchas empresas nadie tiene una respuesta clara, y ahora se espera que un agente de IA resuelva el problema. El agente puede consultar Salesforce, ejecutar un Flow o llamar a una API. Pero si nadie definió quién tiene autoridad para aprobar ese descuento, la IA no debería inventar una política comercial.
Primero hay que resolver el proceso. Después vemos cómo automatizarlo. Ese mismo caso lo desarrollé en detalle en quién aprueba un descuento cuando el gerente está de vacaciones, con la prueba que le haría a cualquier circuito de aprobación.
Cuándo conviene un agente y cuándo alcanza con Flow o Apex?
Tampoco creo que todo necesite agentes. Salesforce Flow sigue siendo extraordinario para automatizar procesos con reglas claras. Apex también. No tiene sentido poner un LLM a decidir algo que una regla de negocio resuelve más rápido, con menos costo y de manera predecible.
Una forma práctica de separar los casos:
- Si la decisión se puede escribir como una condición (monto, estado, rol o fecha), va a Flow o a Apex.
- Si la tarea pide interpretar texto libre o combinar información de varias fuentes, un agente puede aportar de verdad.
- Si el resultado mueve precios, contratos o plata, el agente propone y una regla o una persona valida antes de escribir.
- Si nadie sabe quién decide, todavía no hay nada para automatizar.
Hay casos donde necesitas razonamiento y autonomía. Y otros donde necesitas que el sistema haga exactamente lo que tiene que hacer. Confundirlos sale caro para cualquiera de los dos lados.
Qué revisar antes de dejar un agente trabajando en tu empresa?
Lo complicado empieza cuando lo conectas con una empresa de verdad. Con sus permisos, datos duplicados, procesos heredados y excepciones que nunca aparecen en las demos. Antes de pasar a producción, estas preguntas te ahorran más de un disgusto:
- Con qué usuario corre el agente y qué puede ver y editar?
- Qué Flows, triggers y Validation Rules se disparan cuando escribe en cada objeto?
- Qué pasa si una validación rechaza el cambio en medio de un lote de registros?
- Los datos que va a usar están limpios o hay duplicados?
- Quién es el dueño del proceso y quién aprueba las excepciones?
- Cuándo tiene que frenar y a quién le avisa?
La última pregunta da para un artículo entero, y lo escribí: cinco frenos antes de poner un agente de IA en Salesforce.
Si estás evaluando agentes para procesos reales, en Vantegrate explicamos qué son los agentes de IA y cómo se implementan en empresas medianas, y puedes agendar una demostración para verlo sobre tu caso. Y si lo que falta es ordenar circuitos con reglas claras, el motor de automatización de EGA Futura trabaja dentro del ERP nativo para Salesforce, sobre los mismos datos del CRM.
Te dejo la misma pregunta del post: estás de acuerdo?
Preguntas frecuentes
Qué es un agente de IA en términos simples?
Un sistema donde un modelo de lenguaje recibe una instrucción, decide qué hacer, usa una herramienta, mira el resultado y repite el ciclo. Por eso se lo describe, con humor, como un LLM dentro de un bucle while.
Por qué un agente que funciona en la demo falla dentro de Salesforce?
Porque la org real tiene Validation Rules, Flows, triggers de Apex, permisos y datos duplicados que la demo no tiene. Y muchas veces el proceso que el agente debe ejecutar nunca se definió.
Conviene reemplazar Flow o Apex por agentes de IA?
Para reglas claras, no. Flow y Apex resuelven más rápido, con menos costo y de manera predecible lo que se puede escribir como condición. Un agente suma cuando hace falta interpretar o razonar.
Qué definir antes de conectar un agente a datos reales?
Los permisos del usuario del agente, las automatizaciones que dispara, qué hace ante un error, la calidad de los datos, el dueño del proceso y en qué momento frena y le pasa el caso a una persona.
Recibe estas ideas en tu correo
Si te sirvió esta mirada sobre agentes de IA en Salesforce, suscríbete gratis al newsletter de EGA Futura en Substack y recibe cada artículo nuevo directo en tu correo.