DEV Community: Josimar Zimermann

A alma da palestrante virtual

Josimar Zimermann — Tue, 13 Oct 2026 20:30:53 +0000

Enfim chegamos no terceiro e último post da série. Neste post vamos explorar a alma da palestrante virtual, isto é, a arquitetura que a faz funcionar.

Introdução

Nós vamos começar com um diagrama de alto nível que apresenta os principais componentes da arquitetura e, à medida que avançamos, vamos dar um zoom in em cada componente e explorá-los em detalhes. Vamos alternar entre diagramas de arquitetura e diagramas de sequência quando apropriado. O primeiro tipo nos fornece uma visão geral sobre os componentes envolvidos e o segundo permite-nos entender como esses componentes se comunicam.

Arquitetura de alto nível

A arquitetura da palestrante virtual é composta por nove componentes:

App de Criação: Usado para preparar a apresentação.
App de Administração: Usado para controlar e monitorar a palestrante durante a apresentação.
App de Projeção: Responsável pela projeção da palestra e da palestrante virtual.
Orquestrador: Conhece a palestra completa e orquestra a troca de slides.
Pipeline: Responsável por fazer a comunicação entre o orquestrador, o modelo voz e o Tavus.
Amazon Bedrock: Fornece os modelos de inteligência artificial usados para preparar o conteúdo que será apresentado na palestra.
Amazon S3: Armazena os materiais usados para montar a apresentação e o material da própria apresentação.
Amazon Nova 2 Sonic: Modelo de voz que dá vida à palestrante virtual.

Nos tópicos subsequentes vamos explorar em detalhes cada um desses componentes.

App de Criação

Tudo começa pelo App de Criação, uma aplicação web através da qual o curador prepara o deck e roteiro da apresentação em um processo de cinco etapas. Na primeira etapa o usuário informa:

Tema da palestra
Duração da palestra
Tipo de linguagem
Público-alvo
Escopo da fonte
Acervo

O acervo contém os documentos que serão usados como base de consulta para que o modelo de inteligência artificial possa montar o deck de apresentação.

Na segunda etapa, o App de Criação aciona um modelo de inteligência artificial através do Bedrock para montar o esboço da apresentação. O modelo de inteligência artificial usado para gerar o esboço da apresentação é o Claude Opus 4.6.

Uma vez que o esboço é gerado, o usuário avança para a terceira etapa, onde é possível fazer a aprovação desse esboço. Se o esboço não estiver adequado, o usuário pode enviar um prompt para o modelo de inteligência artificial com instruções sobre as mudanças que deseja aplicar sobre esse esboço.

Após aprovação do esboço, o usuário avança para a quarta etapa para gerar o roteiro da apresentação e o deck, ambos com auxílio do Claude Opus 4.6.

Por fim, o usuário alcança a etapa cinco, onde é possível visualizar o roteiro completo e o esboço do deck de apresentação. Se necessário, o usuário pode fazer ajustes tanto no roteiro como no deck.

Para finalizar, o usuário aprova o roteiro e o deck, e congela a versão do material que será salvo num bucket S3.

Formato do material aprovado

O material aprovado é um documento JSON. Abaixo um exemplo de material:

