Clean Appless Architecture — Parte I

Estamos vivendo a era pós-app: onde as experiências se concentram em diálogo, não em telas.

Com o advento de interfaces conversacionais movidas por LLMs (ex.: ChatGPT), o usuário troca cliques por linguagem natural. No PicPay, batizamos essa abordagem de Appless: oferecer a experiência de um “aplicativo” (pagamentos, consultas, ofertas, relatórios etc.) por meio de canais conversacionais.

Mas como estruturar a arquitetura que sustenta essa jornada “sem app”? Quais são os princípios, blocos de construção e padrões que garantem escalabilidade, segurança e manutenção sustentável para soluções Appless? Neste primeiro artigo da série Clean Appless Architecture, você vai conhecer:

• O conceito Appless explicado de forma enxuta — por que ele vai além de uma interface conversacional e quais ganhos de negócio e experiência ele traz.
• Os pilares fundamentais — as cinco “camadas” que toda solução Appless deve contemplar, da interface conversacional ao monitoramento e feedback.

O que é Appless?

A resposta mais simples para essa pergunta é: oferecer uma experiência completa sem precisar de um app. Isso pode ser uma nova forma de criação de “aplicativos”, sem que o usuário necessite de diversos apps instalados em seu celular. Ter uma experiência fluída onde o cliente pode através de linguagem natural ter suas necessidades atendidas e respondidas. Pontos positivos dessa abordagem para o usuário: — Economia de espaço: Cliente não precisa de múltiplos apps; — Zero curva de aprendizado: Interação natural por texto ou voz. — Adesão facilitada: zero fricção para starts, basta iniciar uma interação com a interface escolhida (no nosso primeiro case foi o Whatsapp) e conversar sobre sua necessidade; — Respostas inteligentes: por ser uma abordagem AI First, o usuário tem respostas nas quais seus próprios dados são analisados baseados nas suas necessidades.

Pilares da Clean Appless Architecture

Para possibilitar esse padrão de arquitetura, é necessário que diversos pontos sejam atendidos. A mudança não é somente relacionada na forma como essa experiência é proposta para o usuário, mas também em como projetamos isso dentro de nossas arquiteturas. Muitos paradigmas precisam ser restabelecidos para uma arquitetura sem interfaces. Abaixo listo as 5 principais características para ter uma arquitetura escalável, segura e focada na experiência:

• Interface Conversacional
• Orquestração de Assistentes e Fluxos
• Gestão de Contexto e Estado
• Segurança e Privacidade
• Observabilidade e Feedback Contínuo

1. Interface Conversacional

Como estamos deixando de lado um padrão de cliques para um padrão conversacional, existem diversos pontos a serem explorados, como qual será o canal e a forma da conversa? Como será o fluxo conversacional? Para ajudar nessa escolha, estes são os principais pontos a serem observados:

1.1 Formato da Comunicação Antes de tudo, escolha o meio de interação que melhor equilibra custo, performance e acessibilidade:

• Texto — o fluxo mais leve e de custo operacional reduzido; ideal para casos de uso onde agilidade e baixo custo são prioridades.
• Áudio — oferece maior naturalidade e conveniência ao usuário, mas requer conversão Speech-to-Text (STT) antes de qualquer processamento e resposta da LLM, isso cria um aumento no tempo de resposta e um aumento do custo da ferramenta.
• Vídeo — enriquece o contexto com sinais visuais (expressões, gestos), porém demanda processamento adicional (STT, OCR de imagem) e impacto significativo em custo e infra-estrutura de streaming.

1.2 Design de diálogo O design do diálogo determina a liberdade do usuário e a sofisticação do backend necessário:

• Fluxo guiado — oferece ao usuário uma espécie de menu de opções para ele interagir, e o usuário necessita qual fluxo/agente será responsável por sua resposta e interação. As principais vantagens dessa abordagem são implementação mais rápida, respostas previsíveis e baixo esforço gerenciamento de contexto e como principais desvantagens são a sensação de estar conversando com um e “chatbot tradicional” e menor naturalidade/fluidez na conversa.
• Fluxo livre — Esse tipo de fluxo oferece uma maior fluidez e uma sensação mais “humana” na conversa, pois o usuário apenas informa sua necessidade e o backend será responsável por identificar qual agente ou quais agentes conseguem oferecer a melhor resposta ao usuário. As principais vantagens estão relacionadas a experiência do usuário, mas como desvantagens exige um “supervisor” inteligente capaz de interpretar intenções, gerenciar ambiguidades e orquestrar múltiplos agentes, e por esse motivo gera uma maior complexidade de implementação, manutenção e rastreabilidade.

