Workflows em múltiplas etapas como forma de reduzir a carga cognitiva

1. O que é um workflow no contexto de ChatGPT App

Se você já entendeu a autenticação, merece um bônus. Vamos passar para um assunto muito interessante — workflow em um ChatGPT App. A palavra “workflow” costuma acionar lembranças de diagramas BPMN e softwares corporativos entediantes. Calma: no contexto de ChatGPT App, nos interessa uma versão bem mais leve.

Em nosso curso, chamaremos workflow de um cenário em múltiplas etapas, no qual:

• há um objetivo claro (por exemplo, selecionar um presente e chegar à compra),
• há etapas sequenciais (levantamento → geração de opções → refinamento → final),
• em cada etapa há papéis específicos para o GPT, o widget e as ferramentas.

Ponto importante: workflow não é “um único método no servidor MCP”. É uma composição:

• do raciocínio do modelo (quais perguntas fazer, qual ferramenta chamar),
• de chamadas de tools (MCP/Agents),
• de etapas de UI no widget,
• de estado no backend.

Ou seja, você não tem um “super‑instrumento” solve_everything, mas vários simples, que entram em ação em fases diferentes. E não um “mega‑widget”, mas um conjunto pequeno de telas/estados, cada uma para sua sub‑tarefa.

“Triângulo de responsabilidades” no workflow

É útil pensar no workflow como uma dança de três participantes:

Esses três papéis implementam o mesmo cenário, mas em níveis diferentes: o GPT decide “o que vem depois”, o widget mostra “o que está agora”, e o MCP garante o que realmente acontece com os dados.

2. Exemplo de workflow baseado no GiftGenius

Vamos usar um cenário já conhecido, o GiftGenius — um assistente para escolher presentes. Ele pode ser descrito como um wizard linear simples.

A sequência de etapas pode ser:

1. Coletar informações básicas sobre o destinatário.
2. Definir orçamento e restrições.
3. Gerar e filtrar ideias de presentes.
4. Mostrar candidatos, permitir curtir/ocultar.
5. Ir para o checkout (Checkout) ou salvar a seleção.

O mesmo cenário pode ser representado como uma pequena “máquina de estados”:

stateDiagram-v2
    [*] --> Profiling
    Profiling --> ProfilingDone: perfil preenchido
    ProfilingDone --> Browsing: ideias geradas
    Browsing --> Refining: usuário ajustou os filtros
    Refining --> Browsing: lista atualizada
    Browsing --> Checkout: presente escolhido
    Checkout --> Success: pedido concluído
    Success --> [*]

Aqui:

• Profiling — etapa de coleta de respostas sobre o destinatário,
• Browsing/Refining — trabalho com a lista de candidatos,
• Checkout — finalização,
• Success — confirmação final.

Observe: no diagrama não há nenhum botão, nenhum fetch. São etapas lógicas; as telas de UI específicas, as tools e as chamadas de API você acopla sobre elas.

3. Por que dividir a tarefa em etapas

Se você já fez “um questionário com 25 perguntas em uma única tela”, já sabe por quê. Mas vamos detalhar por partes.

Carga cognitiva do usuário

O ser humano tem recursos de atenção limitados. Psicólogos gostam de lembrar a lei de Miller sobre 7±2 itens na memória de curto prazo. Em design de UX isso vira uma regra prática: quanto mais campos e opções você mostra de uma vez, maior a chance de o usuário travar, cansar ou fechar a aba.

Um formulário com 12 campos em uma única tela dentro de um widget inline do ChatGPT é praticamente garantia de rage‑quit: o usuário larga tudo e fecha a aba. Ele veio “conversar”, não fazer uma prova.

Se você divide a tarefa em etapas:

• “Etapa 1 de 4: conte sobre a pessoa”,
• “Etapa 2 de 4: escolha o orçamento”,
• “Etapa 3 de 4: veja as opções”,
• “Etapa 4 de 4: confirme a escolha”,

então cada momento específico parece viável. Uma barra de progresso ou a legenda das etapas dá sensação de controle: fica claro o que está acontecendo e quanto falta.

Carga cognitiva do modelo

Surpresa: o modelo tem problema parecido. Uma LLM não é humana, claro, mas também tem “atenção” e janela de contexto limitadas. Se você pede ao GPT em uma única passagem:

• descobrir tudo sobre o destinatário,
• lidar com o orçamento,
• considerar detalhes de entrega,
• selecionar 10 opções,
• explicar por que exatamente essas opções,

então, em cada subtarefa, o modelo gasta parte da atenção e dos tokens. Quanto mais tarefas desconexas em uma única solicitação, maior o risco de que alguma parte seja feita de forma superficial ou com erros.

