Diseñamos agentes de IA que atienden por WhatsApp, voz y web con una responsabilidad concreta: entender solicitudes, consultar fuentes permitidas y coordinar herramientas dentro de límites explícitos. La autonomía se define por acción, no por una promesa general.
Conversemos sobre tu operaciónUn agente de reservas y uno de documentación necesitan objetivos, contexto y herramientas distintos. El diseño comienza por definir qué solicitudes atiende, qué datos necesita y cuándo debe detenerse. Ese contrato permite evaluar si una conversación terminó correctamente y evita que un mismo agente intente resolver todo con permisos demasiado amplios.
Una herramienta puede consultar una reserva, preparar un ticket o recuperar un documento. Cada llamada tiene entradas esperadas, permisos y una respuesta que debe verificarse. Para cambios de estado se definen confirmaciones, protección contra duplicados y comportamiento ante fallos. Una intención expresada en lenguaje natural no equivale por sí sola a una autorización de negocio.
El agente necesita distinguir la conversación actual del estado real en los sistemas. Puede retener un resumen útil para continuar, pero datos como disponibilidad, saldo o permisos deben verificarse en la fuente correspondiente. Las instrucciones dentro de documentos externos se tratan como contenido, no como autoridad para ampliar acciones o revelar información.
Los casos normales y difíciles forman parte de las pruebas: usuarios ambiguos, herramientas caídas, información contradictoria y solicitudes fuera de alcance. Se observa si el agente elige la acción adecuada y reconoce cuándo necesita ayuda. La revisión humana y los registros permiten ajustar el proceso antes de darle más responsabilidad.
Se parte de conversaciones reales anonimizadas y se comprueba si el agente llegó al resultado correcto, no si sonó convincente. Primero se fija una línea base: cómo se resuelven hoy esas solicitudes, con qué errores y con cuántos traspasos. Luego se repasan los casos frecuentes y, con más atención, los difíciles: datos contradictorios, usuarios que cambian de idea a mitad de camino, herramientas que no responden y peticiones fuera de alcance. Cada transcripción se revisa contra criterios escritos de antemano.
El mismo rol de agente se comporta distinto según el canal. En mensajería la conversación es asíncrona: la persona puede responder horas después, adjuntar fotos o documentos y retomar el hilo, por lo que el agente debe recuperar contexto sin repreguntar todo. En voz importa el turno de habla, la confirmación de datos oídos y la brevedad. En web, el entorno suele ofrecer más estructura, como formularios o botones. El diseño adapta el recorrido a cada canal sin cambiar las reglas de negocio.
Los proveedores de mensajería imponen condiciones propias sobre quién puede iniciar una conversación, en qué ventana de tiempo puede responderse libremente y cuándo se exigen mensajes con plantilla previamente aprobada. También regulan el consentimiento de contacto y el tipo de contenido permitido. Estas reglas cambian con el tiempo y varían por proveedor, país y tipo de cuenta, así que verifica las condiciones vigentes del proveedor antes de diseñar flujos que dependan de mensajes salientes. El diseño del agente las trata como restricciones de partida, no como detalles a resolver al final.
Un agente es tan útil como el material con el que trabaja. Antes de empezar conviene reunir las respuestas aprobadas a las preguntas más repetidas, las políticas con sus excepciones y una lista de acciones que el agente podría realizar, ordenadas por riesgo. También hay que decidir quién recibe las transferencias, en qué horario y con qué información, porque un buen traspaso depende tanto del lado humano como del automático.
Un agente no debe aprobar excepciones a una política, modificar importes ni prometer lo que ningún sistema respalda. Tampoco debe seguir instrucciones escondidas en documentos o mensajes que intenten ampliar sus permisos. Las acciones de mayor impacto pasan por confirmación o por una persona, y se revisan muestras periódicas de conversaciones para detectar desvíos. Si cambian los datos o los procedimientos, el comportamiento esperado se vuelve a probar.
Responderlas por escrito, aunque sea de forma imperfecta, acelera el diseño del primer agente.
Comprender la solicitud y comprobar que está dentro del alcance.
Recuperar el contexto permitido y elegir el siguiente paso.
Usar una herramienta autorizada o pedir aprobación.
Verificar el resultado y responder o transferir con contexto.
La autonomía depende de la tarea y del riesgo. Algunas consultas pueden resolverse con fuentes aprobadas; otras acciones requieren confirmación o revisión humana.
Es una opción de diseño cuando existen responsabilidades distintas. Se prefiere la arquitectura más sencilla que permita conservar contexto, permisos y una forma clara de verificar resultados.
Debe pedir aclaración, expresar el límite de la información o derivar el caso. El comportamiento esperado se define y se prueba; no se considera aceptable inventar una solución.
Empecemos por un proceso que importe. Descubramos juntos lo que tu equipo podría hacer con más tiempo.
Agenda una demoO escríbenos sobre el proceso que quieres mejorar