Da Cabine do Avião ao Terminal: o que aprendi construindo agentes de IA e infraestrutura na prática

Trabalho como comissária de voo há 11 anos e meio. Nos últimos dois, comecei a usar minhas folgas para construir sistemas de automação e infraestrutura, não em curso, em produção, com clientes reais usando o que eu construí. Esse artigo é sobre duas dessas experiências e o que elas me ensinaram sobre a diferença entre saber sobre IA e saber construir com IA.

Parte 1: Quatro agentes, um roteador, zero confusão

Numa empresa de consultoria de carreira que atende clientes internacionalmente, o atendimento era feito por humanos respondendo manualmente em quatro frentes diferentes: comercial, suporte, secretaria e financeiro. O mesmo WhatsApp, quatro tipos de pergunta completamente diferentes, e ninguém sabia de antemão qual ia chegar.

A solução não foi um agente genérico tentando fazer tudo. Foi quatro agentes especializados, Secretaria, Vendas, Suporte e Financeiro, cada um com sua própria identidade e função, mais um agente Supervisor classificando a intenção da mensagem e decidindo quem deveria responder.

Como funcionava na prática:

1. A mensagem chega via WhatsApp
2. Um text classifier identifica a intenção por trás da mensagem. É uma dúvida sobre preço? Uma reclamação? Uma pergunta sobre agendamento? Uma questão de pagamento?
3. O Supervisor direciona o atendimento para o agente certo
4. Cada agente roda como um agente LangChain de verdade, não só prompt solto, com seu próprio system prompt, sua própria memória de contexto persistida no Redis, e ferramentas específicas conectadas via HTTP Request e tool calling
5. O agente de Secretaria, por exemplo, tem acesso direto ao Google Calendar. Ele cria, consulta e deleta eventos de agendamento sozinho, sem intervenção humana
6. Pra perguntas que exigem contexto institucional (políticas, processos, FAQ), os agentes consultam uma base vetorial no Supabase via RAG. Os documentos são divididos em chunks, transformados em embeddings com OpenAI, e recuperados por similaridade semântica na hora da resposta

Essa separação resolveu um problema que eu via constantemente em tentativas de "um agente faz tudo": quanto mais você pede pra um único agente fazer, mais ele perde precisão. Um agente focado em uma única responsabilidade, com ferramentas específicas pro seu escopo, erra muito menos.

No fim, o fluxo inteiro envolvia dezenas de etapas: agentes, memória, RAG, integrações com Calendar, Notion e Supabase, tudo orquestrado em sequência. Não é pouca coisa pra rodar de forma estável, e foi exatamente aí que entendi por que a próxima parte desse artigo importa tanto.

O resultado prático: consolidamos o trabalho que antes precisava de três pessoas em uma única estrutura automatizada, reduzimos o tempo de entrega de currículos e cartas de 10 dias úteis para 5, e dobramos a capacidade de produção da equipe.

Parte 2: Quando o agente de IA precisa de um lugar para morar

Construir um agente é uma coisa. Mantê-lo rodando, de forma estável, 24 horas por dia, é outra completamente diferente. Foi aí que percebi que automação sem infraestrutura é automação que quebra na primeira instabilidade.

Recentemente, montei do zero toda a infraestrutura self-hosted para uma clínica de nutrição: VPS Linux, Docker, Traefik como proxy reverso, PostgreSQL e Redis para persistência, Evolution API pra WhatsApp, Typebot pra fluxos de chatbot, tudo orquestrado via Docker Swarm.

Nenhum tutorial prepara você pra esse momento: a mensagem está sendo enviada, o WhatsApp confirma o recebimento, mas o status no banco nunca atualiza de "pending" pra "delivered". Depois de investigar logs, descobri que o problema era um bug específico de como o WhatsApp lida com IDs internos (LID) em contas mais recentes. A confirmação chegava, mas o sistema não conseguia fazer o match com a mensagem original. A correção exigiu atualizar a versão da API e entender, na prática, como o protocolo de confirmação de mensagens funciona por trás dos panos.

Esse tipo de problema não aparece em nenhum curso. Aparece quando o sistema está em produção, alguém depende dele funcionando, e você precisa descobrir sozinha onde está a falha.

A conexão entre as duas experiências

O que essas duas experiências têm em comum não é a ferramenta, é a lógica. Um agente de IA bem desenhado e uma infraestrutura bem configurada resolvem o mesmo tipo de problema: pegar algo que hoje depende de intervenção manual constante, e fazer funcionar sozinho, de forma confiável.

A diferença entre um agente de IA e uma automação tradicional, como vi recentemente num artigo do Felipe Aguiar (DIO) sobre o projeto Freela Radar, é exatamente essa: automação segue um roteiro fixo e quebra na primeira variação; agente recebe um objetivo e ajusta o caminho sozinho. Mas nenhum dos dois sobrevive sem uma infraestrutura estável por trás, e é essa parte que, na minha experiência, menos gente está disposta a aprender, porque é a parte menos "glamourosa".

O que eu levo disso pra frente

Estou numa transição de carreira incomum: continuo voando, mas dedico cada folga e cada pernoite para construir sistemas reais. Não é o caminho mais rápido, mas é o caminho que me deu experiência prática suficiente para entender, na pele, a diferença entre construir um agente que funciona numa demonstração e construir um sistema que precisa funcionar todos os dias, sem ninguém olhando.

Sou Lauren Freitas, estou como comissária de voo e curso Análise e Desenvolvimento de Sistemas. Construo automações e infraestrutura self-hosted nas horas vagas.

P.S.: English version available on LinkedIn: https://www.linkedin.com/in/laurend-freitas | https://github.com/Lauren-Freitas