Se você constrói uma cadeia de etapas — essencialmente o mesmo chain-of-thought, só que explicitamente distribuído na interface —, primeiro o modelo resolve a tarefa estreita “extrair o perfil”, depois “ajustar o orçamento”, depois “selecionar candidatos”. A qualidade do raciocínio do modelo (reasoning) em cada etapa aumenta de forma perceptível.

Manutenibilidade e depuração

Quando tudo é enfiado em uma única ferramenta e uma única tela, a depuração vira um caça‑tesouro: “Em que ponto exatamente ficou ruim?”

Em um workflow de múltiplas etapas, você ganha quase automaticamente:

• pontos de log: step_started, step_completed, step_failed,
• pontos claros para medir conversão (quantas pessoas chegaram à etapa 3),
• problemas localizados: “só quebra na etapa de geração de ideias”.

Tudo isso será útil no módulo sobre analytics de workflow, mas já agora vale a pena acostumar‑se a pensar em etapas.

4. Tipos de etapas em um workflow e como aparecem no UI

Já discutimos por que dividir a tarefa em etapas. Agora vamos organizar as etapas e ver quais “tijolos” mais comuns aparecem em um ChatGPT App. Para não cair em um conjunto caótico de telas, é útil ter uma “biblioteca” de tipos de etapas. No seu App, alguns padrões quase sempre se repetem.

Aqui está uma tabela básica:

É importante lembrar: a mesma etapa lógica pode aparecer tanto no UI quanto em diálogo puramente textual. Por exemplo, a etapa “coleta de interesses” pode ser:

• um formulário com tags “esporte”, “jogos de tabuleiro”, “culinária”,
• ou uma conversa em que o GPT pergunta educadamente: “De que ele/ela gosta?”.

Muitas vezes, o ideal é um híbrido: o GPT faz a pergunta, o usuário responde com texto e, ao mesmo tempo, pode clicar em chips no widget.

5. Quem “conduz” o workflow: GPT, widget ou servidor?

Intuitivamente, dá vontade de dizer: “Claro que o widget, somos frontend e controlamos tudo via state”. Mas no mundo de ChatGPT App não é assim que funciona. O workflow é um trabalho conjunto dos três participantes.

GPT como orquestrador

O GPT:

• conduz o diálogo, faz perguntas,
• decide quando a etapa pode ser considerada concluída,
• escolhe quando chamar uma tool (por exemplo, “é hora de gerar os presentes”).

Para ele, seu workflow parece um conjunto de subtarefas. No system prompt você pode descrever quais subtarefas existem e em que ordem geralmente executá‑las, mas deixa para o modelo certa liberdade para adaptar a sequência.

Exemplo de mini‑instrução dentro do system prompt para o GiftGenius (pseudocódigo, sem sintaxe exata):

1. Primeiro, esclareça o perfil do destinatário (idade, relação, interesses).
2. Depois, esclareça o orçamento.
3. Quando houver dados suficientes — chame a ferramenta suggest_gifts.
4. Após receber os candidatos — ajude o usuário a escolher.

O principal: o GPT não conhece (nem deve conhecer) os detalhes dos seus componentes React. Ele opera com etapas em termos de objetivos: “coletar o perfil”, “selecionar ideias”.

O widget como a “face” da etapa

O widget:

• exibe apenas a etapa que é relevante agora,
• armazena o estado de UI (card destacado, aba aberta, campos de formulário locais),
• pode mostrar um indicador de progresso das etapas.

A representação mais simples do UI workflow em código:

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

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

Dentro do widget React, você pode guardar esse estado em um useState comum ou, se quiser vinculá‑lo ao ciclo de vida do widget no ChatGPT, usar useWidgetState do Apps SDK.

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

Os handlers no widget não vão “comprar um presente” diretamente, mas sim mudar a etapa e enviar os dados necessários de volta ao modelo/backend.

MCP tools como as “mãos” do workflow

O servidor MCP:

• armazena o estado de negócio (perfil, histórico de escolhas),
• valida as etapas (“não é possível ir para Checkout se nenhum presente foi selecionado”),
• executa o trabalho pesado: busca no catálogo, cálculo de preços, integração com ACP.

Por exemplo, faz mais sentido que a decisão “quais presentes mostrar” seja tomada não no widget, mas na MCP tool suggest_gifts, para que o modelo possa chamá‑la várias vezes durante os refinamentos.

Assim, você tem a seguinte separação:

• GPT — texto e sequência,
• widget — representação visual da etapa atual,
• MCP — dados e invariantes.