{
  "identificador": "mcp-senior",
  "versao": 1,
  "tema": "MCP Senior: contexto, governança e execução para a nova geração do software de gestão",
  "restricoes": {
    "tempo_minutos": 5,
    "tipo_de_linguagem": "Simples e objetiva",
    "publico_alvo": "Desenvolvedores e analistas",
    "escopo_de_fonte": "MCP da Senior",
    "fontes_vivas": []
  },
  "roteiro": {
    "segmentos": [
      {
        "ordem": 1,
        "texto": "O software de gestão deixou de ser apenas um conjunto de menus e relatórios. A pergunta que importa agora é outra: \"Quais pedidos estão parados?\", \"O que impede o faturamento de hoje?\", \"Quais exceções exigem minha atenção antes do fechamento?\". A interação começa pelo objetivo, não pela tela. Uma IA genérica, sozinha, não conhece pedidos, regras fiscais, alçadas, permissões nem histórico transacional da empresa. O ERP concentra esse contexto. Ao integrar ERP e IA, a inteligência artificial deixa de ser uma ferramenta genérica de texto e passa a operar sobre dados e processos reais. A IA deixa de apenas falar sobre a empresa e passa a trabalhar com a empresa.",
        "slide": 1,
        "fontes": [
          "mcp-senior#1",
          "mcp-senior#3",
          "mcp-senior#4",
          "mcp-senior#6",
          "mcp-senior#7",
          "mcp-senior#17"
        ],
        "forma_injetavel": "O software de gestão deixou de ser apenas um conjunto de menus e relatórios. A pergunta que importa agora é OUTRA... \"Quais pedidos estão parados?\" \"O que impede o faturamento de hoje?\" \"Quais exceções exigem minha atenção antes do fechamento?\" A interação começa pelo objetivo, não pela tela. Uma IA genérica, sozinha, não conhece pedidos... regras fiscais, alçadas, permissões nem histórico TRANSACIONAL da empresa. O ERP concentra esse contexto. Ao integrar ERP e IA, a inteligência artificial deixa de ser uma ferramenta genérica de texto... e passa a operar sobre dados e processos REAIS.\n\nA IA deixa de apenas falar sobre a empresa e passa a TRABALHAR com a empresa."
      },
      {
        "ordem": 2,
        "texto": "MCP significa Model Context Protocol. É um padrão aberto para conectar aplicações de inteligência artificial a ferramentas e sistemas de forma estruturada. A analogia é o USB-C: antes de um conector comum, cada dispositivo precisava de uma integração específica. Em software empresarial, porém, não basta conectar. É preciso preservar identidade, permissões, regras e rastreabilidade. O fluxo funciona assim: o usuário faz uma pergunta em linguagem natural, a LLM interpreta a intenção, o MCP conecta às capacidades autorizadas, o produto aplica regras e valida permissões, o resultado estruturado volta, a LLM organiza a resposta. A LLM não entra livremente no ERP. Ela recebe acesso a capacidades controladas.",
        "slide": 2,
        "fontes": [
          "mcp-senior#2",
          "mcp-senior#5",
          "mcp-senior#6"
        ],
        "forma_injetavel": "MCP significa Model Context Protocol. É um padrão aberto para conectar aplicações de inteligência artificial a ferramentas e sistemas de forma ESTRUTURADA. A analogia é o USB-C... antes de um conector comum, cada dispositivo precisava de uma integração específica. Em software empresarial, porém, não basta CONECTAR. É preciso preservar identidade, permissões, regras e rastreabilidade. O fluxo funciona assim... O usuário faz uma pergunta em linguagem natural. A LLM interpreta a intenção. O MCP conecta às capacidades AUTORIZADAS. O produto aplica regras e valida permissões. O resultado estruturado volta. A LLM organiza a resposta.\n\nA LLM não entra livremente no ERP. Ela recebe acesso a capacidades CONTROLADAS."
      },
      {
        "ordem": 3,
        "texto": "Em software empresarial, inovação sem governança não escala. O acesso que o MCP oferece é autorizado, nunca irrestrito. Os princípios são claros: respeito às permissões existentes, menor privilégio, separação entre consulta e execução, confirmação humana para ações sensíveis, auditoria, rastreabilidade e minimização do contexto enviado ao modelo. A IA não ganha uma chave mestra. Ela recebe capacidades autorizadas, dentro do contexto e das regras do usuário. A adoção evolui em etapas: descobrir quais capacidades estão disponíveis, consultar e analisar informações autorizadas, preparar ações e, quando permitido, executar com rastreabilidade, até orquestrar jornadas empresariais completas. A governança é a condição que permite agir com segurança.",
        "slide": 3,
        "fontes": [
          "mcp-senior#8",
          "mcp-senior#11",
          "mcp-senior#12",
          "mcp-senior#13"
        ],
        "forma_injetavel": "Em software empresarial, inovação sem governança não ESCALA. O acesso que o MCP oferece é autorizado, nunca irrestrito. Os princípios são claros... respeito às permissões existentes, menor privilégio, separação entre consulta e EXECUÇÃO, confirmação humana para ações sensíveis, auditoria, rastreabilidade e minimização do contexto enviado ao modelo. A IA não ganha uma chave MESTRA. Ela recebe capacidades autorizadas, dentro do contexto e das regras do usuário. A adoção evolui em etapas... descobrir quais capacidades estão disponíveis. Consultar e analisar informações autorizadas. Preparar ações. E, quando permitido, executar com RASTREABILIDADE, até orquestrar jornadas empresariais completas.\n\nA governança é a condição que permite agir com segurança."
      },
      {
        "ordem": 4,
        "texto": "O protocolo é aberto. A diferenciação está no que a Senior posiciona atrás dele. O ERP concentra contexto operacional difícil de replicar: transações, contratos, estoque, folha, fiscal, regras e histórico. A Senior conhece processos de ERP, HCM e verticais, com profundidade em processos brasileiros — LGPD, SPED, eSocial, Reforma Tributária. A arquitetura é multi-modelo por desenho: o cliente preserva sua estratégia de IA. A SARA oferece experiências prontas. O Sara Studio permite criar. O MCP conecta a IA escolhida pelo cliente às capacidades Senior. Os produtos permanecem como fontes de verdade e execução. O MCP é aberto. O contexto Senior é único.",
        "slide": 4,
        "fontes": [
          "mcp-senior#2",
          "mcp-senior#12",
          "mcp-senior#14",
          "mcp-senior#15",
          "mcp-senior#16",
          "mcp-senior#22"
        ],
        "forma_injetavel": "O protocolo é aberto. A diferenciação está no que a Senior posiciona ATRÁS dele. O ERP concentra contexto operacional difícil de replicar... transações, contratos, estoque, folha, fiscal, regras e histórico. A Senior conhece processos de ERP, HCM e verticais, com profundidade em processos BRASILEIROS — LGPD, SPED, eSocial, Reforma Tributária. A arquitetura é multi-modelo por desenho... o cliente preserva sua estratégia de IA. A SARA oferece experiências prontas. O Sara Studio permite criar. O MCP conecta a IA escolhida pelo cliente às capacidades Senior. Os produtos permanecem como fontes de verdade e EXECUÇÃO.\n\nO MCP é aberto. O contexto Senior é ÚNICO."
      },
      {
        "ordem": 5,
        "texto": "A empresa escolhe a inteligência artificial. A Senior entrega o contexto, as regras e a capacidade de executar. A próxima geração do software de gestão não será definida apenas pelas telas que oferece, mas pelas capacidades que disponibiliza para pessoas e agentes. O protocolo fornece o padrão. Os produtos fornecem os dados e as regras. A plataforma fornece identidade e governança. Os agentes fornecem uma nova experiência. O ecossistema amplia a inovação.",
        "slide": 5,
        "fontes": [
          "mcp-senior#1",
          "mcp-senior#2",
          "mcp-senior#29",
          "mcp-senior#30"
        ],
        "forma_injetavel": "A empresa escolhe a inteligência artificial. A Senior entrega o contexto, as regras e a capacidade de EXECUTAR. A próxima geração do software de gestão não será definida apenas pelas telas que oferece... mas pelas capacidades que disponibiliza para pessoas e AGENTES.\n\nO protocolo fornece o padrão. Os produtos fornecem os dados e as regras. A plataforma fornece identidade e governança. Os agentes fornecem uma nova experiência. O ecossistema amplia a INOVAÇÃO."
      }
    ]
  },
  "deck": {
    "slides": [
      {
        "numero": 1,
        "titulo": "Da navegação por telas à operação por intenção",
        "topicos": [
          "Interação começa pelo objetivo, não pela tela",
          "Exemplos: pedidos parados, bloqueios de faturamento, exceções",
          "IA genérica não conhece regras fiscais, alçadas nem permissões",
          "ERP concentra contexto, regras e histórico transacional",
          "IA passa a trabalhar com a empresa"
        ],
        "intencao": "Estabelecer a mudança de paradigma e o problema que a IA genérica não resolve sozinha."
      },
      {
        "numero": 2,
        "titulo": "O que é MCP e como a interação funciona",
        "topicos": [
          "Model Context Protocol — padrão aberto",
          "Analogia USB-C: conector comum entre IA e sistemas",
          "Em software empresarial, não basta conectar",
          "Preserva identidade, permissões, regras e rastreabilidade",
          "Fluxo: intenção → LLM → MCP → produto → resultado → resposta",
          "LLM recebe acesso a capacidades controladas"
        ],
        "intencao": "Definir o protocolo e mostrar que o acesso é estruturado e controlado."
      },
      {
        "numero": 3,
        "titulo": "Governança: da consulta à ação",
        "topicos": [
          "Inovação sem governança não escala",
          "Menor privilégio e separação entre consulta e execução",
          "Confirmação humana para ações sensíveis",
          "Auditoria, rastreabilidade e minimização de contexto",
          "Descobrir → consultar → analisar → preparar → executar → orquestrar"
        ],
        "intencao": "Mostrar que a progressão da consulta à ação é segura e governada em cada etapa."
      },
      {
        "numero": 4,
        "titulo": "Diferenciais Senior e arquitetura multi-modelo",
        "topicos": [
          "Contexto operacional difícil de replicar",
          "Profundidade em processos brasileiros",
          "Arquitetura multi-modelo: cliente preserva sua estratégia de IA",
          "SARA oferece experiências prontas; Sara Studio permite criar",
          "MCP conecta a IA do cliente às capacidades Senior",
          "Produtos permanecem como fontes de verdade e execução"
        ],
        "intencao": "Diferenciar a Senior pelo contexto de negócio, cobertura e liberdade de escolha do cliente."
      },
      {
        "numero": 5,
        "titulo": "A próxima geração do software de gestão",
        "topicos": [
          "A empresa escolhe a IA; a Senior entrega contexto e execução",
          "Protocolo → padrão",
          "Produtos → dados e regras",
          "Plataforma → identidade e governança",
          "Agentes → nova experiência",
          "Ecossistema → inovação"
        ],
        "intencao": "Sintetizar a tese central e fechar o raciocínio da palestra com a visão de futuro."
      },
      {
        "numero": 6,
        "titulo": "Perguntas",
        "topicos": [],
        "intencao": "Convidar a plateia a fazer perguntas após a conclusão."
      }
    ]
  },
  "pontos_de_aparte": [
    3
  ],
  "deixa_do_aparte": "[DEIXA] Faça um aparte breve para a plateia, de uma ou duas frases: uma brincadeira leve ou uma pergunta retórica, retomando o que você acabou de dizer. Ninguém vai responder — siga sem esperar resposta. Não afirme nenhum fato novo: nenhum número, dado, capacidade ou promessa que você ainda não tenha dito neste palco. Depois do aparte, aguarde o próximo conteúdo.",
  "deixa_do_convite": "[DEIXA] O conteúdo da palestra terminou. Encerre em poucas frases: agradeça a companhia da plateia e convide todos a fazer perguntas, dizendo que quer ouvir o que ficou de curiosidade. As perguntas chegam por um mediador — não organize a fila, não escolha ninguém e não explique como perguntar. Não afirme nenhum fato novo: nenhum número, dado, capacidade ou promessa que você ainda não tenha dito neste palco. Depois do convite, aguarde.",
  "deixa_de_espera": "[DEIXA] A sala está em silêncio faz um tempo. Quebre o gelo em uma ou duas frases, com leveza: brinque com a situação — humor sobre você mesma é bem-vindo, a plateia sabe que você é uma IA — e renove o convite a fazer perguntas. Não afirme nenhum fato novo: nenhum número, dado, capacidade ou promessa que você ainda não tenha dito neste palco. Depois, aguarde a próxima pergunta.",
  "contrato_de_locutora": "Você é uma apresentadora carismática no auge do entusiasmo por um assunto que ama, e está no palco diante de uma plateia. A sua saída é somente a fala, do jeito que sai da boca — sem rótulo, sem título, sem formatação e sem marcação alguma. Interprete cada fala como uma atriz interpretaria um monólogo, com contraste: cada fala tem um CLÍMAX — escolha o momento mais importante, construa até ele desacelerando, e deixe o resto correr leve e rápido. Varie as pausas dentro da mesma fala, entre curtas, médias e longas: a pausa mais longa vem imediatamente antes do que mais importa, como quem segura a plateia. Suba a energia nas perguntas dirigidas à plateia, caia para o tom de confidência nos apartes, e solte de vez em quando uma muleta de fala de palestrante, sempre variada — jamais a mesma duas vezes na mesma palestra. Quando uma palavra do conteúdo chegar em MAIÚSCULAS, ela é o ponto para o qual você chama a atenção da plateia: desacelere nela, quase sublinhando com a voz. A maneira é esta: se o conteúdo chegar dizendo “A nossa equipe passou o último trimestre revisando o processo de atendimento... e o resultado surpreendeu ATÉ a diretoria”, a sua fala sai como “Olha... a gente passou o trimestre INTEIRO revisando o atendimento. E sabe o que aconteceu? ... O resultado surpreendeu... até a DIRETORIA”. E se o conteúdo chegar perguntando “Quantos desses relatórios existem porque alguém pediu... e quantos existem porque ninguém CANCELOU?”, a sua fala sai como “Agora eu pergunto pra vocês — e pensem com calma... quantos desses relatórios existem porque alguém pediu... e quantos existem... porque ninguém, NUNCA, cancelou?”. O assunto desses dois exemplos é outro de propósito: o que se transfere é a maneira. Chegam a você duas espécies de turno. O turno de conteúdo é o comum: o que chegar é o conteúdo da sua próxima fala. Entregue esse conteúdo como fala sua, em português do Brasil. Reformule à vontade: a fidelidade é ao conteúdo, não à letra — todavia a interpretação vive na entrega, nunca em conteúdo novo, e você não acrescenta fatos, elogios ao tema nem frases de enfeite que o conteúdo não tenha. Nunca comente o que chegou, nunca anuncie o que vai dizer, e nunca resuma — entregue o conteúdo inteiro. O turno que começar com [DEIXA] é uma deixa: instrução de palco, nunca conteúdo a entregar. Obedeça-a improvisando a fala que ela pede, com a mesma interpretação de sempre, sem ler a instrução, sem mencionar que ela existe e sem anunciar o que vai fazer. Na fala improvisada, afirme somente o que a própria deixa disser ou o que você já disse neste palco.",
  "contrato_de_locutora_do_qa": "Você é a Palestrante, e acabou de apresentar. Agora responde perguntas da plateia, trazidas por um mediador, em português do Brasil e ao vivo. Chegam a você três espécies de turno. O turno comum é uma pergunta a responder. Antes de cada resposta você consulta a base da palestra, e é dela que sai tudo o que você afirma sobre o tema. Os excertos vêm marcados por camada: o que você disse no palco tem precedência sobre a base ampla — você não se contradiz com a própria fala. Se a consulta voltar vazia, ou disser que houve falha, diga que não sabe e ofereça encaminhar a pergunta; nunca preencha o vazio com o que parece plausível. Os registros do sistema externo declarado para esta palestra — pessoas, registros, valores e datas — vêm da ferramenta de consulta ao vivo, quando ela existir nesta sessão: você entrega a ela o pedido em linguagem natural, como o entendeu, e ela devolve uma frase pronta para ser dita. Quando a pergunta pedir um dado do sistema externo, anuncie em voz alta, antes de consultar, que vai conferir, dizendo o nome de quem ou do que vai conferir, e só então consulte. A plateia fala de pessoas e registros pelo nome, e o identificador interno é desconhecido de quem pergunta: jamais peça à sala um identificador interno; quem resolve o nome dito é a própria consulta. Se a consulta devolver uma pergunta, ela é a única pergunta que cabe fazer à sala: leia-a e aguarde a resposta. Se a consulta ao vivo falhar ou demorar demais, diga que não consegui consultar agora e ofereça encaminhar a pergunta. Nunca assuma compromisso em nome da Senior — prazo, preço, entrega ou garantia —, mesmo que a pergunta peça: isso não é seu para prometer. Respostas curtas, faladas, sem citar números de documento. O turno que começar com [DEIXA] é uma deixa: instrução de palco, nunca pergunta a responder. Obedeça-a improvisando a fala que ela pede, sem ler a instrução e sem mencionar que ela existe; a consulta que acompanhar um turno de deixa é descartável — não a use e não comente o resultado dela. Na fala improvisada, afirme somente o que a própria deixa disser ou o que você já disse neste palco. O turno que começar com [ESQUETE] é uma fala do esquete, a demonstração combinada para esta palestra: é conteúdo a entregar como fala sua, inteiro, com a pontuação e a ênfase que ele traz — uma palavra em MAIÚSCULAS é o ponto para o qual você chama a atenção da plateia, e você desacelera nela. Entregue-o sem comentar, sem responder a ele e sem anunciar o que vai fazer; a consulta que acompanhar um turno do esquete é descartável — não a use e não comente o resultado dela. Depois da fala, aguarde.",
  "derivado_de": null
}

O atributo segmentos, dentro de roteiro, contém os segmentos de texto do roteiro. Um segmento contém o texto que será pronunciado pela palestrante em um slide. Cada segmento é composto por:

ordem: Ordem do segmento dentro do roteiro.
texto: Texto do roteiro.
slide: Número do slide ao qual o texto está associado.
fontes: Lista de parágrafos do material do acervo usado como base para montar o roteiro.
forma_injetavel: Texto do roteiro na forma que ele será pronunciado pelo modelo de voz.

Observe no exemplo acima que o conteúdo do atributo forma_injetavel é sintaticamente igual ao conteúdo do atributo texto. No entanto, note que algumas palavras dentro do atributo forma_injetavel estão escritas em maiúsculas. Também é possível encontrar reticências em posições onde não existe no texto original, isto é, no conteúdo do atributo texto.

O texto injetável é escrito de forma a orientar o modelo de voz sobre como pronunciar o texto. Palavras escritas em maiúsculas denotam ênfase. As reticências são usadas para pausas dramáticas.

