Skip to main content
Ilustración abstracta de un agente digital
Madai Garcia · Product Manager @ Leracom
03 de marzo, 2026 · 7 min de lectura

Cuando terminas de armar tu agente, hay una pequeña etiqueta en la parte superior que dice DRAFT. Ese es tu borrador. Mientras esté así, el agente no recibe ni hace llamadas reales. Puedes editarlo sin miedo, que nada se rompe afuera. Publicar es, literalmente, mover ese agente al mundo real. Y en Agents Studio tiene un truco muy elegante que casi nadie entiende la primera vez: el sistema de versiones.

El botón de publicar y lo que pasa por detrás

Arriba a la derecha, verás un botón morado que dice Publish. Cuando le das clic, aparece una ventanita pidiéndote una cosa: una nota de versión.
Version notes
Ej.: Updated welcome prompt and changed voice...
Esa nota es opcional en apariencia, pero en la práctica es obligatoria si no quieres arrepentirte en 3 meses. Te explico por qué.
Diálogo Publish Version con el campo de notas y el botón Publish

Cada vez que publicas, se crea una versión nueva

No sobrescribes el agente. Cada publish genera una versión: v1, v2, v3, v4… Se guardan todas. La última publicada es la activa — la que está atendiendo llamadas. Las anteriores quedan archivadas, pero existen. Eso significa tres cosas hermosas:
  1. Puedes volver atrás. ¿Publicaste algo que rompió el flujo? Un clic y restauras la versión anterior. Sin pánico, sin reconstruir nada.
  2. Tienes un historial completo. Cada versión muestra la fecha, el autor, y la nota. Si dentro de seis meses alguien pregunta “oye, ¿por qué cambió este saludo?”, el historial lo dice.
  3. Puedes experimentar. Armas una v7 aventurera, la publicas, mides, y si no funciona, vuelves a la v6.
Ventana de Version History mostrando v1, v2, v3 con estado active/archived

Por eso la nota de versión importa

“Cambié cosas” no te va a ayudar cuando hagas auditoría. Notas útiles se ven así:
  • “Ajuste del saludo por feedback del equipo de marketing.”
  • “Reducción de temas prohibidos; agregado manejo de objeción por precio.”
  • “Nueva variable de salida origen_contacto por integración con HubSpot.”
Nada sofisticado. Sólo lo necesario para que el tú de dentro de tres meses entienda al tú de hoy.

Antes de darle publicar, los 5 chequeos que yo hago

Después de haber publicado agentes que luego rompí en producción, me hice esta lista. No me falla:

1. ¿Todas las variables dinámicas están bien escritas?

Abre el agente completo y haz cmd + F buscando las dobles llaves. Cada variable debe tener:
  • Doble llave de apertura y de cierre ({{x}}, no {x} ni {{x}).
  • El mismo nombre en todos lados (no mezclar {{nombre_cliente}} con {{cliente_nombre}}).
Este es, literal, el bug #1 que veo al publicar.

2. ¿Las reglas críticas se contradicen?

Cuando escribes 10 reglas, de vez en cuando una dice “siempre ofrece 3 opciones” y otra dice “sé conciso, máximo 2 opciones”. El agente se vuelve loco. Léelas todas seguidas antes de publicar.

3. ¿Las variables de salida obligatorias tienen su pregunta en el flujo?

Si marcaste fecha_promesa_pago como obligatoria pero en ninguna parte del flujo el agente la pregunta, la llamada no va a cerrar bien. O peor: nunca cierra.

4. ¿Hay al menos un camino de escalamiento?

Siempre debe existir una salida para cuando las cosas se ponen feas: cliente enojado, problema que no puedes resolver, duda fuera de alcance. Sin esa salida, el agente se queda atrapado.

5. ¿El tono del saludo encaja con el tono de las reglas?

Me ha pasado tener un saludo super cálido (“¡Hola qué tal!”) seguido de reglas muy formales (“Diríjase al cliente con respeto y distancia profesional”). El agente termina esquizofrénico. Alinea.

La prueba de fuego: una llamada a tu propio celular

Antes de publicar en serio, yo hago esto siempre:
  1. Guardo el borrador.
  2. Uso el botón de Play (prueba de llamada).
  3. Relleno las variables con datos realistas (no test, test, test).
  4. Marco a mi celular.
  5. Me hablo como si fuera un cliente difícil. Hago preguntas capciosas. Cambio de tema. Me quejo.
Si el agente sobrevive a eso, publico. Si no, sigo iterando.

Un error que ni yo me perdono

Una vez publiqué un agente de cobranza con el saludo diciendo Hola {{nombre_cliente}}. Perfecto. Lo que no noté: en la variable de entrada del CSV, la columna se llamaba customer_name, no nombre_cliente. Resultado: 400 llamadas saludando con “Hola llave llave nombre cliente llave llave”. Una pesadilla. Moraleja: los nombres de tus variables tienen que coincidir exactamente entre la personalidad y el archivo de campaña. No son parecidos, son idénticos.

¿Y después de publicar?

Tu agente pasa a estado Activo (verás un círculo verde). Ya puede atender llamadas reales.
Perfil del agente en estado Active con estadísticas de conversations, goal achievement y days active
Pero no te relajes. Las primeras 10-20 llamadas reales son las más importantes:
  • Escucha al menos 5 grabaciones completas.
  • Revisa las variables de salida: ¿están llegando con datos coherentes?
  • Mira el porcentaje de cumplimiento del objetivo (el 100% o lo que sea que muestre en el panel). Si está bajo, algo hay que ajustar.
Con esa información haces tu v2, y así sucesivamente. Los agentes no se publican una vez y se abandonan; se afinan con los datos que ellos mismos generan.

El estado “en entrenamiento” existe por una razón

Entre Inactivo y Activo hay un estado intermedio: En entrenamiento. Lo uso cuando quiero que el agente reciba llamadas, pero bajo control (un volumen bajo, o sólo con un canal específico). Es el “modo pre-producción” del lenguaje tradicional.
Selector de estados del agente desplegado mostrando Active, Training e Inactive
No todos lo usan, pero si tu agente va a manejar cosas sensibles (cobranza, salud, legal), entrena antes de pasarlo a Activo. Ahorra disgustos.
Tu turno
  1. Pasa los 5 chequeos antes de publicar: variables bien escritas, reglas que no se contradicen, variables obligatorias preguntables en el flujo, ruta de escalamiento, tono coherente entre saludo y reglas.
  2. Haz una llamada de prueba jugando al “cliente difícil” antes de darle Publish.
  3. Publica la v1 con una nota de versión descriptiva — no “cambios” ni “v1”. Algo como “Saludo inicial + 3 reglas críticas base”.
¿Te quedaste con dudas? Escríbenos a contacto@leracom.ai.

En el próximo post, el momento que todos esperamos: lanzar la primera llamada real. Veremos cómo hacer una prueba bien hecha, qué variables rellenar, y cómo interpretar el resultado.

Leer más del blog

01-panel-general

Copilot al rescate

7 min · Erika Barrera24 feb 2026
02-modal-prueba

Tu primera llamada de prueba

8 min · Julio Barrera10 mar 2026
04-monitoreo

Tu primera campaña

7 min · Lizbeth Suarez17 mar 2026