6. Como descrever o workflow em código: mini state machine

Lembra do diagrama de estados do GiftGenius no início da aula? Agora vamos escrever a mesma lógica como tipos e funções simples — uma mini state machine no código. Não vamos transformar seu App em um curso teórico sobre autômatos finitos, mas alguns tipos e funções simples ajudam bastante.

Tipos de etapas e configuração

Vamos começar com a descrição declarativa das etapas. Vamos pegar o tipo GiftWorkflowStep (repetimos aqui por clareza) e descrever sua configuração:

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

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

export const GIFT_WORKFLOW_STEPS: Record<GiftWorkflowStep, StepConfig> = {
  profiling: { label: "Destinatário" },
  budget: { label: "Orçamento" },
  candidates: { label: "Opções" },
  checkout: { label: "Finalização", isFinal: true },
};

Agora podemos adicionar uma função de transição simples:

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
  }
}

Isso já oferece a você:

• uma lista centralizada de etapas,
• regras explícitas de transições,
• a possibilidade de mudar rapidamente a ordem e a lógica.

Usando no widget

A versão mais simples do “wizard” no seu widget pode ser assim:

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>
  );
}

O componente StepContent sabe renderizar diferentes sub‑formulários de acordo com a etapa:

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 />;
}

Observe: aqui ainda não tocamos em como o GPT escolhe a etapa — esta é a lógica local de UI. Depois você pode sincronizar esse step com o estado no servidor ou com mensagens das tools, mas para entender a multietapicidade isso já basta.

7. Evoluindo o app didático: do “megaformulário” ao wizard

Imagine que, até esta aula, seu widget do GiftGenius era um “formulário grande”:

• nome do destinatário,
• idade,
• interesses,
• orçamento,
• tipo do evento,
• checkboxes “precisa de entrega” e mais cinco campos,
• e um botão grande embaixo “Encontrar presente”.

Para protótipo isso muitas vezes é ok, mas assim que você quer um cenário de produto — é hora de dividir em etapas.

Como era “antes”

Um exemplo caricatural:

// Antipadrão: um formulário gigantesco
function GiftFormAllInOne() {
  return (
    <form>
      {/* 10+ campos misturados */}
      {/* ... */}
      <button type="submit">Encontrar presente</button>
    </form>
  );
}

Problemas típicos:

• o usuário não entende quais campos são obrigatórios,
• não fica claro quanto tempo isso vai levar,
• é mais difícil para o GPT explicar ao usuário o que aconteceu e fazer follow‑up.

Como fazer o “depois”: wizard em três telas

Etapa 1 — separar perfil do orçamento:

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

  const handleSubmit = () => {
    // aqui você pode chamar a tool para salvar o perfil
    props.onNext();
  };

  return (
    <div>
      <h3>Para quem estamos procurando um presente?</h3>
      {/* pares de radio/chips para tipo e interesses */}
      <button onClick={handleSubmit}>Avançar</button>
    </div>
  );
}

Etapa 2 — orçamento:

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

  const handleSubmit = () => {
    // você pode chamar a tool de validação de orçamento
    props.onNext();
  };

  return (
    <div>
      <h3>Qual é o seu orçamento?</h3>
      {/* slider ou input */}
      <button onClick={handleSubmit} disabled={!budget}>
        Encontrar opções
      </button>
    <div>
  );
}

Etapa 3 — lista de candidatos:

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

  // aqui você já mostra os cards de presentes
  // e permite escolher um

  return (
    <div>
      <h3>Escolha a opção adequada</h3>
      {/* cards com onClick = setSelectedId */}
      <button onClick={props.onNext} disabled={!selectedId}>
        Ir para a finalização
      </button>
    </div>
  );
}

Sim, há um pouco mais de código, mas a lógica ficou mais simples:

• cada etapa resolve uma tarefa pequena,
• o modelo pode comentar separadamente as transições entre as etapas,
• você pode fazer logs/medir cada etapa separadamente.

8. Antipadrões: como não transformar o workflow em um monstro

A prática e a observação de Apps semelhantes mostram alguns erros típicos que você deve evitar.

Primeiro, não tente “desenhar tudo” com um diagrama BPMN complexo, com 30 estados, 40 setas e um pôster A0. No contexto de ChatGPT App, o mais importante é uma escada de etapas intuitiva, não a notação formal. Diagramas como o que desenhamos para o GiftGenius já são suficientes.

Segundo, não transforme o App em um formulário enorme, especialmente dentro de um widget inline. O usuário já está no chat; adicionar um bloco de UI denso deve reduzir, não aumentar a carga. Se você pensa “são 12 campos, mas todos são importantes”, isso quase sempre indica que é preciso dividir a tarefa.