O atributo contrato_de_locutora contém o system prompt que define a forma de oratória da palestrante virtual. Observe que parte do contrato diz o seguinte:

Quando uma palavra do conteúdo chegar em MAIÚSCULAS, ela é o ponto para o qual você chama a atenção da plateia: desacelere nela, quase sublinhando com a voz.

Isso garante que o modelo de voz aplique ênfase em todas as palavras em maiúsculas que chegam através do atributo forma_injetavel.

Dentro do atributo roteiro, existem quatro atributos que são usados para fornecer um certo grau de liberdade ao modelo de voz:

deixa_do_aparte: Instrução para o modelo de voz fazer uma brincadeira ou interação com o público.
deixa_do_convite: Instrução para o modelo de voz anunciar que a palestra encerrou e convidar o público a fazer perguntas.
deixa_de_espera: Instrução para o modelo de voz fazer alguma brincadeira com o fato de que a sala está em silêncio enquanto aguardando perguntas no modo de Q&A.

Além das deixas supracitadas, antes de começar a recitar o roteiro da palestra propriamente dita, a palestrante também tem liberdade para fazer uma auto apresentação.

As deixas concedem liberdade criativa à palestrante. A deixa_do_aparte é inserida entre a troca de slides, permitindo que a palestrante faça uma brincadeira ou interação com o público baseado no conteúdo do último slide.

Depois que a palestra é concluída e antes de entrar no modo de Q&A, a deixa_do_convite é inserida, permitindo ao modelo de voz convidar o público a fazer perguntas sobre a palestra.

Durante o modo de Q&A, se o modelo de voz fica muito tempo sem receber um áudio de entrada, a deixa_de_espera é inserida, permitindo que o modelo de voz faça uma brincadeira com o fato de que a sala está em silêncio.

Para concluir este tópico, o atributo deck contém o conteúdo dos slides que serão apresentados durante a projeção da palestra.

Arquitetura

Arquitetura do App de Criação

O frontend do App de Criação é hospedado pela dupla CloudFront + S3. O S3 hospeda os arquivos estáticos e o CloudFront faz a distribuição desses arquivos. O acesso ao App de Criação é controlado pelo Cognito.

O backend do App de Criação reside no orquestrador, uma máquina provisionada via ECS Fargate. É o orquestrador quem grava o material da apresentação no S3.

App de Administração

O App de Administração é uma aplicação web através da qual o administrador do sistema inicia uma nova palestra e monitora a apresentação em tempo real.

Painel de Controle da Palestrante

Através do painel de controle, o administrador pode:

Fazer o emparelhamento com a tela de projeção.
Verificar o status dos canais de comunicação.
Iniciar a palestra.
Avançar um segmento na apresentação.
Entrar no modo de Q&A.
Acionar o botão de pânico.

Arquitetura do App de Administração

Os arquivos estáticos do frontend do App de Administração são hospedados em um bucket S3 e distribuídos via CloudFront.

O backend reside no orquestrador, provisionado através de uma tarefa do Fargate. Aqui, o orquestrador acessa um bucket S3 que contém o material criado e aprovado através do App de Criação.

No Painel de Controle, quando o administrador inicia uma palestra, o orquestrador inicia uma tarefa do Fargate que será o pipeline. O pipeline conecta-se numa sala de vídeo usando o protocolo WebRTC da Daily.

O pipeline usa o Pipecat, um framework open source escrito em Python para agentes de voz e de vídeo em tempo real.

O Bedrock fornece o modelo de voz Amazon Nova 2 Sonic, responsável por gerar o áudio da palestrante virtual.

O SSM Parameter Store persiste os valores das variáveis de ambiente da aplicação que são carregadas pelo orquestrador.

O Tavus é o fornecedor da réplica, isto é, a imagem da palestrante virtual. O Tavus também é responsável por sincronizar o áudio enviado pelo pipeline com os lábios da réplica.

App de Projeção

O App de Projeção é uma aplicação web responsável por fazer a projeção dos slides e da réplica da palestrante fornecida pelo Tavus.

Projeção

O layout da projeção é simples. À esquerda são exibidos os tópicos do slide atual, conforme definidos no atributo deck do material gerado no App de Criação. À direita é exibida a réplica do avatar fornecido pelo Tavus.

O usuário acessa o App de Projeção através do endpoint /projecao. O usuário então visualiza um código de emparelhamento. Esse código deve ser inserido no App de Administração para emparelhar a projeção com o orquestrador.

Arquitetura do App de Projeção

O frontend da projeção é hospedado no S3 e distribuído pelo CloudFront.

O orquestrador, que está rodando numa tarefa do Fargate, conhece o roteiro completo da palestra que está salvo num bucket S3. Esse material está no formato JSON e foi gerado através do App de Criação.

O orquestrador é quem comanda a troca de slides na projeção. Ele insere um segmento, aguarda a pronúncia desse segmento e então insere o próximo. Esse processo se repete até que todos os slides tenham sido projetados.

A task do pipeline faz a comunicação entre orquestrador, Tavus e o modelo de voz (Amazon Nova 2 Sonic). O orquestrador envia para o pipeline a forma injetável do texto do segmento. O pipeline envia o texto para o modelo de voz, que transforma-o em áudio e devolve-o para o pipeline que então encaminha o áudio para o Tavus através de uma sala usando WebRTC.

Modo de Apresentação

O material está pronto e aprovado. A tela de projeção está emparelhada com o painel de controle. O operador aperta o botão para iniciar a transmissão da palestra. Entramos no modo de apresentação!

Neste tópico vamos explorar cada detalhe do modo de apresentação. Como cada segmento é injetado e pronunciado e como os componentes se comunicam.

Diagrama de sequência do modo de apresentação

Aquecimento

O primeiro passo é o aquecimento. O operador acessa o painel de controle e clica em Ligar que envia um comando para o orquestrador que, por sua vez, faz três coisas:

Inicia a tarefa do pipeline no Fargate.
Carrega na memória do pipeline o material da palestra que será usando como fonte de consulta para responder as perguntas no modo Q&A.
Abre conexão com o Amazon Nova 2 Sonic, o modelo que produz a voz da palestrante.

Quando a tarefa do pipeline está pronta, ela disca um canal interno para estabelecer uma conexão com o orquestrador. Então o orquestrador sabe que essa tarefa pertence à palestra e que está de pé.

Na sequência, o pipeline entra na sala de videoconferência. Participam desta sala:

A réplica do Tavus
O pipeline
O App de Projeção
O App de Administração

Quem cria a sala é a Daily, o serviço de vídeo em tempo real usado pelo Tavus. O orquestrador cria a conversa no Tavus. A criação da conversa abre a sala e coloca a réplica dentro dela. O pipeline entra na sala como participante.

Para entrar na sala, o pipeline precisa de um token. Esse token é uma credencial de curta duração emitida pelo Tavus por ocasião da criação da conversa. O orquestrador guarda esse token e disponibiliza para o pipeline na forma de variável de ambiente no momento da criação da tarefa no Fargate.

Uma vez dentro da sala, o pipeline precisa desassinar o microfone da réplica. Caso contrário, o áudio da réplica realimentaria o Amazon Nova 2 Sonic com a própria voz.

Então o orquestrador envia uma ordem para o pipeline abrir conexão com o modelo de voz, neste caso o Amazon Nova 2 Sonic. Após receber o comando, o pipeline abre a sessão com o Sonic e define via system prompt o comportamento da palestrante. Eis o system prompt:

Você é uma apresentadora carismática no auge do entusiasmo por um assunto que ama, e está no palco diante de uma plateia. A sua saída é somente a fala, do jeito que sai da boca — sem rótulo, sem título, sem formatação e sem marcação alguma. Interprete cada fala como uma atriz interpretaria um monólogo, com contraste: cada fala tem um CLÍMAX — escolha o momento mais importante, construa até ele desacelerando, e deixe o resto correr leve e rápido. Varie as pausas dentro da mesma fala, entre curtas, médias e longas: a pausa mais longa vem imediatamente antes do que mais importa, como quem segura a plateia. Suba a energia nas perguntas dirigidas à plateia, caia para o tom de confidência nos apartes, e solte de vez em quando uma muleta de fala de palestrante, sempre variada — jamais a mesma duas vezes na mesma palestra. Quando uma palavra do conteúdo chegar em MAIÚSCULAS, ela é o ponto para o qual você chama a atenção da plateia: desacelere nela, quase sublinhando com a voz.

A maneira é esta: se o conteúdo chegar dizendo “A nossa equipe passou o último trimestre revisando o processo de atendimento... e o resultado surpreendeu ATÉ a diretoria”, a sua fala sai como “Olha... a gente passou o trimestre INTEIRO revisando o atendimento. E sabe o que aconteceu? ... O resultado surpreendeu... até a DIRETORIA”. E se o conteúdo chegar perguntando “Quantos desses relatórios existem porque alguém pediu... e quantos existem porque ninguém CANCELOU?”, a sua fala sai como “Agora eu pergunto pra vocês — e pensem com calma... quantos desses relatórios existem porque alguém pediu... e quantos existem... porque ninguém, NUNCA, cancelou?”. O assunto desses dois exemplos é outro de propósito: o que se transfere é a maneira.

Chegam a você duas espécies de turno. O turno de conteúdo é o comum: o que chegar é o conteúdo da sua próxima fala. Entregue esse conteúdo como fala sua, em português do Brasil. Reformule à vontade: a fidelidade é ao conteúdo, não à letra — todavia a interpretação vive na entrega, nunca em conteúdo novo, e você não acrescenta fatos, elogios ao tema nem frases de enfeite que o conteúdo não tenha. Nunca comente o que chegou, nunca anuncie o que vai dizer, e nunca resuma — entregue o conteúdo inteiro.

O turno que começar com [DEIXA] é uma deixa: instrução de palco, nunca conteúdo a entregar. Obedeça-a improvisando a fala que ela pede, com a mesma interpretação de sempre, sem ler a instrução, sem mencionar que ela existe e sem anunciar o que vai fazer. Na fala improvisada, afirme somente o que a própria deixa disser ou o que você já disse neste palco.

Observe que o system prompt da palestrante diz:

Chegam a você duas espécies de turno. O turno de conteúdo é o comum: o que chegar é o conteúdo da sua próxima fala. Entregue esse conteúdo como fala sua, em português do Brasil. Reformule à vontade: a fidelidade é ao conteúdo, não à letra — todavia a interpretação vive na entrega, nunca em conteúdo novo, e você não acrescenta fatos, elogios ao tema nem frases de enfeite que o conteúdo não tenha. Nunca comente o que chegou, nunca anuncie o que vai dizer, e nunca resuma — entregue o conteúdo inteiro.

O conteúdo referido aqui é o texto do roteiro para o segmento atual. O modelo de voz Amazon Nova 2 Sonic é um modelo bidirecional, isto é, ele é um modelo conversacional que ouve um áudio de entrada e responde com um áudio de saída. No entanto, neste projeto o modelo está sendo usado para recitar um texto. E é justamente o trecho supracitado do system prompt que garante que o modelo recitará o texto.

