De chatbot a agente: cómo diseñé un asistente de IA que ejecuta acciones con confirmación humana

Hace un tiempo que vengo notando el mismo patrón en los equipos de producto con los que trabajo: todos tienen un chatbot. Responde preguntas frecuentes, busca en la documentación, a veces hasta suena inteligente. Pero en algún momento de la conversación con el cliente aparece la pregunta incómoda: "¿y esto puede hacer algo, o solo habla?"

Ahí es donde entra la diferencia entre un chatbot y un agente. Un chatbot responde. Un agente opera tu plataforma: crea un recurso, actualiza un estado, dispara un proceso. Y ese salto —de responder a ejecutar— es el que más valor agrega, pero también el que más responsabilidad exige. En este post te cuento cómo lo encaramos, qué piezas usamos y por qué la confirmación humana no es un detalle, es el corazón del diseño.

El chatbot de FAQ ya no alcanza

Un asistente que solo contesta preguntas sobre tu producto tiene un techo bajo. Sirve para reducir tickets de soporte, sí, pero no cambia la forma en que un usuario interactúa con tu plataforma. La pregunta que le hago a cada equipo de producto que me consulta es simple: ¿qué pasaría si este asistente pudiera, además de explicar cómo se hace algo, hacerlo directamente?

Ahí aparece function-calling: en lugar de que el modelo solo genere texto, le damos la capacidad de invocar funciones concretas que operan sobre las entidades reales del negocio. No es una integración genérica de "conectá tu API"; es modelar qué acciones tiene sentido que el agente pueda ejecutar sobre tus entidades —una orden, un usuario, una suscripción, un ticket— y exponer eso como herramientas que el modelo puede decidir usar según el contexto de la conversación.

RAG del estado de la organización: que el agente sepa dónde está parado

Para que el agente tome buenas decisiones necesita algo más que las instrucciones del usuario: necesita contexto real sobre el estado actual de la organización. Ahí es donde entra RAG (Retrieval-Augmented Generation), pero no solo aplicado a documentación estática, sino al estado vivo de la plataforma: qué recursos existen, en qué situación están, qué reglas de negocio aplican.

Construimos un motor de RAG propio que no fue pensado exclusivamente para el agente. Lo reutilizamos en tres frentes: la landing (donde responde preguntas de visitantes sobre el producto), la documentación (donde ayuda a los usuarios a entender funcionalidades) y el propio agente (donde alimenta las decisiones antes de proponer una acción). Un solo motor, tres superficies. Esto no es solo eficiencia de desarrollo: significa que la fuente de verdad es una sola, y cuando actualizás la base de conocimiento, se actualiza para los tres casos de uso al mismo tiempo.

Para los embeddings usamos pgvector directamente sobre Postgres. No sumamos una base de datos vectorial aparte para esto: si ya tenés Postgres corriendo tu negocio, tiene sentido que el conocimiento vectorizado viva ahí también, con los mismos backups, la misma infraestructura, el mismo lenguaje de consultas que ya conocés.

Function-calling con freno de mano: la confirmación humana

Acá llegamos al punto que más me interesa transmitir en este post, porque es el que marca la diferencia entre un agente útil y un agente riesgoso.

Cuando el agente decide que hay que ejecutar una acción —crear algo, modificar algo, disparar un proceso— esa acción no se ejecuta directamente. Queda registrada como una acción pendiente, lo que en nuestra implementación llamamos AiPendingAction, y permanece en ese estado hasta que un humano la revisa y la confirma explícitamente.

Esto cambia por completo la conversación con el cliente sobre "IA que actúa sola". No estamos delegando control ciego a un modelo de lenguaje; estamos dándole al agente la capacidad de proponer con contexto y precisión, pero dejando la decisión final donde tiene que estar: en una persona. El agente hace el trabajo pesado de entender qué hay que hacer y prepararlo; el humano hace el trabajo liviano de decir "sí, adelante" o "no, así no".

Para los equipos de producto esto suele ser un alivio más que una limitación. La primera pregunta que me hacen cuando presento esta arquitectura es "¿y si se equivoca?". Con confirmación humana obligatoria antes de cualquier ejecución, esa pregunta pierde urgencia: el peor caso no es que el agente ejecute algo mal, es que proponga algo mal y alguien lo rechace. Es una diferencia enorme en el nivel de riesgo que estás dispuesto a asumir al lanzar este tipo de funcionalidad.

Controlar el costo: medir antes de gastar, cobrar al confirmar

Un agente que hace function-calling y RAG puede volverse costoso rápido si no diseñás con cuidado el ciclo de vida de cada interacción. La lógica que aplicamos es bastante directa: primero medimos, después gastamos.

Antes de ejecutar la parte más pesada del flujo —la que efectivamente consume recursos del modelo de forma significativa— evaluamos si la solicitud amerita ese gasto. Y en los flujos donde el agente propone una acción concreta, el cobro (o el consumo de cuota, según el modelo de negocio de la plataforma) ocurre en el momento de la confirmación, no en el momento en que el agente simplemente "pensó" en la acción. Esto alinea el costo real con el valor entregado: no le cobrás a nadie por una propuesta que después se descarta.

Como proveedor principal para las capacidades de lenguaje usamos Gemini, con fallback a OpenRouter cuando hace falta resiliencia adicional o acceso a otros modelos. Esta combinación nos da margen para operar sin depender de un solo punto de falla, sin que eso implique reinventar la arquitectura cada vez que aparece un nuevo modelo en el mercado.

De responder a operar, sin perder el control

Si tu producto ya tiene un chatbot de FAQ, probablemente estés en el punto justo para dar el siguiente paso. La clave no es agregar más "inteligencia" al asistente por agregarla, sino definir con claridad qué acciones de tu negocio tiene sentido que un agente pueda proponer, con qué contexto (RAG sobre el estado real de tu organización) y bajo qué mecanismo de control (confirmación humana antes de ejecutar).

Esa combinación —function-calling sobre entidades reales, RAG reutilizable en toda tu plataforma, acciones pendientes hasta confirmación humana y un control de costos que mide antes de gastar— es lo que separa a un chatbot de un agente que realmente opera tu producto sin que pierdas el control sobre lo que pasa.

Si estás pensando en dar ese salto en tu plataforma, te invito a visitar estebanburgos.com.ar/servicios/inteligencia-artificial y charlamos sobre cómo aplicar esto a tu caso concreto.