mais lidos
Life at Nu
Conheça a sede do Nubank em Pinheiros, São Paulo/Brasil jan 11
Design
A nova aparência do Nubank: conheça nossa nova logo maio 17
Culture & Values
Como os valores e a cultura da Nu moldam os produtos que criamos ago 7
Carreiras
Reunimos grandes mentes de diversas origens que permitem a discussão e o debate e melhoram a resolução de problemas.
Saiba mais sobre nossas carreiras
Written by: Nubank Editorial
Por muito tempo, o chat do Nubank foi tratado como um produto dentro do app. Mas, conforme a empresa cresceu, o que antes era apenas um canal de suporte começou a concentrar responsabilidades demais: automações, roteamento humano, chatbots, fluxos operacionais, múltiplos produtos, novos países e, mais recentemente, inteligência artificial.
Em algum momento, o desafio passou a ser repensar a própria ideia de conversa como infraestrutura.
Essa foi a jornada apresentada por Natally Mauerverck, Engineering Manager no Nubank, durante o Platform Days realizado no escritório do Nu, em São Paulo. Na palestra, ela compartilhou como o time transformou um monólito altamente acoplado em uma plataforma conversacional desenhada para autonomia entre times, múltiplos agentes e IA em escala.
A mudança começou quando a equipe percebeu que o problema ia além da arquitetura. O antigo sistema já não sustentava, sozinho, a velocidade de evolução dos produtos, a expansão para novos canais e a necessidade crescente de experiências conversacionais mais inteligentes.
O resultado dessa transição foi uma mudança profunda de paradigma: deixar de enxergar o chat como uma feature isolada e começar a tratá-lo como uma capability platform capaz de habilitar diferentes jornadas, produtos e agentes dentro do ecossistema do Nubank.
O chat que cresceu junto com o Nubank
O chat nasceu junto com o Nubank, inicialmente focado no cartão de crédito, e evoluiu para acompanhar a expansão da empresa. Por isso, se tornou o coração da operação de suporte.
Na prática, isso significava que praticamente tudo passava pelo mesmo serviço central: o chat-client.
Ele era responsável não apenas pelo envio e recebimento de mensagens, mas também por automações, auto-replies, integração com chatbots, fluxos operacionais, notificações do aplicativo e gerenciamento do estado das conversas. Tudo baseado em uma arquitetura de máquina de estados construída anos antes, quando o contexto da empresa era completamente diferente.
Conforme novas necessidades surgiam, novas funcionalidades eram adicionadas a este mesmo núcleo. O resultado foi um sistema gigantesco, crítico e extremamente difícil de evoluir. Por isso, ficou claro que o problema também tinha uma dimensão organizacional, para além de técnica.
Cada nova funcionalidade dependia do mesmo codebase e os times precisavam fazer inner source dentro do serviço principal. Mudanças aparentemente pequenas podiam afetar fluxos críticos de atendimento humano e deploys começaram a causar ansiedade nas pessoas envolvidas.
O conhecimento também ficou concentrado: existiam pessoas específicas que “entendiam o chat-client”, porque a complexidade acumulada ao longo dos anos tornava difícil navegar por aquele sistema sem contexto histórico profundo.
Mas, ao mesmo tempo, o Nu continuava crescendo e o monólito continuava no centro de tudo.
Conheça nossas oportunidades
Quando o problema deixa de ser “refatorar o sistema”
Em muitos cenários, a reação natural seria propor um refactor, mas a virada de chave da equipe aconteceu quando a pergunta mudou completamente.
Em vez de perguntar “como refatoramos o chat?”, o time passou a discutir qual seria o papel da conversa na estratégia do Nubank para os próximos anos.
Essa mudança parece simples olhando em retrospecto, mas alterou completamente a direção do projeto. Esse novo olhar fez a discussão passar a ser sobre habilitação de capacidades, e não mais sobre manutenção técnica.
Ficou claro que o caminho para permitir múltiplos canais, suportar agentes especializados e criar uma base preparada para IA e workflows conversacionais mais sofisticados era investir no desenvolvimento de uma plataforma conversacional.
O nascimento da Conversation Platform
A principal mudança de arquitetura consistiu em separar infraestrutura conversacional de lógica de negócio.
Antes, tudo acontecia dentro do mesmo sistema central e, agora, a plataforma passou a cuidar apenas do que é responsabilidade comum e compartilhada:
Enquanto isso, os times de produto passaram a construir agentes independentes responsáveis pelas regras específicas de negócio e, na prática, a conversa passou a ser tratada como infraestrutura.
Assim, ficou mais fácil democratizar a compreensão desta ferramenta dentro do Nu.
Arquitetura orientada a agentes
Com a nova abordagem, a plataforma recebe os eventos das conversas e encaminha cada interação para o agente apropriado. Para possibilitar essa decisão, criamos o componente agent selector.
Ele determina qual agente é responsável por cada tarefa. Alguns dos agentes, nesse contexto, são determinísticos: eles têm fluxos previsíveis, auditáveis e estruturados em regras bem definidas. O atendimento humano é um exemplo disso, assim como as jornadas mais rígidas e controladas.
Outros agentes, por sua vez, utilizam IA, modelos de linguagem e recuperação de contexto para executar interações mais flexíveis. O ponto importante, porém, é que todos os agentes seguem contratos padronizados, independente do tipo.
Isso permitiu que os times de produto construíssem seus próprios agentes sem depender diretamente do time responsável pela plataforma. Isso também fez com que os deploys passassem a ser independentes e, por isso, o acoplamento diminuiu drasticamente. A evolução da plataforma deixou de bloquear a evolução dos produtos, e vice-versa.
O verdadeiro desafio
Construir a arquitetura foi difícil, mas reorganizar o funcionamento do time foi ainda mais. Durante a palestra, um dos pontos mais enfatizados foi que plataformas internas também são produtos, mas que carregam outro tipo de responsabilidade.
O time deixou de ser medido apenas por entregas de feature e passou a ser medido por:
Isso exigiu uma mudança profunda de mentalidade, porque a plataforma precisava habilitar outros times, e não centralizar decisões.
Ao mesmo tempo, os times consumidores passaram a ser responsáveis pelas métricas e jornadas dos próprios produtos e o time de plataforma deixou de ser dono da lógica de negócio.
Na prática, essa separação de responsabilidades exigiu alinhamentos, redefinição de ownerships e novos modelos de governança.
Dados conversacionais também precisavam mudar
Além disso, a arquitetura antiga dificultava a construção de métricas confiáveis e observabilidade consistente. Parte disso vinha da própria forma como as sessões eram gerenciadas (em memória), o que aumentava a complexidade das auditorias.
A nova plataforma passou a tratar dados conversacionais como entidades de primeira classe: sessões persistentes, eventos padronizados e datasets agnósticos, tudo com histórico auditável.
Mas, além disso, era preciso separar métricas de plataforma de métricas de produto. Antes, o time de chat também acabava responsável por métricas relacionadas às jornadas de negócio. Com a nova estrutura, os times consumidores passaram a construir suas próprias métricas utilizando os dados disponibilizados pela plataforma.
Essa mudança foi importante não apenas para a observabilidade, mas para tornar a nova estratégia mais sustentável.
Construir o novo foi mais fácil do que desligar o antigo
Existe uma frase recorrente em projetos de modernização: “o legado sempre fica mais tempo do que o planejado”. No caso da Conversation Platform, isso também aconteceu.
A migração precisa acontecer de forma progressiva porque, na verdade, o novo sistema e o antigo coexistem. Mesmo com os principais agentes já validados em produção, o runtime da plataforma colocado em rollout gradual, e novos times migrando seus fluxos de forma independente, o antigo chat-client ainda existe, porque nem tudo funcionou perfeitamente desde o primeiro momento.
O tempo necessário para migrar o legado foi subestimado e alguns contratos evoluíram tarde demais, gerando retrabalho. Em alguns momentos, dados foram tratados como consequência da arquitetura, e não como parte central dela.
Desafios como estes são comuns em plataformas desse tamanho, mas o Nu é uma das poucas empresas que os compartilham de forma tão aberta.
Cinco aprendizados da jornada
Ao final da palestra, resumimos alguns dos principais aprendizados da transformação.
O primeiro deles foi mudar a pergunta: a modernização só ganhou força quando deixou de ser apresentada como “refactor” e passou a ser conectada à estratégia de produto e ao futuro da empresa.
O segundo aprendizado foi começar pelo domínio mais valioso. No caso do Nubank, conversa é infraestrutura crítica.
O terceiro foi tratar contratos como produto. Afinal, interfaces bem definidas reduzem o acoplamento e facilitam a autonomia.
O quarto foi entender que dados não podem ser tratados como afterthought, porque IA, métricas e observabilidade dependem diretamente disso.
E o quinto talvez seja o mais importante: plataformas exigem governança, e a arquitetura sozinha não resolve problemas organizacionais.
O futuro das plataformas conversacionais
A transformação do chat do Nubank em uma plataforma conversacional mostra como desafios de escala raramente são apenas problemas de infraestrutura. Em ambientes complexos, arquitetura, governança, autonomia entre times e dados precisam evoluir juntos.
Ao separar runtime conversacional da lógica de negócio, o Nubank criou uma base mais preparada para múltiplos canais, agentes especializados e experiências suportadas por inteligência artificial. Mais do que modernizar um sistema legado, a iniciativa abriu caminho para que diferentes times possam construir jornadas conversacionais com mais independência.
O monólito original segue coexistindo com a nova arquitetura enquanto os times avançam na migração gradual de fluxos e agentes, mas a direção está clara: tratar conversas não apenas como interface de atendimento, mas como a infraestrutura necessária para construir produtos digitais em escala.
Conheça nossas oportunidades