Workflows multietapa como manera de reducir la carga cognitiva

1. ¿Qué es un workflow en el contexto de ChatGPT App?

Bueno, si ya dominas la autorización, te has ganado una recompensa. Pasemos a un tema muy interesante: el workflow en ChatGPT App. En general, la palabra «workflow» a muchos les dispara flashbacks de diagramas BPMN y software corporativo plomizo. Tranquilidad: en el contexto de ChatGPT App nos interesa una versión mucho más ligera.

En nuestro curso por workflow entenderemos un escenario multietapa, en el que:

• hay un objetivo claro (por ejemplo, seleccionar un regalo y llevarlo hasta la compra),
• hay pasos secuenciales (encuesta → generación de opciones → afinado → final),
• en cada paso hay roles propios para GPT, el widget y las herramientas.

Un punto importante: un workflow no es «un único método en el servidor MCP». Es una composición:

• del razonamiento del modelo (qué preguntas hacer, qué herramienta invocar),
• de llamadas a tools (MCP/Agents),
• de pasos de UI en el widget,
• y del estado en el backend.

Es decir, no tenéis un «súper‑instrumento» solve_everything, sino varios sencillos que se activan en distintas etapas. Y no un «mega‑widget», sino un pequeño conjunto de pantallas/estados, cada uno para su subtarea.

«Triángulo de responsabilidad» en un workflow

Es útil pensar el workflow como un baile de tres participantes:

Estos tres roles implementan el mismo escenario, pero en distintos niveles: GPT decide «qué sigue», el widget muestra «qué hay ahora», y MCP se encarga de lo que realmente ocurre con los datos.

2. Ejemplo de workflow basado en GiftGenius

Tomemos el ya conocido escenario GiftGenius —un asistente para elegir regalos—. Se puede describir como un sencillo asistente lineal.

La secuencia de pasos puede ser así:

1. Recopilar la información básica del destinatario.
2. Definir el presupuesto y las restricciones.
3. Generar y filtrar ideas de regalo.
4. Mostrar candidatos y permitir dar like/ocultar.
5. Pasar a la tramitación (Checkout) o guardar la selección.

El mismo escenario puede representarse como una pequeña «máquina de estados»:

stateDiagram-v2
    [*] --> Profiling
    Profiling --> ProfilingDone: perfil completado
    ProfilingDone --> Browsing: ideas generadas
    Browsing --> Refining: el usuario afinó los filtros
    Refining --> Browsing: lista actualizada
    Browsing --> Checkout: regalo seleccionado
    Checkout --> Success: pedido tramitado
    Success --> [*]

Aquí:

• Profiling — paso de recopilación de respuestas sobre el destinatario,
• Browsing/Refining — trabajo con la lista de candidatos,
• Checkout — tramitación,
• Success — confirmación final.

Atención: en el diagrama no hay ni un botón ni un fetch. Son pasos lógicos, y sobre ellos colgáis las pantallas de UI, tools y llamadas a API concretas.

3. ¿Por qué fraccionar la tarea en pasos?

Si alguna vez hiciste «un cuestionario de 25 preguntas en una sola pantalla», ya sabes por qué. Pero vamos a desglosarlo.

Carga cognitiva del usuario

La atención humana es limitada. A los psicólogos les encanta recordar la ley de Miller sobre 7±2 objetos en la memoria a corto plazo. En UX esto se traduce en una regla muy práctica: cuanto más campos y opciones muestras a la vez, mayor la probabilidad de que el usuario se bloquee, se canse o cierre la pestaña.

Un formulario con 12 campos en una sola pantalla dentro de un widget inline pequeño de ChatGPT es casi un rage‑quit garantizado: el usuario lo deja y simplemente cierra la pestaña. El usuario vino a «conversar», no a hacer un examen.

Si, en cambio, divides la tarea en pasos:

• «Paso 1 de 4: cuéntanos sobre la persona»,
• «Paso 2 de 4: elige el presupuesto»,
• «Paso 3 de 4: revisa las opciones»,
• «Paso 4 de 4: confirma tu elección»,

