Dynamic Planner: la IA que convierte una petición compleja en un plan paso a paso

La mayoría de las conversaciones no necesitan un plan. Quien le pregunta a tu agente un precio, un horario de apertura o una única duda de «cómo se hace» debería recibir una respuesta directa, no un proyecto. Pero algunas conversaciones son distintas: el usuario intenta sacar adelante un asunto entero — constituir una empresa, solicitar un visado, resolver una reclamación por muebles dañados — y se le nota que no sabe por dónde empezar. El Dynamic Planner existe justo para ese momento: convierte esa conversación concreta en una storyline temporal (un plan anidado, guiado por un checklist) que el agente después recorre paso a paso.

Es una capacidad Pro, activable por tenant. El modelo que hace la planificación se lo asigna la plataforma a cada tenant en lugar de elegirse dentro de la conversación, y eso es justamente lo que permite dirigir a un tenant con restricciones de residencia de datos hacia un modelo local o regional y dejar al resto en uno alojado.

¿Cuándo se dispara un plan?

Nunca porque el modelo «lo decida por su cuenta», y nunca a través de una caja de texto abierta que permita a los usuarios encargar planes arbitrarios. Hay exactamente tres vías de entrada, en orden decreciente de determinismo:

1. Un paso expandible de una storyline. El inquilino marca como expandible un paso de una storyline escrita por él. Cuando un usuario llega a él, el agente ofrece expandir ese paso en un subplan. El autor ya tomó la decisión en tiempo de diseño; no se deja nada al azar.
2. El usuario acepta una oferta. Todo plan empieza con una tarjeta de confirmación (la misma interfaz de formulario en conversación que se usa en todo lo demás). El usuario siempre puede rechazarla, y el agente no volverá a preguntar en esa sesión.
3. El juez de escalación. Fuera de las storylines, una pequeña llamada a un modelo dedicado observa cada turno y lo puntúa en tres dimensiones — las de más abajo. Solo cuando las tres pasan ve el usuario siquiera la oferta. Nunca se confía en que el modelo principal del chat se acuerde de disparar nada; el juez es una llamada forzada y estructurada que hace el motor.

Una storyline escrita por el inquilino siempre tiene prioridad: mientras una dirige la conversación, el planificador se mantiene callado. El proceso hecho a mano le gana al proceso generado.

La prueba de escalación en tres dimensiones

El juez evalúa la complejidad de la tarea, la confusión del usuario y el encaje con el dominio — y las tres tienen que cumplirse. Este es el corazón de la función, así que aquí está la lógica real con ejemplos.

1. Complejidad — ¿esto es de verdad multipaso? La tarea debería necesitar varios pasos, varios documentos o varios turnos para completarse. Una pregunta no es un plan.

• ✅ «Quiero montar una empresa en EE. UU. para comercio electrónico y no tengo ni idea de lo que eso implica»
• ❌ «¿Cuánto cuesta el registro en Delaware?» — es consultar un precio, respóndelo directamente
• ❌ «¿Cómo relleno la línea 7b del formulario SS-4?» — un paso concreto de un proceso que el usuario ya lleva

2. Confusión — ¿el usuario quiere que lo lleven de la mano? Señales: «por dónde empiezo siquiera», «qué necesito preparar», «guíame por todo el proceso», «no consigo llevar la cuenta de todo esto». Un usuario que conoce el proceso y pregunta por un eslabón de la cadena no está confundido — dale el eslabón, no un plan.

• ✅ «Mi jefe me ha pedido que monte la filial en EE. UU. y nunca he hecho nada parecido»
• ✅ «El registro ya está hecho, ¿qué viene después? ¿Presentaciones anuales? ¿Impuestos? No consigo tenerlo claro, prefiero que lleves tú la cuenta»
• ❌ «Tengo los documentos listos, solo dime dónde los presento» — informado, no confundido

3. Encaje con el dominio — ¿es trabajo del agente? Que un usuario diga la palabra «plan» no abre la puerta. Los inquilinos pagan por conversación; un agente de constitución de empresas se niega a convertirse en un asistente personal general, por muy educadamente que se formule la petición.

• ❌ «Hazme un plan de entrenamiento físico de tres meses, detallado por semanas» — fuera de dominio, rechazar
• ❌ «Planifica un viaje de diez días por Europa paso a paso» — fuera de dominio, rechazar

El plan generado también está restringido al dominio: el planificador recibe el cometido del agente y debe mantener cada paso dentro de él.

Qué pasa después del «sí»

La planificación es el único momento probabilístico, y ocurre una sola vez: un modelo planificador redacta el plan como datos estructurados — pasos, instrucciones por paso, un checklist de lo que hay que recoger, un criterio de finalización. El borrador se valida como cualquier grafo de storyline (los planes mal formados se reintentan y después se pasan a un modelo de reserva; un plan que nunca llega a validar sencillamente nunca se ejecuta). En cada paso se estampa de forma determinista una plantilla de límites fija — las contradicciones deben cuestionarse, no puede recomendarse nada fuera de la lista de ese paso, no se prometen aprobaciones ni precios — para que las barreras nunca dependan de que el modelo planificador se acuerde de escribirlas.

De ahí en adelante, la ejecución es el motor de storylines haciendo lo que siempre hace: un paso enfocado por turno, elementos del checklist marcados solo cuando hay evidencia, el progreso mostrado en el banner, una barra de progreso fina y una lista de pasos que renderiza el motor — así que lo que ves es el estado real, no el recuerdo que el modelo tenga de él. Los planes se ejecutan anidados: si un paso de una storyline se expandió en un plan, la storyline padre se reanuda exactamente donde se quedó cuando el plan termina.