Modelar un proceso como una Historia de Usuario — la forma correcta

Convertir un proceso complejo en un Storyline es un ejercicio de modelado, no de transcripción. La mecánica está en Compilar un flujo en un Storyline; esto es cómo pensar al respecto para que el resultado sea fiable en lugar de un grafo que funciona en su mayor parte.

Comienza desde el perfil, luego los puntos de decisión

Antes de dibujar nodos, decide qué estás rastreando — ese es el profile_schema (por ejemplo, docs_ready, risk_flag, attempts). Luego mapea los puntos de decisión reales, no solo el camino feliz. Cada lugar donde la conversación puede ramificarse o fallar es un nodo con salidas; un flujo que solo modela el camino ideal se rompe la primera vez que un usuario hace algo inesperado.

Un nodo = un paso coherente

Un nodo debe hacer una cosa que una persona nombraría ("recopilar documentos", "confirmar identidad"). No intentes meter todo un subproceso en la task de un solo nodo y esperar que el modelo lo secuencie: pierdes la capacidad de ramificar, reanudar y medir. Si la tarea de un nodo tiene "y luego, y luego", se trata de varios nodos.

Haz que el ramificado sea determinista donde el resultado debe ser fiable

• Enruta según rule (contra las dimensiones del perfil) o user_choice cuando la rama debe ser predecible. Reserva las salidas ai para juicios reales ("¿realmente describió su problema?").
• Las salidas están ordenadas por prioridad — coloca las deterministas primero y el ai como último recurso.
• Modela un bucle de reintento con una retroexición y un contador writes (op: "inc") y un límite rule. Nunca confíes en que el modelo decida que ha bufeado suficiente.

Mantén la identidad y la seguridad en el agente, no en el nodo

El soul del agente y su límite de seguridad son constantes en todo el Storyline — ese es el punto. No intentes repetir la personalidad ni imponer la seguridad por nodo; los nodos solo añaden tarea/habilidades/conocimiento/herramientas y escriben dimensiones del perfil.

Mantén los node_key estables; valida antes de publicar

Los node_key son la identidad de las salidas y la referencia del embudo. Cuando edites con update_storyline, mantén estables los node_key — renombrar un nodo orfana silenciosamente sus salidas. Siempre validate_storyline antes de publish_storyline; detecta nodos inalcanzables, callejones sin salida y salitudes colgantes.

No sobre-modelar

Si la tarea es una sola pregunta y respuesta, no es un Storyline — es un agente con una base de conocimientos. Recurre a un Storyline cuando haya un estado genuino de múltiples pasos que llevar (recolección, tutoría, una aplicación guiada). Modelar una pregunta y respuesta única como un grafo añade coste y modos de fallo por nada.

Formas comunes en las que se equivoca (evita esto)

• Solo camino feliz — no hay salida para "el usuario está confundido" o "no lo proporcionó", por lo que el flujo se estanca.
• Todo es una salida ai — el enrutamiento se convierte en una apuesta; la misma entrada toma diferentes caminos.
• Un mega-nodo — la task de un nodo describe todo el proceso; nada puede ramificarse o reanudarse.
• Bucles sin límite — una retroexición sin contador ni límite.
• Repetir la seguridad por nodo — ruido que compite con el límite real del agente.

Corrige esto nombrando los estados reales y moviendo cada decisión a una salida determinista.