Terceiro, não crie etapas “por estética”. Cada etapa deve ter um objetivo claro: coletar dados, reduzir opções ou permitir que a pessoa confirme algo. Uma tela vazia como “só mais um pouco” com um único botão “avançar” raramente ajuda.

Por fim, não tente expor todos os recursos do App nas primeiras etapas. Itens detalhados como “filtros avançados”, “condições especiais de entrega” podem ser adicionados como etapas adicionais apenas para quem realmente precisa.

9. Um exercício simples de projeto de workflow

Para fixar melhor o conteúdo, tente fazer o seguinte no papel (ou na IDE, mas sem código).

Escolha uma tarefa. Pode ser:

• seleção de presentes (GiftGenius),
• reserva de viagem,
• montar um plano de estudos de algo.

Divida-a em 3–5 etapas. Para cada etapa, descreva:

• objetivo: o que deve ser conhecido/feito após esta etapa,
• formato: o que é mais adequado aqui — texto puro do GPT, widget ou uma combinação.

Por exemplo, para um “plano de estudos de TypeScript” simples:

1. Etapa “Avaliação de nível” — diálogo (o GPT faz algumas perguntas) + formulário curto de autoavaliação.
2. Etapa “Objetivos” — discussão em texto + checkboxes de objetivos no widget.
3. Etapa “Plano” — geração do plano (lista) + botões “dificultar/simplificar”.
4. Etapa “Confirmação” — breve resumo e botão “salvar plano”.

Depois, pense por alto quais tools poderiam ser usadas em cada etapa, mas sem entrar em detalhes: ferramentas, sua ativação/desativação e armazenamento de estado são temas das próximas aulas deste módulo.

10. Erros comuns ao trabalhar com workflows em múltiplas etapas

Erro nº 1: tentar resolver tudo em uma única etapa e com uma única tool.
É muito tentador fazer uma “grande ferramenta inteligente” que pergunta, analisa, seleciona e finaliza a compra. Na prática, isso piora o UX (uma tela pesada) e a qualidade do raciocínio do modelo (reasoning) — responsabilidades demais em uma única chamada. É mais simples, confiável e barato de manter dividir a tarefa em uma cadeia de 3–5 etapas simples.

Erro nº 2: etapas implícitas, escondidas na cabeça do desenvolvedor.
Às vezes, o código até tem uma sequência de ações, mas ela não está descrita explicitamente: não há tipos de etapas, nem configuração, nem diagrama. No fim, ninguém no time consegue responder claramente “o que acontece neste App do começo ao fim”. Uma descrição declarativa mínima de etapas e transições economiza horas de debug.

Erro nº 3: misturar etapas de UI e lógica de negócio.
Se a lógica das transições entre etapas está enfiada fundo nos componentes React (no estilo if (isValid && hasBudget && !needsShipping) no onClick do botão), fica difícil reutilizar e testar. É melhor quando existe uma “máquina de estados” relativamente explícita ou pelo menos funções como getNextStep, e o UI apenas a chama e exibe o resultado.

Erro nº 4: ignorar o papel do GPT como orquestrador.
Às vezes o desenvolvedor tenta controlar totalmente o cenário a partir do widget: “eu mesmo vou perguntar tudo, o modelo só seleciona”. O ChatGPT deixa de parecer um assistente vivo e vira um motor de cálculo por trás do formulário. É muito mais agradável quando o GPT conversa ativamente, impulsiona para a próxima etapa e ele mesmo inicia chamadas às tools — e você o ajuda com o design das etapas e as instruções.

Erro nº 5: etapas sem objetivo claro.
Às vezes aparecem etapas “extras” no wizard — sinceramente, só porque fica mais bonito. O usuário vê “Etapa 2 de 5”, mas nessa etapa quase nada é exigido e nada acontece de fato. Essas telas vazias só aumentam a sensação de complexidade. Se não dá para formular a etapa como “depois dela com certeza sabemos X” ou “depois dela o usuário fez Y”, provavelmente ela não é necessária.

Erro nº 6: esquecer o progresso e a sensação de caminho.
A multietapicidade sem suporte visual vira uma caixa‑preta: o usuário não entende onde está e quanto falta. Mesmo um indicador textual simples “Etapa 2 de 4” ou a enumeração horizontal das etapas no cabeçalho do widget reduz bastante a ansiedade. Ignorar esse efeito é uma das razões pelas quais as pessoas “desistem” no meio do cenário, embora pode não haver dificuldade real ali.