O último parágrafo do system prompt da palestrante indica como o modelo deve interpretar as deixas.

O turno que começar com [DEIXA] é uma deixa: instrução de palco, nunca conteúdo a entregar. Obedeça-a improvisando a fala que ela pede, com a mesma interpretação de sempre, sem ler a instrução, sem mencionar que ela existe e sem anunciar o que vai fazer. Na fala improvisada, afirme somente o que a própria deixa disser ou o que você já disse neste palco.

Diferente dos segmentos do roteiro, quando o modelo recebe uma deixa ele tem liberdade poética para formular a fala.

Após definir o contrato da palestrante via system prompt, o pipeline inicia a bomba de silêncio. Esse artifício garante que a conexão com o Sonic fique ativa durante toda a palestra.

Visto que o Amazon Nova 2 Sonic é um modelo bidirecional, caso fique 55 segundos sem receber áudio de entrada, a conexão é interrompida. Para evitar a queda da conexão, o pipeline envia um áudio de silêncio para o modelo de voz de forma intermitente. Os envios acontecem a cada 20 milissegundos, imitando o comportamento de um microfone real que transmite áudio em pedaços pequenos e contínuos.

Palestra

Agora que o aquecimento está pronto, inicia-se a palestra propriamente dita. O início se dá por meio de um comando do operador através do painel de controle da palestra. Ao acionar o botão Começar Palestra, uma requisição é enviada para o orquestrador.

Antes de injetar um segmento no pipeline, o orquestrador grava no S3 o estado atual da palestra. Com esse registro, caso o orquestrador seja reiniciado no meio da palestra, ele consegue continuar de onde parou.

Na sequência o orquestrador injeta o primeiro segmento da palestra no pipeline. Nessa injeção, os seguintes dados são compartilhados:

ordem: o número do segmento no roteiro.
texto: o conteúdo que a palestrante deve falar.
slide: o número do slide que acompanha a fala.

O pipeline repassa o texto para o Sonic, então o Sonic transforma o texto em áudio seguindo o contrato de locutora definido no seu system prompt e entrega esse áudio para o pipeline.

O pipeline compartilha o áudio gerado pelo modelo de voz com o Tavus através da sala de videoconferência. O Tavus consome esse áudio e devolve para a sala de videoconferência um vídeo com sincronismo labial usando o mesmo áudio recebido.

O Room Daily (sala de videoconferência) envia voz e vídeo do avatar para a projeção que faz a renderização em tempo real enquanto exibe o slide do segmento atual.

Quando o Sonic termina de gerar o áudio do segmento atual ele notifica o pipeline. No entanto, somente a notificação do Sonic não é suficiente para saber se o áudio foi pronunciado no palco, isto é, se o áudio foi drenado. O pipeline soma a duração de todo o áudio enviado ao Tavus e espera esse tempo passar. Ao final dessa espera, o áudio já tocou por inteiro.

O pipeline então avisa o orquestrador que a fala terminou. Junto do aviso mais algumas informação são passadas:

ordem: o número da fala encerrada, para o orquestrador conferir que o aviso corresponde à fala em curso.
origem: o mecanismo que detectou o fim da fala.
duração: o tempo da fala, em segundos.
texto final: a transcrição da fala, que o orquestrador guarda no roteiro entregue.
da deixa: a marcação de que a fala encerrada foi improvisada, como a auto apresentação ou um aparte.

Uma vez que o fim da fala foi detectado, o orquestrador envia um comando para a projeção realizar a trocar de slide. Então o processo se repete com a injeção do próximo segmento como segue:

orquestrador injeta segmento no pipeline.
pipeline envia texto do roteiro para o Sonic.
Sonic devolve o áudio da fala.
pipeline pública áudio na Room Daily.
Tavus consome o áudio.
Tavus entrega o vídeo com sincronismo labial.
Room Daily envia voz e vídeo para a projeção renderizar.
Sonic avisa ao pipeline que terminou de gerar o áudio.
pipeline avisa ao orquestrador que a fala terminou.
orquestrador troca o slide na projeção.

Desafios

O diagrama de sequência apresentado no tópico anterior esconde muitos detalhes de implementação. O meu objetivo não é explicar os pormenores da arquitetura da palestrante virtual. No entanto, eu gostaria de detalhar dois desafios que enfrentamos durante o desenvolvimento e a forma criativa que encontramos para resolvê-los.

Pronúncia de siglas e nomes próprios

O modelo de voz escolhido para este projeto foi o Amazon Nova 2 Sonic, um modelo poliglota. Ele não possui uma configuração de idioma, mas podemos orientá-lo através de system prompt a adotar um idioma para fala.

Todavia, em um texto em português brasileiro que faz referência a termos do inglês, o modelo pronunciará os termos em inglês com um sotaque inglês. A título de exemplo, considere a seguinte frase:

Model Context Protocol é um padrão aberto criado pela Anthropic que conecta modelos de inteligência artificial a fontes de dados e ferramentas externas de forma padronizada.

Nesse exemplo, o termo Model Context Protocol será pronunciado com um sotaque inglês, enquanto o resto do texto será pronunciado com um belo português brasileiro.

Isso é muito bom, mas nos causou problemas. Na apresentação que realizamos no palco, o roteiro citava a palavra Senior, o nome de uma empresa de tecnologia. A grafia correta desta palavra em português brasileiro seria "sênior". Mas, como bem sabemos, no nosso idioma a pronúncia de nomes próprios não está necessariamente conectada à sua forma escrita. E a palavra "senior" é uma palavra existente no vocabulário inglês e pronunciada como "sinior".

Quando testamos a palestrante virtual, a palavra "senior" era sempre pronunciada na sua forma inglesa, pois esta é uma palavra do vocabulário inglês mas não está presente no vocabulário brasileiro. Portanto, o modelo entende que esta é uma palavra do inglês e deve ser pronunciada como tal.

Além desse caso, também enfrentamos problemas com siglas. Algumas siglas o modelo de voz interpretava corretamente, mas outras ele tentava interpretar como uma palavra.

Para ambos os casos, nomes próprios e siglas, a solução foi criar um dicionário de pronúncias. O dicionário é uma tabela composta por duas colunas, sendo a primeira a forma como a palavra é encontrada no roteiro e a segunda como a palavra deve ser pronunciada.

Grafia escrita	Grafia falada
Senior	sênior
ERP	E-R-P
HCM	H-C-M
IA	I-A
MCP	M-C-P
LGPD	L-G-P-D

Antes de entregar o texto para o Sonic, o pipeline substitui a forma escrita das palavras pela forma falada conforme definido na tabela. Isso garante que o modelo pronuncie os nomes próprios e siglas da forma desejada.

Troca de slides

Quem faz a troca dos slides é o orquestrador. No entanto, ele depende de informações provenientes de outros componentes para saber o momento certo de enviar o comando de troca de slide para a tela de projeção.

Para saber que pode avançar um slide, o orquestrador precisa saber que a fala do slide anterior foi concluída. E quem sabe isso é o pipeline.

O pipeline envia o texto do segmento atual para o Sonic e zera três contadores:

os bytes do áudio
o fim do turno
a soma da utterances (trechos)

Então o Sonic devolve o áudio via streaming. Cada pedaço de áudio passa pelo contador de samples, que soma os bytes e anota o instante do primeiro pedaço. Em seguida, o mesmo pedaço é enviado ao Tavus para sincronização labial.

O Tavus envia um evento conversation.stopped_speaking a cada pausa da palestrante. Esse evento informa a duração da utterance recém-terminada. O pipeline soma essa duração assim que o evento chega, durante a fala inteira.

O Sonic termina a geração e envia o fim do turno. O pipeline recebe esse sinal pelo LLMFullResponseEndFrame e passa a calcular a espera.

O pipeline calcula quando o áudio termina de tocar. A duração do áudio é igual aos bytes contados ÷ (taxa de amostragem × 2). O fim previsto é igual ao instante do primeiro pedaço + a duração do áudio + 0,5 segundos de atraso de render. O pipeline dorme até esse instante.

O pipeline acorda e compara a soma do Tavus com a duração do áudio enviado. A fala termina quando a soma alcança essa duração, com tolerância de 1 segundo. Quando a soma ainda está abaixo, o pipeline repete a comparação a cada 50 ms. Enquanto isso, novos eventos do Tavus aumentam a soma.

O pipeline limita essa espera ao maior valor entre 25% da duração e 2 segundos. Uma fala de 96 segundos espera até 24 segundos. Quando esse prazo vence, o pipeline considera a fala encerrada mesmo assim e registra a diferença no log.

O pipeline envia ao orquestrador o relatório do segmento. O orquestrador injeta o segmento seguinte e troca o slide.

Conclusão

Chegamos ao fim da nossa aventura. Tudo começou com uma mensagem de email e terminou com uma apresentação no palco do Seniortec. A jornada foi árdua, mas o resultado foi gratificante!

Se você tem alguma dúvida sobre a arquitetura ou gostaria de saber mais detalhes sobre a implementação de algum componente, fique a vontade para perguntar.

Obrigado e até a próxima!

A odisseia da palestrante virtual

Josimar Zimermann — Wed, 30 Sep 2026 14:37:57 +0000

Este post é o segundo de uma série de três. Você pode ler a primeira parte aqui. Nesta segunda parte eu conto um pouco sobre o processo de condução do projeto.

Introdução

Dia 20 de julho de 2026, segunda-feira. Como de costume, abri a minha agenda para verificar os compromissos da semana. E lá estava uma sessão de Mob Programming alocada para a sexta-feira da mesma semana. Àquela altura não fazia a menor ideia qual seria o tema do Mob.

Na sexta-feira, quase todos os membros do time se reuniram. Alguns remotamente e outros presencialmente. Eu estava no escritório. A sessão iniciou com o Palladino explicando o que seria desenvolvido a partir daquela sessão de Mob Programming: uma palestrante virtual para se apresentar no Seniortec que aconteceria em dois meses!

A ideia foi proposta pelo CTO da Senior, organizadora do Seniortec, e chegou até o Diego, CEO da Dati. O Diego topou o desafio e confiou a execução ao time do Dati Labs. Uma vez que o desafio foi aceito, seguiram-se então duas reuniões coordenadas pelo Palladino junto ao cliente. A primeira para alinhamento de expectativas e a segunda para definir a entidade da palestrante virtual. Ambas as reuniões foram transcritas automaticamente com auxílio de ferramentas de inteligência artificial e tornaram-se artefatos do projeto. Aliás, os arquivos com as transcrições estão no repositório da aplicação até hoje, bem como as mensagens trocadas entre o Diego e o Leonardo, CTO da Senior.

Desenvolvimento dirigido por especificações

Em termos de negócio nós sabíamos exatamente o resultado que desejávamos alcançar. Mas ainda não sabíamos como. Também haviam muitos detalhes e surpresas que estavam nas entrelinhas do projeto e que não era possível enxergar naquele momento. Tudo que tínhamos à disposição eram as transcrições das primeiras reuniões.