cada momento concreto parece abordable. Una barra de progreso o el rotulado de pasos da sensación de control: se entiende qué está pasando y cuánto queda.

Carga cognitiva del modelo

Sorpresa: el modelo tiene un problema similar. Una LLM no es humana, claro, pero también tiene «atención» y una ventana de contexto limitadas. Si pides a GPT en una sola pasada:

• averiguar todo sobre el destinatario,
• resolver el presupuesto,
• tener en cuenta detalles de envío,
• elegir 10 opciones,
• explicar por qué esas opciones,

en cada subapartado el modelo gasta parte de su atención y de los tokens. Cuantas más tareas no relacionadas metas en una solicitud, mayor el riesgo de que algunas se hagan de forma superficial o con errores.

Si construyes una cadena de pasos —en esencia el mismo chain-of-thought, pero explícitamente desglosado en la interfaz—, primero el modelo resuelve la tarea estrecha de «extraer el perfil», luego «ajustar el presupuesto» y después «elegir candidatos». La calidad del razonamiento del modelo en cada etapa aumenta notablemente.

Mantenibilidad y depuración

Cuando todo está metido en una sola herramienta y una sola pantalla, la depuración se convierte en una gymkhana: «¿En qué punto exacto se estropeó?»

En un workflow multietapa casi automáticamente obtienes:

• puntos de logging: step_started, step_completed, step_failed,
• lugares claros para medir la conversión (cuánta gente llegó al paso 3),
• problemas localizados: «solo falla en el paso de generación de ideas».

Todo esto vendrá bien en el módulo sobre analítica de workflows, pero ya ahora conviene acostumbrarse a pensar en pasos.

4. Tipos de pasos en un workflow y cómo se ven en el UI

Ya hemos hablado de por qué dividir la tarea en pasos. Ahora ordenemos los propios pasos y veamos qué «bloques» típicos aparecen con más frecuencia en una ChatGPT App. Para no caer en un conjunto caótico de pantallas, es útil tener una «biblioteca» de tipos de paso. En tu App casi siempre se repetirán algunos patrones.

Aquí va una tabla básica:

Es importante recordar: un mismo paso lógico puede manifestarse tanto en el UI como en un diálogo puramente textual. Por ejemplo, el paso «recopilar intereses» puede ser:

• un formulario con tags «deporte», «juegos de mesa», «cocina»,
• o una conversación donde GPT pregunta con cuidado: «¿Qué le interesa?».

A menudo la opción óptima es un híbrido: GPT hace la pregunta, el usuario responde algo en texto y, a la vez, puede hacer clic en chips del widget.

5. ¿Quién «dirige» el workflow: GPT, el widget o el servidor?

Instintivamente apetece decir: «Claro que el widget, somos frontenders, lo controlamos todo con state». Pero en el mundo de ChatGPT App no funciona así. Un workflow es trabajo conjunto de los tres participantes.

GPT como orquestador

GPT:

• lleva el diálogo y hace las preguntas,
• decide cuándo puede darse por terminado un paso,
• elige cuándo llamar a una tool (por ejemplo, «es hora de generar regalos»).

Para él, tu workflow se ve como un conjunto de subtareas. En el system‑prompt puedes describir qué subtareas hay y en qué orden suele ejecutarlas, pero dejas al modelo cierta libertad para adaptar un poco la secuencia.

Ejemplo de mini‑instrucción dentro del system‑prompt para GiftGenius (pseudocódigo, sin sintaxis precisa):

1. Primero aclara el perfil del destinatario (edad, relación, intereses).
2. Luego aclara el presupuesto.
3. Cuando haya datos suficientes, invoca la herramienta suggest_gifts.
4. Tras recibir candidatos, ayuda al usuario a elegir.

Lo principal: GPT no sabe (ni debe saber) los detalles de tus componentes de React. Opera con pasos en términos de objetivos: «recopilar el perfil», «elegir ideas».

El widget como «la cara» del paso

El widget:

• muestra justamente el paso que ahora es relevante,
• guarda el estado de UI (tarjeta seleccionada, pestaña abierta, campos locales del formulario),
• puede mostrar un indicador de progreso por pasos.

