Habla mientras trabaja: por qué nuestro agente acepta interrupciones

Una tester temprana estaba trabajando en una tarea larga cuando escribió una corrección en el chat — sin detener nada. Después nos contó que el momento se sintió inesperadamente bien: la otra herramienta de agente que usa le hace detener la ejecución primero antes de aceptar un mensaje nuevo. "Tener que pararla solo para hablarle se sentía tonto", dijo, "comparado con esto".

Tiene razón, y la diferencia no es un pequeño detalle de UX. Viene de una decisión de diseño que tomamos pronto y seguimos reaplicando: un agente es un colega, no una máquina. Interrumpes a un colega a mitad de frase y lo integra. No lo apagas y enciendes.

Por qué "para primero" es el defecto equivocado

Obligar al usuario a detener una ejecución antes de hablar tiene tres costes, todos pagados por el usuario:

• La corrección llega demasiado tarde. El momento en que notas que el agente se desvía es exactamente cuando deberías hablar. Forzar una parada significa verlo quemar tiempo y tokens por el camino equivocado mientras buscas el botón de parar.
• Detener destruye estado. Una ejecución detenida no se reanuda — empiezas de cero, o peor, recibes un esqueleto "cancelado" y vuelves a explicar el contexto. Tu corrección de rumbo en pleno vuelo te cuesta todo el trabajo en curso.
• Invierte quién sirve a quién. "La máquina no puede oírte ahora, vuelve luego" es la conveniencia de la máquina, no la tuya.

Cómo funciona el nuestro de verdad

Cuando envías un mensaje mientras una ejecución está en marcha, pasan tres cosas en orden:

1. Tus palabras se guardan primero. El mensaje cae en el historial de conversación inmediatamente — antes de que se despache nada. Tu intención es durable desde ese instante; ninguna cola, buffer o timing puede perderla.
2. Se entrega en el siguiente límite de paso. El agente no suelta lo que tiene entre manos a mitad de una llamada de herramienta — lee tu mensaje en la siguiente pausa natural, como una persona que termina un pensamiento y luego atiende tu punto.
3. Corrige el rumbo, no reinicia. Todo lo que la ejecución ya hizo permanece. Tu mensaje es una corrección de rumbo aplicada a una tarea en movimiento, no un reinicio.

El principio debajo: la durabilidad de la intención del usuario pesa más que la conveniencia del sistema. Una vez guardadas las palabras, todo lo que sigue es timing — y el timing puede hacerse elegante. La intención no guardada no se recupera jamás.

Cómo se ve en la práctica

El ejemplo más claro ya es público. En la historia del reloj, la petición del fundador pivotó dos veces mientras el agente trabajaba — "en realidad, haz una versión HTML", luego "empaquétalo como una web app instalable". Cada interjección aterrizó a mitad de ejecución y curvó la trayectoria. Nadie pulsó stop; la app que se entregó quedó moldeada por correcciones lanzadas en vuelo.

La versión cotidiana más sutil es más aburrida y más valiosa: llevas diez mensajes en una tarea de investigación, ves que está construyendo la comparación equivocada, escribes "compara con X mejor" — y lo ves girar sin perder las ocho buenas fuentes que ya había reunido.

El principio viaja

Esta semana nos topamos con la misma pregunta desde el otro lado: ¿qué pasa cuando nosotros te interrumpimos — un reinicio del servidor por un deploy? La respuesta honesta resultó ser la misma regla. Durante los deploys el servidor ahora acepta inyecciones a mitad de ejecución (tus palabras guardadas sobreviven y la siguiente ejecución las retoma en contexto) mientras solo pausa el arranque de ejecuciones nuevas. Rechazar texto que el usuario ya escribió habría sido nuestra conveniencia imponiéndose a tu intención — la inversión exacta que criticamos arriba, solo que con disfraz de operaciones.

No pretendemos que esto sea novedoso — las interrupciones encoladas son como los buenos sistemas han funcionado siempre. Solo es raro en la UX de agentes, donde "para la máquina para hablarle" se volvió la norma de algún modo. Nos alegra ser el defecto aburrido y correcto.