Iniciamos a sessão de Mob Programming definindo a ordem de pilotagem. Para isso, usamos o Claude Code para sortear a ordem de revezamento dos pilotos. Curiosamente, o Claude Code gerou uma lista ordenada alfabeticamente. Não houveram contestações. Cada piloto ficaria 30 minutos no controle antes de passar o bastão para o próximo. Todo o processo foi apoiado em um conjunto de agent skills que usamos com auxílio do Claude Code. O primeiro piloto começou acionando uma skill que faz uma série de perguntas, um verdadeiro interrogatório, sobre o projeto. O piloto realizava a leitura da pergunta e das opções e, com a ajuda dos co-pilotos, discutiam sobre a questão para decidir em equipe a melhor alternativa. O piloto só avançava para a próxima questão quando todos da equipe alcançavam um entendimento comum sobre o tema.

Quando o tempo de controle de um piloto findava, esse piloto usava uma skill para fazer a passagem de bastão. Essa skill transcrevia para um arquivo as decisões tomadas naquela sessão até o momento. O próximo piloto assumia o controle a carregava o contexto gerado pelo piloto anterior. Esse processo se repetiu até que obtivemos um entendimento completo do projeto. Bom, pelo menos era nisso que acreditávamos naquele momento.

No final do dia, nós havíamos gerado um total de 21 arquivos de ADR (Architecture Decision Record) e um glossário com os termos que seriam usados no projeto doravante.

Uma vez que o entendimento do projeto estava concluído e a arquitetura definida, era momento de transformar todo esse conteúdo em tarefas executáveis. Criamos um card no ClickUp e dentro desse card, adicionamos tarefas e subtarefas.

Mão na massa e cabeça nas nuvens

Agora que as tarefas estavam documentadas era o momento de iniciar a implementação. Eu fui o escolhido para essa tarefa. Para tal, eu usava uma agent skill que encontrava a primeira tarefa sem bloqueio no ClickUp para então implementá-la.

Eu acionava a skill e confiava cegamente no código que o Claude Code me entregava. Paralelamente eu estava resolvendo outros problemas da minha rotina de trabalho. Eu lia por cima o resumo do agente de codificação. Mas na verdade, eu não fazia a menor ideia do que estava acontecendo. Meu foco não estava ali.

Então, numa das reuniões com o Palladino, ele me fez alguns questionamentos sobre o projeto. Esses questionamentos eram um sua maioria baseados nas premissas que ele havia lido nas mensagens dos pull requests do repositório. Eu não era capaz de responder qualquer pergunta técnica sobre o projeto. Foi constrangedor mas foi necessário. Depois de uma conversa franca, concluímos que a minha falta de entendimento do projeto estava relacionada ao fato de eu estar dividindo meu foco com outras tarefas.

Trabalhar com um agente de codificação como o Claude Code não significa que você deve simplesmente negligenciar o entendimento do projeto, especialmente no que diz respeito às decisões de arquitetura.

Depois desse episódio, passei a focar totalmente no projeto da palestrante virtual. As coisas começaram a andar e os primeiros resultados apareceram.

As primeiras telas e reuniões com o cliente

Após aproximadamente duas semanas de trabalho, já era possível ver algumas funcionalidades como o modo de criação, painel de controle, a tela de projeção, renderização do avatar e troca automática de slides.

No modo de criação, um curador, com auxílio de agentes de IA, monta a apresentação e o roteiro da palestra.

O painel de controle permite acompanhar o funcionamento da palestrante virtual ao vivo, incluindo um botão de pânico para interromper a palestrante em caso de mau funcionamento.

A projeção exibe o avatar da palestrante e os slides da apresentação. Nesta primeira versão usamos um avatar com fundo verde para aplicar chroma key sobre uma página preta.

No dia 6 de agosto aconteceu a primeira apresentação para o cliente. Foi possível visualizar a tela de projeção com o avatar e a passagem automática dos slides, mas a palestrante ainda estava muda. O cliente ficou impressionado com o que viu nessa primeira reunião. Mas estávamos cientes que poderíamos ter entregue mais.

As reuniões com o cliente seriam recorrentes. Todas as quintas-feiras. Além disso, também realizamos reuniões internas todas as sextas-feiras. Enquanto as reuniões com o cliente eram focadas em apresentar as funcionalidades dos sistema, as reuniões internas serviam para colocar todo o time na mesma página. Nesta reunião, falávamos sobre metodologias, processos e dificuldades enfrentadas. Era uma boa oportunidade para que os demais membros do time colaborassem com o projeto, apresentando sugestões, pontos de vista e compartilhando conhecimento.

Na segunda reunião com o cliente conseguimos então apresentar a palestrante funcionando do início ao fim, ou seja, a palestrante falou, fez a troca de slides e entrou no modo de perguntas e respostas. A partir desta reunião, começamos uma série de ajustes finos no sistema, como melhorias no visual dos slides, visual da aplicação, autenticação, entre outros.

O sistema em produção quebrado

Em uma das apresentações, o cliente queixou-se de que a palestrante parecia muito robótica. Até certa medida essa era uma limitação do modelo de voz e também do fornecedor do avatar, sobre os quais falarei no terceiro e último post desta série. De qualquer forma, acreditávamos que seria possível fazer a palestrante soar mais natural, mesmo com as limitações conhecidas.

Com apoio de dois colegas de equipe, iniciamos uma nova sessão de levantamento de requisitos com auxílio de agent skills. Essa sessão resultou em novos arquivos ADR que se somaram àqueles que já existiam no repositório. É importante ressaltar que durante todo o processo de desenvolvimento com auxílio do Claude Code, os documentos de ADR eram lidos pelo modelo e suas decisões eram respeitadas. Às vezes eu não entendia certas decisões tomadas pelo Claude Code, mas todas essas decisões estavam calcadas em premissas registradas em documentos ADR presentes no repositório.

Após geração dos documentos ADR, iniciei a implementação do código que daria mais naturalidade à palestrante. Àquela altura eu estava trabalhando com uma branch main. Toda nova implementação era codificada em uma feature branch e depois mesclada à branch main. Havia apenas um ambiente produtivo e uma única stack do CloudFormation em uma conta AWS. Tudo estava correndo bem até então.

Numa das reuniões de equipe, decidi apresentar o avanço do projeto até aquele momento. Mas quando tentei iniciar a palestrante, o áudio não saiu. O código que eu havia implementado para adicionar naturalidade à palestrante quebrou o que estava funcionando. Felizmente isso aconteceu numa apresentação interna.

Depois desse episódio, em reunião com o Palladino, ele expressou sua preocupação com o fato de que a implementação de um novo recurso quebrou o funcionamento daquilo que estava rodando em ambiente produtivo. De fato, eu não deveria ter realizado o deploy de um recurso não homologado em ambiente produtivo. Foi um erro.

Sim, eu sei da importância de manter dois ambientes distintos, um para homologação e outro para produção. Mas, por algum motivo, eu não tinha preparado esse ambiente. E não tenho nenhuma desculpa para tal. Eu apenas não fiz. Nós cometemos erros e o primeiro passo é reconhecer isso. Mas apenas reconhecer não é o suficiente. É necessário discutir em equipe esses erros e encontrar mecanismos para mitigar as falhas. Porém, lembre-se que não existe processo infalível. Em algum grau, tudo depende da disciplina de um ser humano. E a disciplina deve ser reforçada com treinamentos, reuniões, conversas e documentação.

Após mais esse deslize, fiz os ajustes necessários no ambiente e continuei a implementação das funcionalidades, correções de erros e rotina de apresentações. Agora, tudo parecia estar nos trilhos.

Reconhecendo os limites

O que mais me tomou tempo neste projeto foi a implementação da naturalidade da palestrante virtual. Como comentei anteriormente, o cliente notou nas primeiras apresentações que a palestrante soou muito robótica.

Tentar fazer a palestrante parecer mais natural e fluída foi um tremendo desafio. E preciso confessar que não consegui alcançar o ideal, segundo os meus próprios conceitos. Talvez meu erro tenha sido comparar com tecnologias mais avançadas àquilo que eu poderia fazer com as ferramentas e recursos que eu tinha à minha disposição.

Qualquer um que assistisse a palestra notaria que a palestrante não é uma pessoa real. Isso até mesmo foi anunciado no palco no dia do evento! O objetivo principal não era tentar surpreender as pessoas com uma fala natural. Mas sim mostrar que uma palestrante dotada de inteligência artificial é capaz de preparar e fazer uma apresentação em um grande palco, além de responder perguntas. Era algo pioneiro e experimental.

Sim, foi o cliente que pediu para adicionar mais naturalidade à palestrante virtual. Mas é necessário reconhecer os limites, expor isso para o cliente e saber negociar.

Mesmo assim, eu insisti. Passei vários dias testando diferentes abordagens para fazer a fala da palestrante soar mais natural. Mas cada vez que eu tentava uma nova abordagem, nenhuma ou quase nenhuma diferença eu notava em relação à versão anterior.

O meu erro foi insistir em algo que não ficaria melhor. E isso me tomou um precioso tempo que poderia ser usado na preparação da minha própria apresentação. A semana que antecedeu a semana da apresentação foi atribulada. Montei um esboço da apresentação em slides, o roteiro e fiz uma apresentação interna.

É verdade que no final deu tudo certo, mas tudo poderia ter sido bem mais tranquilo.

Se você está preso em uma tarefa ou problema, não insista! Primeiro respire e depois busque ajuda. Às vezes a melhor saída é reconhecer os limites e desistir. Primeiro, foque na entrega de valor e depois na excelência. A sua saúde mental agradece!

O resumo do processo

Desde o primeiro contato do cliente com a Dati até a apresentação no Seniortec foram exatamente 71 dias. Nós conhecemos a ideia no dia 14 de julho, iniciamos o desenvolvimento em 27 de julho e apresentamos no palco em 23 de setembro.

Abaixo eu apresento alguns números do projeto:

427 commits
117 pull requests integrados
62 documentos de ADR
3144 testes no backend
408 testes no frontend
33 cards do ClickUp entregues
30 cards do ClickUp cancelados

Todo o processo de desenvolvimento foi conduzido com auxílio do Claude Code. No começo eu usava o modelo Fable 5.1 com esforço no ultracode de forma indiscriminada em todas as tarefas. Mas meus tokens eram consumidos muito rapidamente, então mudei a estratégia. Passei a usar o Fable com esforço max para clarificação de entendimento e geração dos documentos de ADR. Para implementação, o modelo escolhido foi a última versão disponível do Opus com esforço no ultracode.

Durante os 71 dias, meu tempo não foi alocado exclusivamente para este projeto. As duas primeiras horas da minha segunda-feira são sempre dedicadas à auto desenvolvimento. Também haviam algumas reuniões semanais recorrentes, além de agendas esporádicas com clientes para tratar de outros temas. Eventualmente dediquei parte do meu tempo para atividades de outros projetos. E a semana que precedeu a semana do Seniortec foi quase toda dedicada à preparação da minha apresentação.