Representación más simple del UI‑workflow en código:

type GiftWorkflowStep =
  | "profiling"
  | "budget"
  | "candidates"
  | "checkout";

type GiftWidgetState = {
  step: GiftWorkflowStep;
  selectedGiftId?: string;
};

Dentro del widget de React puedes guardar este estado en un useState normal o, si quieres ligarlo al ciclo de vida del widget en ChatGPT, usar useWidgetState del Apps SDK.

const [widgetState, setWidgetState] = useState<GiftWidgetState>({
  step: "profiling",
});

Las funciones manejadoras en el widget no «compran el regalo» directamente, sino que cambian el paso y pasan los datos necesarios de vuelta al modelo/backend.

MCP‑tools como «las manos» del workflow

El servidor MCP:

• guarda el estado de negocio (perfil, historial de elecciones),
• valida los pasos («no se puede pasar a Checkout si no hay regalo seleccionado»),
• realiza el trabajo pesado: búsqueda en el catálogo, cálculo de precios, integración con ACP.

Por ejemplo, es más correcto que la decisión de «qué regalos mostrar» se tome no en el widget, sino en la herramienta MCP suggest_gifts, para que el modelo pueda invocarla repetidamente al afinar.

Así consigues una separación:

• GPT — texto y secuencia,
• widget — representación visual del paso actual,
• MCP — datos e invariantes.

6. Cómo describir el workflow en código: mini state‑machine

¿Recuerdas el diagrama de estados para GiftGenius del principio de la lección? Ahora escribiremos la misma lógica en forma de tipos y funciones sencillas —una mini state‑machine en código—. No vamos a convertir tu App en un curso teórico de autómatas finitos, pero un par de tipos y funciones simplifican mucho la vida.

Tipos de paso y configuración

Empecemos con la descripción declarativa de los pasos. Tomemos el tipo ya conocido GiftWorkflowStep (lo repetimos aquí por claridad) y describamos su configuración:

type GiftWorkflowStep =
  | "profiling"
  | "budget"
  | "candidates"
  | "checkout";

type StepConfig = {
  label: string;
  isFinal?: boolean;
};

export const GIFT_WORKFLOW_STEPS: Record<GiftWorkflowStep, StepConfig> = {
  profiling: { label: "Destinatario" },
  budget: { label: "Presupuesto" },
  candidates: { label: "Opciones" },
  checkout: { label: "Tramitación", isFinal: true },
};

Ahora podemos añadir una función de transición simple:

export function getNextStep(
  current: GiftWorkflowStep
): GiftWorkflowStep | null {
  switch (current) {
    case "profiling":
      return "budget";
    case "budget":
      return "candidates";
    case "candidates":
      return "checkout";
    default:
      return null; // final
  }
}

Esto ya te da:

• una lista centralizada de pasos,
• reglas de transición explícitas,
• posibilidad de cambiar rápido el orden y la lógica.

Usarlo en el widget

La versión más simple del «asistente» en tu widget puede verse así:

function GiftWizard() {
  const [step, setStep] = useState<GiftWorkflowStep>("profiling");

  const handleStepComplete = () => {
    const next = getNextStep(step);
    if (next) setStep(next);
  };

  return (
    <div>
      <ProgressBar step={step} />
      <StepContent step={step} onComplete={handleStepComplete} />
    </div>
  );
}

El componente StepContent sabe renderizar distintos subformularios según el paso:

function StepContent(props: {
  step: GiftWorkflowStep;
  onComplete: () => void;
}) {
  const { step, onComplete } = props;

  if (step === "profiling") {
    return <ProfilingStep onNext={onComplete} />;
  }
  if (step === "budget") {
    return <BudgetStep onNext={onComplete} />;
  }
  if (step === "candidates") {
    return <CandidatesStep onNext={onComplete} />;
  }
  return <CheckoutStep />;
}

Atención: aquí todavía no tocamos cómo GPT elige el paso —esto es lógica local de UI—. Más adelante puedes sincronizar este step con el estado del servidor o con mensajes de tools, pero para entender la multietapa esto basta.