1.3 Fallback Escolher um fluxo de fallback também é um ponto importante, como estamos falando em uma arquitetura appless, não existe 404. Quando um usuário tem uma solicitação do qual não é mapeada, qual será a resposta? Para isso existem algumas opções que podem resolver esse problema, são elas:

• Fallback automático — caso nenhum agente consiga responder a necessidade, um agente de fallback é chamado. Esse agente consulta uma base de FAQs ou KB e sugere soluções, informando passos para que o usuário resolva sua necessidade;
• Transbordo humano — quando o usuário demonstra insatisfação ou a intenção não foi mapeada, a conversa é redirecionada para um atendente humano que segue com o fluxo de exceção.
• Resposta genérica — esse fallback é o mais simples de ser implementado, pois dado uma necessidade não mapeada, uma resposta informando isso ao usuário é fornecida.

2. Orquestração de Assistentes e Fluxos

A orquestração é o coração de uma arquitetura Appless de êxito. Dividimos essa responsabilidade em duas camadas principais:

Imagem ilustrativa de uma arquitetura conversacional utilizando um supervisor

2.1 Broker O broker gerencia todos os eventos de mensagens entre o canal de comunicação e os agentes.

Funções:

1. Receber payloads de qualquer interface conversacional (áudio, vídeo e texto);
2. Enfileirar, priorizar mensagens e armazenar temporariamente arquivos com as devidas proteções alinhadas a segurança da informação;
3. Autenticar, validar autorização, criptografar e encaminhar ao(s) serviço(s) dos agentes ou microserviços de domínio.
4. Garantir retry e dead-letter para falhas transitórias.

2.2 Supervisor

Tem como suas responsabilidades identificar qual ou quais agentes devem responder a uma pergunta. Ele é o orquestrador das conversas, deve ter conhecimento sobre todas as especialidades e ferramentas que os seus agentes possuem. Suas principais funções são:

Funções:

1. Receber as mensagens do broker e extrair a intenção principal.
2. Mapear agentes responsáveis com base em capabilities/skills.
3. Agregar respostas parciais de múltiplos agentes (se houver) e enviar a resposta final ao broker.
4. Emitir métricas de uso de agentes e alertas de inconsistência de fluxo.

3. Gestão de Contexto e Estado

Em uma arquitetura Appless, a experiência do usuário depende diretamente da capacidade do sistema de lembrar onde ele parou, de informações importantes que ocorrem dentro do canal e de garantir que cada interação seja consistente e segura. Isso é papel da gestão de contexto e gestão de estado, dois elementos que evitam fluxos quebrados e efeitos colaterais indesejados.

3.1 Gestão de Contexto Responsável por armazenar e resgatar as informações da sessão/conversa de cada usuário. Principais funções:

• Persistência de sessão — manter dados como intenção, último agente acionado, e dados da transação em andamento.
• Histórico da conversa — registrar trocas recentes para retomada fluída após interrupções.
• Personalização — usar o contexto para respostas mais relevantes (ex: lembrar do produto que o usuário mencionou antes).

Exemplo prático: Quando o usuário começa um pagamento e abandona o fluxo, o contexto deve permitir que ele retome a operação sem precisar reiniciar todo o processo.

3.2 Gestão de Estado A gestão de estado define como o sistema responde a cada etapa e garante a consistência da jornada. Principais funções:

• Idempotência — garantir que uma mesma solicitação repetida (por falha de rede ou reenvio) não gere ações duplicadas (ex: dois pagamentos).
• Controle de transições — validar em que etapa o usuário está e impedir saltos de etapas (ex: não permitir a conclusão de pagamento sem a validação prévia).
• Expiração de sessão — definir regras de timeout para limpar estados inativos e evitar acúmulo de dados desnecessários.

4. Segurança e Privacidade Segurança e privacidade são pontos críticos em uma arquitetura Appless. Eles exigem uma revisão completa dos paradigmas tradicionais de proteção e autenticação, já que os fluxos não ocorrem dentro de um app proprietário, mas em canais de terceiros como WhatsApp e outros canais de conversacionais. Nesse cenário, o broker assume um papel central, funcionando como guardião da integridade, confidencialidade e rastreabilidade das mensagens trocadas no canal.

Veja a seguir os principais pilares de segurança que uma ferramenta Appless deve garantir:

• Criptografia de mensagens recebidas — todas as mensagens recebidas do canal escolhido devem trafegar de forma criptografada, garantindo integridade e confidencialidade ponta a ponta.
• Webhook seguro com o canal — a conexão com ferramentas de terceiros, como no caso do Whatsapp geralmente ocorre via webhook. Essa comunicação deve ser feita por um microserviço dedicado, encapsulado, com chaves de segurança e criptografia para assegurar o tráfego seguro das mensagens.
• Autorização do usuário — o canal deve implementar mecanismos que garantam o consentimento explícito do usuário para uso do serviço e dos dados compartilhados.
• Controles de segurança adicionais — a ferramenta deve oferecer múltiplos controles, como autenticação forte, gestão de sessão, monitoramento de atividades suspeitas e validação contra possíveis “clonagens” de contas ou fraudes.
• Governança de LLM e Guardrails — Implemente filtros de conteúdo, red team e políticas de privacidade para evitar vazamento de prompts e dados, toxicidade ou viés.