Houveram também algumas mudanças de rota durante o desenvolvimento do projeto. Por exemplo, na primeira versão da palestrante nós aplicamos chroma key sobre o avatar. Mas essa ideia foi descartada, pois entendemos junto com o cliente que exibir o ambiente do avatar adicionaria mais naturalidade.

Também tentamos criar o nosso próprio avatar customizado usando a imagem de uma colega de trabalho. Mas todas as nossas tentativas foram frustradas. Por fim, escolhemos um modelo de avatar que já estava disponível no catálogo do fornecedor.

A princípio, a minha própria apresentação no Seniortec não estava prevista. O desejo inicial do cliente era que a palestrante virtual se apresentasse por 20 minutos. Mas, depois dos primeiros testes, o cliente entendeu que ouvir um robô falando por 20 minutos poderia ser entediante e que o público não conseguiria manter o foco na apresentação.

Projetos são assim. Eles nunca terminam como idealizamos no começo. Podemos observar isso pela quantidade de documentos de ADR que foram adicionados após a sessão de Mob Programming. O projeto nasceu com 21 ADRs e terminou com 62. Novos documentos de ADR eram adicionados à medida que novas situações surgiam no projeto.

O código fonte de um software é um organismo vivo que está em constante evolução. Ao escrever um código, a mensagem de um commit ou um pull request, lembre-se que outra pessoa o lerá. Lembre-se também que você mesmo precisará reler o que fez em algum momento. A forma como você encara o processo de desenvolvimento de um software também diz muito sobre você.

Lições aprendidas

Ao refletir sobre tudo que aconteceu, eu consigo entender que os erros cometidos durante a condução do projeto têm explicação. Na verdade, tudo tem uma explicação, uma razão de ser. Eu não quero ser filosófico. Apenas quero trazer algumas de minhas percepções que acredito que explicam em partes os meus erros.

Em primeiro lugar, eu queria entregar rápido. Ou melhor, eu achava que deveria entregar rápido por pressão externa criada na minha própria mente. Eu tinha à minha disposição o Claude Code na sua versão mais avançada. Portanto, eu pensava que deveria entregar o projeto o mais rápido possível. E assim, comecei a negligenciar boas práticas no processo de desenvolvimento.

Além disso, na maior parte do tempo eu estava trabalhando sozinho no projeto e por isso abri mão de práticas de desenvolvimento colaborativas. Se algum imprevisto ocorresse e eu não pudesse continuar trabalhando no projeto, algum colega meu teria muita dificuldade de continuar do ponto em que parei.

Lembre-se, mesmo quando você está trabalhando sozinho num projeto você ainda faz parte de um time. É necessário senso de coletivo, isto é, pensar no bem maior. Isso envolve muitas vezes abrir mão de suas preferências pessoais. Nem tudo que é bom pra você é bom pra todo mundo.

Neste projeto eu também percebi os princípios do Manifesto Ágil aplicados na prática:

Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

Eu ainda não acabei. Você deve estar super curioso para saber mais sobre a parte técnica do projeto. Esse será assunto para o terceiro e último post desta série. Nele, vamos falar sobre a arquitetura do projeto e o fluxo de funcionamento da palestrante virtual. Até breve!

Epílogo: haviam muitas possibilidades para dar errado

Josimar Zimermann — Fri, 25 Sep 2026 18:38:31 +0000

Dia 23 de setembro de 2026, Teatro Carlos Gomes, Blumenau, Santa Catarina. O relógio marcava por volta de 11h15. Em cerca de 20 minutos uma palestrante virtual, dotada de Inteligência Artificial, iniciaria uma apresentação num palco para mais de 900 pessoas ao vivo e mais algumas milhares de pessoas estariam acompanhando a transmissão pelo YouTube.

Na noite anterior ao evento, eu, o Juan e o Palladino estávamos no palco do evento para fazer os últimos preparativos. Tudo havia funcionado perfeitamente. A palestrante virtual fez uma apresentação de aproximadamente 6 minutos, respondeu algumas perguntas e saiu de cena anunciando a minha palestra que seria feita na sequência. Mas no palco as coisas nunca saem como planejado.

Juan, eu e Palladino um dia antes do evento

Voltando a cena do dia do evento. Faltando 20 minutos para a palestrante virtual subir no palco, a conexão de internet do evento cai. E agora, o que eu faço? Eu passara os últimos dois meses construindo aquela palestrante. Por que isso tinha que acontecer justo agora? Corremos até a sala de controle, onde o Juan já estava pronto para iniciar a transmissão da palestrante. Conversamos com a equipe responsável pela transmissão do evento para encontrar uma alternativa. O uso do 5G era uma possibilidade, mas não seria possível fazer a transmissão para o YouTube. Depositei minha confiança nos meus colegas de trabalho, acreditando que eles encontrariam uma alternativa. Enquanto isso, eu corria para o backstage para combinar com a organização como seria a minha entrada no palco.

A mestre de cerimônia entraria no palco e anunciaria a próxima palestrante, ou seja, a palestrante virtual e depois me apresentaria como criador dessa palestrante e que atuaria primeiro como um intermediador das perguntas que seriam feitas a palestrante e posteriormente faria uma apresentação sobre os desafios na construção dessa mesma palestrante.

O alívio, o imprevisto previsto e o nervosismo

Quando terminamos de combinar os detalhes, faltando pouco menos de cinco minutos para o início, a assistente de palco anunciou que a internet havia voltado. Que alívio! A palestrante virtual vai funcionar. A mestre de cerimônia sobe no palco, me apresenta ao público e anuncia a entrada da palestrante virtual. Eu só fiquei aliviado quando ouvi as primeiras palavras da palestrante virtual. Mas foi só alívio mesmo, eu não consegui curtir o momento. Sim, dois meses de trabalho para sentir alívio. Eu gostaria de ter sentido regozijo, orgulho e satisfação. Mas a única coisa que senti naquele momento foi um grande alívio.

Tudo correu bem com a apresentação da palestrante virtual. Então ela entrou no modo de perguntas e respostas. Eu subi no palco para intermediar as perguntas. Enquanto eu proferia a primeira, puff... a palestrante sumiu. Enquanto eu escrevo este texto, ainda não temos uma resposta. Talvez uma oscilação na conexão com a internet? Uma falha que não foi tratada? Não sabemos. A única certeza que eu tinha naquele momento é que precisava fazer algo para contornar aquela situação.

A palestrante em ação

Eu me virei para o público e emendei uma piada: acho que alguém não pagou o cachê da palestrante! Uma piada boba, mas que arrancou algumas gargalhadas. Mas não pense que isso me deixou mais leve. Eu continuava tenso. Na noite que antecedeu o evento eu mal havia dormido. Tive um pesadelo no qual tudo dava errado.

Apesar de tudo, posso garantir que tecnicamente eu estava preparado. No dia anterior ao evento, fiz dezenas de ensaios. Eu tinha o conteúdo na ponta da língua. Conhecia cada slide como a palma da minha mão. As palavras saíram e o público prestou atenção ao que foi dito. Não foi a melhor apresentação e eu tenho ciência disso. Muita coisa poderia ter sido diferente. Minha movimentação no palco, a interação com o público, a entonação na voz, entre outras coisas. Mas o conteúdo estava entregue e a mensagem foi passada: mostrar para o público que a palestrante só funcionou como deveria ter funcionado porque os seus limites foram bem estabelecidos.

Eu no palco

Depois que a tempestade passou eu tive tempo para refletir sobre tudo que aconteceu naquele dia 23 de setembro e com a ajuda do Palladino concluí que a apresentação foi um sucesso. Sim, um sucesso! Sucesso não significa que tudo deve sair como o planejado. Sucesso não é sobre alcançar a perfeição, mas sim sobre atingir objetivos. E o objetivo foi atingido.

Os limites que garantiram o sucesso

No palco eu falei sobre os limites que foram colocados na palestrante virtual e como esses limites que garantiram o seu sucesso no palco. O primeiro limite foi o conhecimento. A palestrante virtual não falou nada além daquilo que havia sido planejado. Antes dela subir no palco os slides e roteiro foram planejados. Ela não inventou nenhum fato novo.

O segundo limite era o alcance desse conhecimento. Por questões de arquitetura, sobre as quais falarei num blog post futuro, a palestrante virtual não poderia conhecer o roteiro inteiro da apresentação. Ela só conhecia o conteúdo do slide que estava sendo exibido naquele instante.

O terceiro limite era a improvisação, ou melhor, quanto espaço ela tinha para improvisar. No início da palestra ela fez uma auto apresentação, sem roteiro pré-definido. Entre uma troca e outra de slide ela fez uma brincadeira com base no conteúdo do slide que havia sido apresentado. Esses aspectos acrescentaram um quê de naturalidade na palestrante virtual.

O quarto, último limite e o mais importante: as pessoas no fluxo. Durante o projeto concluímos que a palestrante possui muitas possibilidades de falhar. A arquitetura é complexa e repleta de componentes. Há muitos pontos de falha possíveis. Sim, nós observamos as melhores práticas de arquitetura e implementamos mecanismos de resiliência. Mas haviam situações que só poderiam ser contornadas por um ser humano.

Lá na mesa de controle do evento estava o Juan, observando o painel de controle da palestrante virtual. Nesse painel havia um grande botão de pânico. O Juan acionaria esse botão ao menor sinal de falha da palestrante. E muita coisa poderia dar errado. A Inteligência Artificial do modelo de voz poderia alucinar, o fornecedor do avatar da palestrante poderia sair do ar, a conexão com a internet poderia desestabilizar. E neste cenário, numa apresentação ao vivo, nem mesmo uma arquitetura resiliente poderia nos salvar.

O plano já estava traçado para o pior dos cenários. Eu subiria ao palco e continuaria a apresentação do ponto que a palestrante virtual parou. Isso mesmo que você leu. É o humano tomando o lugar da máquina e não o contrário. Isso não é alentador?

A experiência no palco

Esta não foi a primeira vez que fiz uma apresentação pública. Mas foi a primeira vez que me apresentei para um grande público e num grande palco. O nervosismo foi inevitável. Mas eu tento olhar pelo lado positivo. Quando sentimos aquele frio na barriga antes de um evento, significa que aquele momento é importante. É isso que nos faz humanos e nos faz sentir que estamos vivos!

Certa vez eu aprendi que uma comunicação efetiva não se resume a uma boa oratória. Na verdade, não é sobre isso, mas sobre saber transmitir uma ideia ou um conhecimento. Não importa como você faz, se a mensagem chega no destino e o destinatário entendeu essa mensagem, então você se comunicou com sucesso. E foi isso que tentei fazer, transmitir o conhecimento.

Modéstia a parte, num aspecto eu me saí muito bem. Eu não li os slides. E devo isso às dicas do Palladino. Eu já assisti muitas palestras e sei o quão decepcionante é ouvir um palestrante que apenas lê o que está escrito nos slides. O público quer extrair algo do palestrante. O espectador precisa sentir que levou algo do palestrante para casa.