7. Evolucionar la app de práctica: de «mega‑formulario» a asistente

Imagina que hasta esta lección tu widget de GiftGenius era un «formulario grande»:

• nombre del destinatario,
• edad,
• intereses,
• presupuesto,
• tipo de evento,
• checkboxes «necesito envío» y otros cinco campos,
• y abajo un gran botón «Elegir un regalo».

Para un prototipo esto suele valer, pero en cuanto quieras un escenario de producto, es hora de dividir en pasos.

Cómo era «antes»

Ejemplo caricaturesco:

// Antipatrón: un formulario enorme
function GiftFormAllInOne() {
  return (
    <form>
      {/* 10+ campos mezclados */}
      {/* ... */}
      <button type="submit">Elegir un regalo</button>
    </form>
  );
}

Problemas típicos:

• el usuario no entiende qué campos son obligatorios,
• no se sabe cuánto tiempo llevará,
• es más difícil para GPT explicar al usuario qué ha pasado y hacer follow‑up.

Cómo hacerlo «después»: asistente de tres pantallas

Paso 1 — separar el perfil del presupuesto:

function ProfilingStep(props: { onNext: () => void }) {
  const [recipientType, setRecipientType] = useState("");
  const [interests, setInterests] = useState<string[]>([]);

  const handleSubmit = () => {
    // aquí se puede invocar la tool de guardado de perfil
    props.onNext();
  };

  return (
    <div>
      <h3>¿Para quién buscamos un regalo?</h3>
      {/* pares de radios / chips para el tipo e intereses */}
      <button onClick={handleSubmit}>Siguiente</button>
    </div>
  );
}

Paso 2 — presupuesto:

function BudgetStep(props: { onNext: () => void }) {
  const [budget, setBudget] = useState<number | null>(null);

  const handleSubmit = () => {
    // se puede invocar la tool de validación de presupuesto
    props.onNext();
  };

  return (
    <div>
      <h3>¿Cuál es tu presupuesto?</h3>
      {/* slider o input */}
      <button onClick={handleSubmit} disabled={!budget}>
        Buscar opciones
      </button>
    </div>
  );
}

Paso 3 — lista de candidatos:

function CandidatesStep(props: { onNext: () => void }) {
  const [selectedId, setSelectedId] = useState<string | null>(null);

  // aquí ya muestras las tarjetas de regalos
  // y permites elegir uno

  return (
    <div>
      <h3>Elige la opción adecuada</h3>
      {/* tarjetas con onClick = setSelectedId */}
      <button onClick={props.onNext} disabled={!selectedId}>
        Ir a la tramitación
      </button>
    </div>
  );
}

Sí, hay un poco más de código, pero la lógica es más simple:

• cada paso resuelve una tarea pequeña,
• el modelo puede comentar por separado las transiciones entre pasos,
• puedes registrar/medir cada paso por separado.

8. Antipatrones: cómo no convertir el workflow en un monstruo

La práctica y la observación de apps parecidas muestran varios errores típicos que conviene evitar.

Primero, no intentéis «dibujarlo todo» con un diagrama BPMN complejo con 30 estados, 40 flechas y un pliego A0. En el contexto de ChatGPT App es más importante una escalera de pasos intuitiva que una notación formal. Bastan diagramas como el que dibujamos para GiftGenius.

Segundo, no convirtáis la App en un formulario gigantesco, especialmente dentro de un widget inline. El usuario ya está en un chat; añadir un bloque de UI denso debe reducir, no aumentar, la carga. Si te sorprendes pensando «son 12 campos, pero todos son importantes», casi siempre es señal de que hay que dividir la tarea.

Tercero, no hagas pasos «por estética». Cada paso debe tener un objetivo claro: o recopilar datos, o reducir opciones, o permitir confirmar algo. Una pantalla vacía del tipo «ya casi» con un único botón «siguiente» rara vez ayuda.

