Editás el asistente desde tu agente y en ese mismo momento un cliente escribe por WhatsApp. ¿Cuál de los dos le contesta: lo que acabás de cambiar o lo de ayer?

En CognitionDesk un asistente tiene dos estados, y saber cuál corre en cada canal es lo que te deja editar sin miedo. Con @cognitiondesk/mcp todo el ciclo se maneja desde Claude u otro cliente MCP con cuatro tools: try_assistant, publish_assistant, list_assistant_versions y rollback_assistant.

Borrador y publicado: quién corre qué

El borrador es el documento vivo: lo que escribe update_assistant y lo que devuelve get_assistant. Lo corren el chat del panel y try_assistant, para que veas tus cambios al instante.
La versión publicada es una copia congelada que hace publish_assistant. Es lo que reciben tus clientes: el widget embebido en un sitio, el SDK, todo turno que entra por API key, y WhatsApp.

La consecuencia práctica es una sola: update_assistant no le cambia nada a ningún cliente hasta que publicás.

Hay un caso que conviene conocer: un asistente que nunca se publicó corre su borrador en vivo, sin protección y sin nada a qué volver. La primera publicación es el momento en que empieza a ser seguro editarlo.

1. Antes de tocar: qué está en vivo

list_assistant_versions devuelve las versiones publicadas, de la más nueva a la más vieja, y cuál está en vivo. Pide el scope assistants:read. La forma de la respuesta:

{
  "publishedVersionId": "<id de v3>",
  "enVivo": "v3",
  "total": 3,
  "aviso": null,
  "versiones": [
    { "versionId": "<id de v3>", "numero": "v3", "enVivo": true,  "publishedAt": "…", "publishedBy": "…" },
    { "versionId": "<id de v2>", "numero": "v2", "enVivo": false, "publishedAt": "…", "publishedBy": "…" },
    { "versionId": "<id de v1>", "numero": "v1", "enVivo": false, "publishedAt": "…", "publishedBy": "…" }
  ]
}

Si el asistente nunca se publicó, total es 0 y aviso lo dice con todas las letras: "Nunca se publicó: los clientes reciben el DRAFT en vivo y no hay a qué volver." No es una lista vacía que se pasa por alto.

La lista no repite el prompt de cada versión: para eso está get_assistant. Sirve para leer de un vistazo qué hay en vivo y a qué se puede volver.

2. Editar y probar el borrador

update_assistant cambia el borrador. try_assistant habla con él por el mismo camino que atiende a los clientes, así que lo que contesta ahí es lo que van a recibir. Probá con messages y no con un solo message: la mayoría de las fallas aparecen en el segundo turno, cuando el asistente tiene que acordarse de lo que ya se dijo.

Cada llamada a try_assistant corre el modelo y gasta créditos de la cuenta; no queda registrada como una conversación real.

3. Publicar

publish_assistant congela el borrador como una versión nueva y apunta el bot en vivo a ella. Devuelve el versionId. Desde ese momento le habla a clientes reales, así que la regla que conviene darle al agente es: publicar sólo con el OK de la persona dueña del asistente, después de mostrarle lo que contestó en la prueba.

4. Volver atrás

Si una publicación salió mal frente a clientes, rollback_assistant apunta el bot en vivo a una versión anterior. Pide el scope assistants:write y un versionId que sale de list_assistant_versions, nunca adivinado.

El rollback no toca el borrador: tus últimos cambios siguen ahí. Los corregís, probás de nuevo con try_assistant y volvés a publicar.

Medido contra producción el 23 de septiembre, list_assistant_versions contestó en 2,5 s y rollback_assistant en 2,1 s. Deshacer una publicación mala es cuestión de segundos, no de reconstruir el prompt de memoria.

El orden, en una línea

Para un asistente que ya atiende clientes: list_assistant_versions (saber qué reemplazás) → update_assistant (borrador) → try_assistant (borrador) → mostrárselo a la persona → publish_assistant con su OK → si sale mal, rollback_assistant.

Está en @cognitiondesk/mcp y en la guía del MCP. Si operás asistentes desde tu agente y querés revisar tu flujo de publicación, escribinos.

Publicar, ver versiones y volver atrás: el ciclo de vida de un asistente desde el MCP