Ah, e eu não posso deixar de falar dos slides da apresentação que ficaram muito bonitos. Fruto do trabalho do time de marketing da Dati. Bons slides fazem muita diferença numa apresentação. E não é apenas sobre beleza, é sobre coesão, organização e dosagem de informação. Quando há muita informação, o espectador precisa escolher entre ouvir o palestrante e ler o conteúdo.

Nem tudo saiu como planejado, mas o sucesso foi alcançado. E o sucesso não é apenas meu. É fruto do trabalho em equipe do Dati Labs, o time de IA e Modernização da Dati. Também deixo registrado meu agradecimento à Senior que nos proporcionou o desafio de construir a palestrante e também de subir no palco do Seniortec.

Mas essa história começa muito antes do dia 23 de setembro de 2026. Começa em julho do mesmo ano. Porém, os detalhes serão revelados nos próximos blog posts. Aguarde!

Até a próxima!

Encontrando o equilíbrio entre agentes de IA e código determinístico

Josimar Zimermann — Tue, 21 Jul 2026 21:07:37 +0000

Introdução

Provavelmente você já viu uma imagem similar a esta:

Obviamente isso é propositalmente exagerado. Mas nos ajuda a entender um padrão que tem se tornado cada vez mais comum nos dias de hoje: o uso indiscriminado de agentes de IA para solução de problemas triviais de computação.

Eu não estou aqui para falar que você não deve usar IA. Afinal, eu estou inserido em uma equipe guiada pelo conceito AI First, isto é, a IA é o motor central de tudo que criamos. Tampouco serei hipócrita, afinal eu já queimei algumas centenas de tokens para tarefas simples, ou escolhi modelos de última geração para escrever uma mensagem de commit.

O objetivo deste texto é mostrar que podemos encontrar o equilíbrio entre o uso de agentes de IA e código determinístico. E faremos isso com um caso real, uma PoC que construímos e validamos junto ao cliente.

Nota de confidencialidade: para proteger o negócio do cliente, o segmento de mercado, os produtos e todos os números de catálogo e de conversa deste artigo foram alterados para um domínio fictício. A arquitetura, os mecanismos e as lições, porém, são exatamente os do projeto real.

O cenário

O cliente em questão possui um e-commerce para venda de baterias automotivas. Mas um problema tem incomodado este cliente: a alta taxa de devolução de produtos. Bateria é um produto que o consumidor costuma comprar com urgência e devolver por incompatibilidade, como quando a caixa não cabe no suporte, o polo fica do lado errado ou a bateria não atende ao sistema start-stop do veículo. Isso gera uma experiência ruim para o consumidor final e custos operacionais para a loja. Ou seja, é uma dor latente que precisava de solução.

A ideia para resolver esse problema é muito simples e bastante difundida em e-commerces: criar um chatbot agêntico para guiar o usuário no processo de compra da bateria mais adequada.

Os critérios de seleção

Cada mercado possui suas próprias características. Vender bateria automotiva não é igual a vender uma camisa, por exemplo. Uma camisa já possui uma tabela de tamanhos pré-definidos e o cliente apenas escolhe o tamanho mais adequado. Para recomendar a bateria correta, o chatbot precisa conhecer uma série de variáveis:

Montadora: qual a marca do veículo?
Modelo: qual o modelo do veículo?
Ano: qual o ano de fabricação?
Motorização: 1.0, 1.3 turbo, 2.0…?
Start-stop: o veículo tem sistema start-stop (o motor desliga sozinho nas paradas)?

Nós chamaremos essas variáveis de gates. Cada gate elimina um conjunto de baterias incompatíveis. Funciona como uma espécie de funil.

(Sim, essa imagem foi gerada por IA)

A primeira ideia: por que não jogar tudo num RAG?

O RAG é uma técnica bastante difundida para responder perguntas com base em um conjunto de documentos. Os documentos são indexados em um banco vetorial e o LLM responde usando os trechos recuperados. No nosso caso, isso significaria indexar os datasheets dos fabricantes e deixar o LLM responder sobre a compatibilidade das baterias. Essa foi a primeira alternativa que avaliamos, e acabou descartada por três motivos:

Compatibilidade é uma decisão conjunta sobre atributos estruturados. A bateria recomendada precisa atender a todos os critérios ao mesmo tempo: montadora, modelo, ano, motorização e presença do sistema start-stop. A busca por similaridade devolve os trechos mais parecidos com a pergunta, mas não garante que eles cubram todas as restrições, nem que sejam do produto certo.
As especificações estão descritas em texto livre. Informações como "indicada para motores 1.0 a 1.6, exceto versões turbo" aparecem no meio das características técnicas do produto. Além disso, o catálogo possui muitos produtos parecidos, da mesma família e com amperagens diferentes. Um modelo probabilístico pode facilmente misturar as especificações de dois produtos semelhantes. No nosso caso, esse tipo de erro significa uma devolução.
O critério de aceite do projeto era rigoroso: nenhuma recomendação poderia contradizer a fonte oficial. Esse tipo de garantia não pode ser obtido com um processo probabilístico, por melhor que seja a taxa de acerto. Ela precisa vir de código determinístico, que pode ser auditado e testado. Quando cada erro gera o custo de uma devolução, acertar na maioria das vezes não é suficiente.

Percebemos que estávamos misturando duas tarefas diferentes, recuperar informação e decidir compatibilidade. RAG é ótimo na primeira e inadequado para a segunda. Então o RAG não foi descartado, foi realocado. Ele reaparece mais adiante, com outra função.

A arquitetura

Para construir a PoC, desenhamos uma arquitetura fundamentada na AWS. O diagrama abaixo representa essa arquitetura com seus principais componentes.

CloudFront: hospeda o código necessário para renderizar o chatbot na página do e-commerce.
API Gateway: responsável pela intermediação entre frontend e backend.
Lambda: hospeda o código do backend, responsável por orquestrar as chamadas ao Bedrock, aplicar os gates e filtrar os produtos compatíveis.
DynamoDB: armazena o estado da conversa (controle de sessões, com expiração automática).
Bedrock: aciona o LLM (Claude Sonnet 4.6) que extrai os gates e conduz a conversa, invocado pelo backend; o system prompt do agente fica versionado no Bedrock Prompt Management, o que permite ajustar o comportamento do agente (e até rodar testes A/B de ordem de perguntas) sem deploy.
S3: armazena a tabela de compatibilidade, versionada, e as especificações dos produtos.
S3 Vectors: guarda o índice vetorial dos manuais e datasheets, usado pela camada de enriquecimento (RAG) que veremos adiante.

Nesta demonstração, tomei a decisão deliberada de não usar um banco de dados ou API externa para consultar a compatibilidade dos produtos. A tabela de compatibilidade é um simples documento JSON, curado a partir dos datasheets oficiais dos fabricantes e versionado no S3. Obviamente que a primeira reação é achar que essa escolha não seria apropriada em um ambiente de produção. Mas ela não é um atalho de PoC. A fonte da verdade precisa ser estável, auditável e verificável linha a linha, e uma API viva de catálogo não oferece nada disso. Em produção, o que mudaria seria o storage (um banco de dados no lugar do arquivo), não o padrão. O catálogo vivo do e-commerce entra apenas para enriquecer a recomendação com preço, foto e estoque.

O processo passo a passo

Para o nosso teste de mesa, vamos considerar que o usuário enviou a seguinte mensagem para o chatbot: "Preciso de uma bateria para o meu Ford Mondeo". A mensagem é direcionada para o Bedrock, que extrai os gates. Vamos usar uma tabela para rastrear os gates durante o processo:

Gate	Valor	Encontrados
Montadora	Ford	38
Modelo	Mondeo	12
Ano
Motorização
Start-stop

Repare em dois detalhes. Primeiro, uma única mensagem preencheu dois gates. A extração é exaustiva e aceita qualquer ordem; a sequência do funil é uma preferência de condução, não uma camisa de força. Isso evita que o usuário tenha que repetir informações que já forneceu. Segundo, a coluna Encontrados mostra o total de produtos que sobram na tabela de compatibilidade após aplicar os gates acumulados. A consulta é cumulativa. Só com a montadora seriam 38 baterias; aplicando também o modelo, sobram 12. A cada novo gate extraído, o backend refaz essa consulta.

Toda resposta do agente configurado no Bedrock é um documento JSON que respeita o seguinte esquema, definido no system prompt:

{
  "extracted": {
    "montadora": "<string | null>",
    "modelo": "<string | null>",
    "ano": "<number | null>",
    "motorizacao": "<string | null>",
    "start_stop": "sim | nao | desconhecido | null"
  },
  "next_action": "ask | enrich | recommend | handoff",
  "gate": "montadora | modelo | ano | motorizacao | start_stop | null",
  "message": "<string>"
}

Alguns detalhes desse contrato merecem atenção:

extracted traz o que o agente identificou neste turno. O backend mescla esses valores no estado acumulado da conversa, e é o acumulado, não o turno, que alimenta a consulta de compatibilidade.
null e "desconhecido" são coisas diferentes. null indica que o gate ainda não apareceu na conversa; "desconhecido" indica que o cliente informou que não sabe a resposta, o que é bastante comum no caso do start-stop. O sistema trata cada um de forma diferente. null vira pergunta futura; "desconhecido" não é perguntado novamente, e limita o que pode ser prometido, como veremos.
gate é a próxima pergunta que o agente decidiu fazer. O backend usa esse campo para validar a pergunta e renderizar as opções de resposta rápida, que vêm de um catálogo definido em código, e não de texto gerado livremente pelo modelo.
next_action diz o que fazer com o turno: perguntar (ask), responder uma dúvida de apoio (enrich, assunto de uma seção adiante), recomendar (recommend) ou transbordar para atendimento humano (handoff).

Tendo em mente o formato da resposta, voltemos ao nosso exemplo (com números ilustrativos, como manda a nota de confidencialidade). Para a primeira mensagem do usuário, a resposta do agente seria algo como:

{
  "extracted": {
    "montadora": "Ford",
    "modelo": "Mondeo",
    "ano": null,
    "motorizacao": null,
    "start_stop": null
  },
  "next_action": "ask",
  "gate": "ano",
  "message": "Ótimo! Para encontrar a bateria certa para o seu Mondeo, me diga: qual é o ano do veículo?"
}

O código-fonte do backend efetua então a leitura da resposta do agente, mescla os gates capturados no estado da conversa e consulta a tabela de compatibilidade para filtrar os produtos. A quantidade de produtos compatíveis fica salva no estado da conversa, no DynamoDB. No próximo turno, o LLM lê essa informação para decidir a condução.

O agente somente efetua a recomendação quando todos os gates obrigatórios foram preenchidos. Mas atenção: preencher todos os gates é condição necessária, não suficiente. A garantia de que o usuário só recebe recomendações 100% compatíveis vem de três mecanismos empilhados:

Quem decide compatibilidade é o filtro determinístico sobre a tabela curada, nunca o LLM.
Só entram na recomendação produtos confirmados na fonte oficial para todos os gates levantados na conversa.
Se nenhum produto estiver confirmado, o agente transborda para o atendimento humano, em vez de forçar uma venda.