5. Observabilidade e Feedback Contínuo Um fluxo de arquitetura sem uma ferramenta visual exige uma maior rastreabilidade e observabilidade de tudo que pode estar ocorrendo nos fluxos conversacionais. Outro ponto extremamente importante é a coleta de feedbacks para identificar pontos de melhorias e observar todos os fluxos nos quais um fallback foi acionado, pois a intenção é sempre fornecer as melhores respostas para os usuários. Para fazer isso, alguns pontos precisam ser seguidos, são eles:

5.1 Logging estruturado e centralizado

• Registre cada etapa do fluxo de forma segura (recepção, orquestração, resposta, fallback) com informações como: ID da sessão, ID do usuário, intenção detectada, agente chamado, tempo de resposta.
• Use logs em formato estruturado (JSON, por exemplo) para facilitar consulta em ferramentas como CloudWatch, Datadog, Grafana.

5.2 Tracing distribuído

• Cada mensagem/conversa deve carregar um correlation ID único para permitir rastrear ponta a ponta: desde a entrada no broker até o agente e retorno ao canal.
• Permite identificar gargalos (ex.: onde houve latência acima do esperado).

5.3 Métricas chave (KPIs)

• Taxa de acerto da LLM ou do fluxo escolhido para dar respostas ao usuário(quantas intenções corretamente identificadas).
• Latência média e percentil (p95) das respostas.
• Taxa de fallback acionado (% de fluxos que precisam do fallback).
• Taxa de transbordo humano ou de fallbacks;
• Conversão por fluxo (pagamentos concluídos, consultas bem-sucedidas).
• Custo por sessão dos usuários

5.4 Alerta e monitoramento

• Crie alertas para padrões anômalos: picos de fallback, aumento na latência, aumentos de custos;
• Use dashboards em tempo real para que o time identifique e atue em incidentes rapidamente.

5.5 Feedback do usuário

• Registre e analise explicitamente as avaliações do usuário após o atendimento (ex.: “essa resposta foi útil?”).
• Use feedback passivo (ex.: se o usuário reformulou ou repetiu a pergunta) como sinal de insatisfação.

5.6 Loop de melhoria contínua

• Mapeie os fluxos com mais acionamentos de fallback e defina quais são prioritários para serem resolvidos;
• Use os dados de observabilidade para realizar fine tuning (retreinamento) do modelo de LLM ou revisar os fluxos conversacionais.

5.7 Testes automatizados de fluxos conversacionais Antes de qualquer nova versão ser publicada, é essencial validar os fluxos conversacionais com testes automatizados. Monte suítes de testes que simulem os principais diálogos (felizes e críticos) para garantir que:

• As intenções continuem sendo corretamente mapeadas;
• As respostas permaneçam consistentes;
• Os fluxos mais usados não tenham sido quebrados acidentalmente.

Esses testes devem ser executados em pipelines CI/CD e bloquear a publicação caso indicadores críticos (acurácia, regressões) estejam abaixo do esperado. Isso fecha o ciclo de qualidade, combinando observação em produção com prevenção antes do deploy.

Conclusão

Ao longo deste artigo, apresentamos os fundamentos da Clean Appless Architecture: um novo paradigma de experiência e arquitetura que vai além de simplesmente deixar de lado o app e mudar para um canal conversacional. Discutimos os pilares necessários para construir uma solução robusta, segura e escalável — da definição do fluxo conversacional à orquestração da ferramenta, da gestão de contexto ao monitoramento contínuo.

O Appless é mais que uma inovação: é uma mudança de paradigma que exige novas formas de projetar, desenvolver e operar experiências.

Nos próximos artigos da série:

• Vamos explorar como aplicamos esses princípios com exemplos práticos sobre como fizemos em nosso Broker do WhatsApp do PicPay, os desafios reais enfrentados e as soluções adotadas.
• Apresentaremos o funcionamento da camada de supervisor com múltiplos agentes.
• E um roadmap prático para adoção Appless, com o passo a passo para mapear jornadas, escolher canais, organizar os microserviços e implantar com segurança e observabilidade, do MVP até a escala.

✍️ Este artigo foi inspirado por princípios do livro “Clean Architecture”, de Robert C. Martin, adaptando-os ao contexto de arquiteturas conversacionais baseadas em LLMs.