La primera parte es un recorrido por recuperación de documentos y conversación con modelos; la segunda, la que importa, presenta los flujos como grafos con estado: nodos que hacen algo, aristas que deciden a dónde se sigue, un estado que viaja y un punto donde todo eso se guarda para poder retomarlo.
Qué saqué de él
La costumbre de dibujar el flujo antes de escribir la primera instrucción. Nodos, estado y condiciones de salida. Suena obvio y casi nadie lo hace: lo habitual es encadenar llamadas a un modelo hasta que la demostración funciona, y después nadie puede decir qué pasa cuando el tercer paso falla.
La segunda idea, que es la que defiendo frente a un cliente: el momento en que una persona aprueba tiene que ser un nodo del flujo, con su estado guardado, y no un correo aparte. Si la aprobación vive fuera del sistema, el sistema no sabe que está esperando, no sabe cuánto lleva esperando y no puede retomar donde quedó. La persistencia del estado es lo que convierte una demostración en algo que se puede operar.
La tercera es la memoria entendida como decisión de diseño y no como una casilla: qué se recuerda, por cuánto tiempo y quién puede verlo. En una empresa, esa última parte es una pregunta de permisos disfrazada de pregunta técnica.
Qué dejé fuera
El código. No por desprecio, sino porque estas bibliotecas cambian de nombre de funciones cada pocos meses y media docena de páginas ya no compilan igual. Hay además un desacuerdo de fondo: para un caso sencillo, llamar directamente a la interfaz del modelo es menos trabajo que aprender un marco que esconde lo que hace. El marco empieza a pagar cuando el flujo tiene estados, reintentos y personas de por medio; antes de eso, es peso muerto.