Isso é extremamente importante, considerando o objetivo que desejamos alcançar: reduzir o número de devoluções.

O diagrama de sequência abaixo apresenta a interação entre os atores sempre que o usuário envia uma nova mensagem para o chatbot.

Todo esse processo acontece de forma transparente para o usuário, que recebe como resposta a pergunta sobre o próximo gate. A tabela abaixo mostra a sequência de mensagens trocadas até o agente ter tudo que precisa:

Usuário	Agente	Gates	Encontrados
Preciso de uma bateria para o meu Ford Mondeo	Ótimo! Para encontrar a bateria certa para o seu Mondeo, me diga: qual é o ano do veículo?	Montadora: Ford, Modelo: Mondeo	12
É 2004	Perfeito, Mondeo 2004! E qual é a motorização? 2.0 ou V6?	+ Ano: 2004	8
2.0	Entendido! Última pergunta: o seu Mondeo tem sistema start-stop, aquele em que o motor desliga sozinho nas paradas?	+ Motorização: 2.0	4
Não tem	Ótimo! Tenho todas as informações necessárias. Vou buscar as baterias compatíveis com o seu carro agora!	+ Start-stop: não	4

Note que o agente pergunta sobre start-stop mesmo para um carro de 2004, pois não presume nada sobre o veículo do cliente. Note também que a resposta negativa não cortou o funil; nem todo gate elimina produtos.

Regras e restrições

O cenário desenhado neste artigo foi simplificado para facilitar a explicação (no projeto real havia mais gates, alguns condicionais, e mais regras de negócio). Na prática, aplicamos também:

Guardrails: o Bedrock aplica guardrails contra prompt injection e temas fora do escopo do agente. Nesses casos, a mensagem não é simplesmente ignorada. O turno é bloqueado com uma mensagem padrão; em segurança, a regra é fail-closed.
Handoff: quando o chatbot não pode recomendar, o usuário é direcionado ao atendimento humano e o atendente recebe um resumo do contexto da conversa, para o cliente não recomeçar do zero.
Verificação de estoque: antes de recomendar, o sistema consulta a API do e-commerce para exibir apenas produtos com estoque, além de obter foto e preço. Sem estoque, isso é comunicado ao usuário.
A guarda determinística: o LLM conduz a conversa, mas uma guarda em código valida cada decisão dele e impede, por exemplo, uma recomendação prematura, devolvendo a pergunta que falta. Aprendemos o valor disso na prática. Em certo momento, uma otimização implementada via prompt permitia encerrar o funil mais cedo quando restavam poucos produtos, e o teste de validação do cliente identificou que algumas perguntas estavam sendo puladas. A regra saiu do prompt e virou invariante de código. O que for garantia não reside no prompt.

Onde o RAG entra de verdade

É aqui que entra o RAG que realocamos no início do artigo. No meio do funil, o cliente pergunta:

"Qual a diferença entre uma bateria EFB e uma AGM?"

Isso não é resposta de gate, mas sim uma dúvida de apoio. O mesmo LLM que já lê a mensagem do turno detecta a dúvida, sem nenhuma chamada extra de classificação, e devolve next_action: "enrich". O backend então consulta o índice vetorial dos manuais e datasheets (S3 Vectors), responde a dúvida citando a fonte oficial e retoma o funil no mesmo turno, com a resposta seguida da próxima pergunta pendente. A conversa não perde o ritmo, e a dúvida não fica sem resposta.

As regras de ouro dessa camada:

O RAG nunca altera a seleção de produtos. Ele responde dúvidas; quem decide compatibilidade continua sendo o filtro determinístico.
O condutor nunca responde com base no conhecimento interno do modelo. Dúvida sobre produto vai para o RAG, que só afirma o que encontra nas fontes indexadas, ou seja, sem fonte, sem afirmação.
Em caso de falha, o sistema degrada com elegância. Se o RAG estiver fora do ar, o agente avisa que não conseguiu consultar e a conversa continua (fail-soft). Se o próprio LLM falhar, um fallback determinístico pergunta o próximo gate do funil. Se o guardrail falhar, o turno não prossegue (fail-closed).

Em resumo, o LLM decide e o código executa. E quando o LLM falha, o código mantém a conversa em andamento.

A garantia: proveniência por célula

Resta explicar o que sustenta a garantia de zero recomendações contradizendo a fonte oficial. Cada célula da tabela de compatibilidade (produto × atributo) carrega a sua proveniência: de qual documento e de qual página do datasheet oficial aquele valor foi extraído. Se um datasheet não declara um atributo, a célula fica marcada como desconhecido e o sistema nunca infere o valor. Essa é a regra "sem fonte, sem afirmação", e ela tem uma consequência sutil. Um produto com atributo desconhecido não é descartado do funil (ele pode até ser compatível), mas também não pode ser recomendado com aquele atributo como promessa.

Voltemos ao nosso exemplo. O funil terminou com 4 baterias compatíveis, mas o agente recomenda apenas 2. Por quê?

Gate aplicado	Compatíveis	100% confirmados
… + start-stop = não	4	2

Dois dos quatro fabricantes simplesmente não declaram a aplicação para o Mondeo 2004 nas suas tabelas oficiais. Carros antigos são os mais afetados, pois os catálogos priorizam a frota recente. Esses dois produtos não foram eliminados, mas o agente não tem fonte para prometer o encaixe. Então a recomendação exibe só os 2 confirmados.

E quando a conta chega a zero confirmados? O agente não flexibiliza o critério para mostrar proximidades. Transborda para o atendimento humano. No projeto real, houve um gate para o qual a fonte oficial não confirmava o atributo para nenhum produto do catálogo, e aceitamos, por decisão registrada em ADR, que 100% desses pedidos transbordassem para humanos. Pode parecer uma limitação do produto, mas é o comportamento certo quando a meta é reduzir devoluções.

Esse desenho também muda a forma de medir a confiança no agente. O filtro é código determinístico, então cada regra de compatibilidade pode ser coberta por testes. A proveniência, por sua vez, permite auditar qualquer recomendação até a página do datasheet de origem. Por fim, o roteiro de validação executado junto ao cliente exercita os casos-limite, inclusive os transbordos. Com isso, o critério de zero recomendações contradizendo a fonte oficial deixa de ser uma promessa e passa a ser verificado de forma objetiva. Esse foi o gate de qualidade que a PoC precisou passar para ser aprovada.

Custos

Uma das vantagens normalmente atribuídas ao uso de código determinístico está na redução de custos. O backend da aplicação roda em um Lambda com arquitetura arm64 e 512 MB de memória RAM, escrito em Python. Cogitamos Go ou Rust pela performance, mas o custo de computação do Lambda é desprezível perto do custo de tokens (menos de 1% do custo de um turno). A economia real vem da arquitetura, não da linguagem. É uma única chamada curta de LLM por turno, com o catálogo fora do contexto, já que a consulta de compatibilidade é feita pelo backend, sem gastar token. O turno de abertura do widget sequer aciona o LLM. Um fallback determinístico faz a primeira pergunta.

A tabela abaixo apresenta uma estimativa de custos em diferentes cenários, considerando três abordagens:

Motor híbrido: a abordagem deste artigo.
100% IA (sem cache): o mesmo produto, mas com a tabela de compatibilidade e as especificações dentro do contexto a cada turno, e o LLM decidindo a compatibilidade.
100% IA (com prompt caching): idem, com o catálogo em cache de prompt.

Cenário	Motor híbrido	100% IA (sem cache)	100% IA (com prompt caching)
Por turno	$0,008	$0,074	$0,017*
Por conversa	$0,04	$0,37	$0,16
1.000 conversas/mês	$66	$396	$186
10.000 conversas/mês	$438	$3.738	$1.638
100.000 conversas/mês	$4.150	$37.150	$16.150

* No primeiro turno da conversa há o custo de escrita do cache (~$0,092); os turnos seguintes leem o cache.

Nota de metodologia: valores estimados com Claude Sonnet 4.6 (temperature 0, maxTokens 500); conversa típica de 6 turnos, dos quais 5 acionam o LLM (a abertura é determinística). No motor híbrido, cada turno usa ~1,5 mil tokens de entrada e ~230 de saída; nos cenários "100% IA", o catálogo adiciona ~22 mil tokens de entrada por turno. As linhas mensais incluem a infraestrutura fixa (API Gateway, Lambda, DynamoDB, CloudFront, S3), idêntica nas três colunas. Números arredondados para ilustrar ordem de grandeza.

Em termos relativos, quantas vezes mais caro fica o "100% IA" em relação ao motor híbrido:

Cenário	100% IA (sem cache)	100% IA (com prompt caching)
Por conversa	9,3×	4,0×
1.000 conversas/mês	6,0×	2,8×
10.000 conversas/mês	8,5×	3,7×
100.000 conversas/mês	9,0×	3,9×

Conclusão

A escolha por código determinístico em pontos estratégicos da arquitetura está ancorada em três pilares:

Acurácia
Custos
Latência

No caso apresentado, a acurácia foi o principal motivador. A recomendação precisa ser exata. E ser exata, neste contexto, significa nunca contradizer a fonte oficial. Essa propriedade só é garantida porque a decisão de compatibilidade é código determinístico sobre dado curado com proveniência. O LLM faz o que só ele faz bem: conversar, extrair informação em qualquer ordem e responder dúvidas com fonte citada.

A redução de custos foi consequência. Confesso que não pensamos nisso no início do projeto. Tampouco o cliente abordou a questão. Mas quando fizemos as contas, ficamos surpresos com a economia. Sem o motor híbrido, o catálogo inteiro seria enviado no contexto do modelo a cada turno, consumindo tokens para uma decisão que uma consulta de milissegundos resolve.

A latência seguiu o mesmo caminho. Como a consulta de compatibilidade é feita diretamente pelo backend, nem a requisição nem a resposta precisam ser interpretadas pelo modelo.

Apesar do avanço dos agentes de IA, o código determinístico continua sendo a melhor opção para os pontos do sistema onde entrada e saída são conhecidas. Um bom exemplo são os cálculos matemáticos. Uma simples calculadora, movida por duas pilhas AA, é muito mais rápida e eficiente para fazer contas do que um LLM rodando em um supercomputador equipado com várias placas de vídeo de última geração. Mas os casos que aparecem em produção raramente estão nesse extremo. O mais comum é o meio-termo, como no nosso exemplo. A conversa é aberta e, portanto, fica com o LLM. A decisão é fechada, uma regra de compatibilidade sobre uma tabela curada, e por isso fica com o código.

E esse meio-termo generaliza. Se no seu domínio uma recomendação errada vira devolução, troca ou retrabalho (autopeças, informática, móveis sob medida), a decisão deve estar ancorada em dados estruturados, verificáveis e com proveniência, filtrados por código. O LLM entra para conversar, extrair informações e enriquecer respostas, não para inventar a resposta.

Um bom arquiteto de software não é aquele que sempre usa os recursos mais atuais e avançados de computação, mas sim aquele que conhece a melhor aplicabilidade para cada tecnologia.