Qué es un agente de IA y cuándo tu empresa necesita uno

Un agente de IA es un programa en el que un modelo de lenguaje recibe un objetivo, tiene herramientas para actuar sobre otros sistemas y decide en un ciclo cuál es el siguiente paso hasta terminar. Modelo, herramientas y ciclo: esas son las tres piezas. Si falta alguna, lo que tienes es otra cosa, normalmente un chatbot o una automatización.

Las búsquedas de “qué es un agente de IA” crecieron mucho en el último año: según los datos de Google Ads, en México casi se triplicaron y en España se duplicaron con creces. Lo que posiciona hoy son definiciones genéricas. Este artículo parte de otro lugar: los agentes que construimos y operamos en Bamboo Tech Studio, lo que hacen de verdad y cómo decidimos cuándo un problema merece uno.

Qué es un agente de IA, pieza por pieza

• Un modelo de lenguaje que lee la situación y razona sobre ella. Es el que decide.
• Herramientas: funciones que el modelo puede llamar para leer o cambiar algo en el mundo. Buscar un cliente en el CRM, crear un ticket, editar un archivo, responder en un grupo.
• Un ciclo: el modelo llama una herramienta, lee el resultado, decide el siguiente paso y repite hasta cumplir el objetivo o concluir que no le corresponde actuar.

Un ejemplo real. En un grupo de WhatsApp alguien escribe que hay que llamar a un contacto el lunes. Nuestro agente de CRM crea un seguimiento con la fecha correcta de ese lunes y confirma en el grupo lo que hizo. Nadie le dijo qué herramienta usar ni en qué orden: lo decidió leyendo el mensaje. Eso es lo que lo vuelve un agente.

Agente de IA, chatbot y automatización: la diferencia

La pregunta que separa a los tres es simple: ¿quién decide el siguiente paso?

La última fila de la tabla importa. Un agente es la opción más flexible y también la más cara de operar bien. Por eso muchas veces la respuesta correcta es una automatización con un solo paso de IA. Nuestro flujo de entrada de soporte, que describimos abajo, es exactamente eso: una secuencia fija en la que un modelo solo etiqueta cada mensaje, y únicamente lo que parece un reporte sigue adelante. No elige herramientas ni da vueltas. Y funciona mejor así.

Agentes que tenemos funcionando

Estos son los que operamos hoy, descritos sin nombres de clientes. Los modos de fallo propios de agentes como estos, y la regla que aplicamos a cada uno, están en agentes de IA en WhatsApp en producción.

Un agente de CRM en un grupo de WhatsApp. Vive en un grupo que compartimos con un socio. Lee lo que se escribe, consulta y actualiza el CRM por medio de herramientas (clientes, seguimientos, reuniones) y responde en el grupo. Puede agregar registros, pero no cerrarlos: eso lo hace una persona.

Un flujo de entrada que propone tickets de soporte. Escucha los grupos de WhatsApp que tenemos con clientes. Un modelo clasifica cada mensaje de cliente como reporte, consulta de estado, conversación o ruido. Si es un reporte con confianza alta, se crea un ticket en borrador con las palabras textuales del cliente, y una persona lo confirma con un clic antes de que el cliente reciba el acuse. Las notas de voz se transcriben y se clasifican igual que el texto.

Un asistente de borradores en una bandeja de soporte. Lee cada mensaje de cliente que entra y escribe la respuesta como nota privada. Una persona la revisa, la corrige si hace falta y la envía. El asistente nunca responde directamente al cliente.

Un agente que edita sitios web. El cliente pide un cambio en lenguaje natural (“cambia este texto por este otro”, “actualiza este indicador”). El agente prepara el cambio en una rama separada, el sistema construye una vista previa de la página y una persona hace clic en Publicar. El agente solo puede tocar archivos de contenido y no tiene forma de publicar: eso lo hace el servidor, y solo cuando alguien aprueba. Hoy funciona en dos sitios de clientes, con un modelo abierto de tamaño mediano sobre inferencia propia.

Un agente de pedidos del equipo. Cuando alguien del equipo pide algo en un canal interno, el agente acusa recibo sin adelantar contenido, prepara una respuesta con lo que ya sabe la wiki de la empresa y se la manda en privado a quien decide. Solo publica la versión aprobada, y la aprobación la verifica el código, no el modelo.

ChatWise, en sitios web y WhatsApp. Es nuestro producto de chat de soporte. Responde desde el propio contenido del negocio (con la técnica que explicamos en qué es RAG) y, en cada mensaje, un enrutador elige entre responder desde la base de conocimiento, usar una herramienta o pasarle la conversación a una persona. El traspaso ocurre cuando el cliente pide hablar con una persona, y una segunda revisión evita que un simple “gracias” u “ok” se confunda con ese pedido.

Fíjate en el patrón: en casi todos, el agente prepara y una persona decide. No es falta de ambición. Es lo que permite usar un agente en trabajo real desde el primer día.

Cuándo tu empresa necesita un agente de IA

Un agente tiene sentido cuando se cumplen las cuatro condiciones:

1. Hay criterio repetitivo sobre información desordenada. Mensajes de WhatsApp, correos, pedidos en lenguaje natural, notas de voz. Si cada caso exige leer y decidir, y los casos se repiten todos los días, hay terreno para un agente.
2. Existen las herramientas. El agente necesita sistemas sobre los que actuar: un CRM con API, un repositorio, una base de datos, una bandeja de soporte. Sin herramientas solo puede conversar.
3. El costo de un error se puede contener. Un borrador mal escrito se corrige; un cambio en una rama se descarta. Un pago enviado o un registro borrado no tienen vuelta.
4. Una persona puede revisar. Al menos al principio, alguien tiene que mirar lo que el agente propone antes de que llegue a un cliente.

Y cuándo no lo necesitas:

• Las reglas son claras y los datos estructurados. “Cuando entra un pedido pagado, generar la factura y avisar por correo” es una automatización. Un agente ahí solo agrega costo y variación.
• La tarea ocurre unas pocas veces al mes. El trabajo de construirlo, probarlo y vigilarlo no se paga.
• Cada error es irreversible y nadie puede revisar. Primero hay que diseñar el punto de aprobación, después el agente.
• No hay sistemas a los que conectarlo. Si la información vive en la cabeza de alguien, el primer proyecto es escribirla, no automatizarla.

Si dudas entre “agente” y “automatización”, empieza por la automatización y agrega un paso de IA donde haga falta criterio. Es más fácil subir de ahí a un agente que bajar. Y si la presión para tener “un agente” viene de afuera más que de un problema concreto, vale la pena leer el hype está tomando tus decisiones de IA.

Lo mínimo para operarlo con seguridad

Nuestra regla de base: una regla que solo vive en el prompt no es una regla. Un modelo puede ignorar una regla pedida por instrucción (trabajar en una rama, respetar un formato), mientras que la misma regla puesta en el código se cumple siempre. Lo que construimos desde el día uno:

• Herramientas estrechas. El agente que edita sitios solo puede escribir en la carpeta de contenido, y su acceso a la terminal es una lista blanca de comandos de solo lectura y de git. Una lista negra se queda corta: un agente puede crear un archivo bloqueado usando una redirección de la terminal.
• Aprobación humana para lo irreversible. Los agentes agregan; las personas cierran, borran, publican y facturan.
• La fecha de hoy en cada mensaje. Los modelos no saben qué día es. Sin ese dato, un agente puede fijar un vencimiento en un año que ya pasó.
• IDs verificados. El código compara cada número de registro que el agente cita contra los que las herramientas devolvieron de verdad. Si el agente crea el seguimiento 4 y luego confirma “seguimiento 14”, esa comparación lo detecta.
• Registros que no mientan. El estado sale del sistema, no de lo que el agente dice que hizo. Un agente puede decirle a una persona que un cambio está listo cuando el sistema lo bloqueó. Por eso, en nuestro agente de sitios, el estado que ve la persona se lee de git, nunca de lo que dice el agente.
• Una evaluación antes del lanzamiento. Un conjunto de casos con la nota mínima para aprobar. Nuestros agentes nuevos la tienen antes de salir a producción. Escribir las pruebas después del primer incidente es el orden que conviene evitar. Explicamos cómo armarla en las evals que de verdad necesitas.

Cada punto responde a un modo de fallo concreto. Varios se explican en detalle en agentes de IA en WhatsApp en producción, y lo que un agente debe recordar entre conversaciones, en memoria de agentes de IA en la práctica.

Cómo crear un agente de IA para tu empresa: por dónde empezar

1. Elige un solo proceso. Uno que pase todos los días y que hoy alguien resuelva leyendo y decidiendo. “Revisar los mensajes de clientes y detectar los reportes” es un buen primer proceso. “Automatizar el soporte” no lo es.
2. Mídelo antes de tocarlo. Cuántos casos por semana, cuánto tarda cada uno, cuántos se escapan. Sin esa línea base no vas a poder decir si el agente ayudó.
3. Arranca en modo sombra. Así ponemos en marcha flujos como el de entrada de soporte: antes de crear un solo ticket, corre en modo solo registro y anota cuáles mensajes habría convertido en ticket, sin crear ninguno y sin enviar nada. Si el tráfico en vivo es poco para evaluarlo, se le pasan también mensajes reales anteriores. Eso da datos de precisión gratis antes de que actúe.
4. Después, modo borrador. El agente propone y una persona aprueba con un clic. Solo cuando los borradores salen bien de forma consistente se discute darle más autonomía, y siempre con un interruptor para volver atrás al instante.
5. Agrega herramientas de una en una. Cada herramienta nueva es una nueva forma de equivocarse. Agrégalas cuando un caso real las pida, no por si acaso.

Cuando ya tengas varios agentes, el problema cambia: dónde vive lo que saben, cómo se coordinan, quién los vigila. De eso trata qué es un sistema operativo de IA.

Si tienes un proceso candidato y quieres saber si merece un agente o una automatización más simple, hablemos. Diseñamos, construimos y operamos agentes de IA y automatizaciones con las mismas reglas que aplicamos a los nuestros.