Por último, no intentes enseñar todas las posibilidades de la App en los primeros pasos. Detalles como «filtros avanzados» o «condiciones especiales de envío» se pueden añadir como pasos adicionales solo para quien realmente los necesite.

9. Ejercicio sencillo de diseño de workflow

Para asentar mejor el material, intenta en papel (o en el IDE, pero sin código) hacer lo siguiente.

Toma una tarea. Puede ser:

• elección de un regalo (GiftGenius),
• reservar un viaje,
• construir un plan de aprendizaje de algo.

Divídela en 3–5 pasos. Para cada paso describe:

• el objetivo: qué debe saberse/hacerse tras ese paso,
• el formato: qué encaja mejor aquí —texto puro de GPT, widget o combinación—.

Por ejemplo, para un «plan de aprendizaje de TypeScript» sencillo:

1. Paso «Evaluación del nivel» — diálogo (GPT hace un par de preguntas) + formulario corto de autoevaluación.
2. Paso «Objetivos» — discusión textual + checkboxes de objetivos en el widget.
3. Paso «Plan» — generación del plan (lista) + botones «complicar/simplificar».
4. Paso «Confirmación» — breve resumen y botón «guardar plan».

Luego intenta esbozar qué tools podrían intervenir en cada paso, pero sin entrar en detalles: las herramientas, su activación/desactivación y el guardado de estado son temas de las siguientes lecciones de este módulo.

10. Errores típicos al trabajar con workflows multietapa

Error n.º 1: intentar resolverlo todo con un solo paso y una sola tool.
Es muy tentador crear una «herramienta grande e inteligente» que pregunte, analice, seleccione y además tramite la compra. En la práctica empeora el UX (una pantalla pesada) y la calidad del razonamiento del modelo —demasiadas responsabilidades en una sola llamada—. Es más simple, fiable y barato de mantener dividir la tarea en una cadena de 3–5 pasos sencillos.

Error n.º 2: pasos implícitos, escondidos en la cabeza del desarrollador.
A veces en el código parece haber una secuencia de acciones, pero no está descrita en ninguna parte: no hay tipos de pasos, ni configuración, ni diagrama. Al final nadie en el equipo puede responder con claridad «qué pasa en esta App de principio a fin». Una descripción declarativa mínima de los pasos y transiciones ahorra horas de depuración.

Error n.º 3: mezclar pasos de UI y lógica de negocio.
Si la lógica de transiciones entre pasos está metida a fondo en los componentes de React (al estilo if (isValid && hasBudget && !needsShipping) en el onClick del botón), se vuelve difícil de reutilizar y probar. Es mejor tener una «máquina de estados» relativamente explícita o al menos funciones como getNextStep, y que el UI solo la invoque y muestre el resultado.

Error n.º 4: ignorar el papel de GPT como orquestador.
A veces el desarrollador intenta controlar por completo el escenario desde el widget: «yo pregunto todo lo necesario, que el modelo solo elija». Como resultado, ChatGPT deja de parecer un asistente vivo y se convierte en un motor de cálculo detrás del formulario. Es mucho más agradable cuando GPT conversa activamente, empuja hacia el siguiente paso e inicia por sí mismo llamadas a tools, y tú le ayudas con el diseño de pasos y las instrucciones.

Error n.º 5: pasos sin objetivo claro.
A veces aparecen pasos «de relleno» en el asistente —seamos honestos, porque queda más bonito—. El usuario ve «Paso 2 de 5», pero en ese paso apenas se le pide nada ni ocurre nada. Esas pantallas vacías solo aumentan la sensación de complejidad. Si no puedes formular el paso como «después de él sabemos X con certeza» o «después de él el usuario hizo Y», probablemente no hace falta.

Error n.º 6: olvidar el progreso y la sensación de recorrido.
La multietapa sin soporte visual se convierte en una caja negra: el usuario no entiende dónde está ni cuánto queda. Incluso un indicador textual simple «Paso 2 de 4» o un listado horizontal de los pasos en la cabecera del widget reduce notablemente la ansiedad. Ignorar este efecto es una de las razones por las que la gente «se cae» a mitad del escenario, aunque puede que no haya dificultad real.