Like:Me · Estudo de arquitetura

Arquitetura do Produto · Adaptive Layer™ & Agentes

A proposta preserva o app, o backend e os parceiros atuais. A Adaptive Layer™ entra entre esses sistemas e os agentes para unificar contexto, controlar ações e tornar cada decisão observável. Atualizado em 21/08/2026.

Estudo técnico-executivo

Do produto integrado por APIs a uma plataforma operada por contexto, eventos e agentes

Este workspace confirma a separação em Landing, App Frontend e Backend/API, além das integrações registradas nas reuniões e documentos.

O código dos três produtos vive em repositórios externos. Como o conteúdo privado não estava acessível durante este levantamento, detalhes internos de runtime, banco e contratos são tratados como pontos de validação — não como fatos.

Estado real da IA: o copiloto de PM e o pipeline documentos → arquitetura/backlog são executáveis neste workspace. A Adaptive Layer operacional e os agentes de domínio descritos abaixo ainda são arquitetura-alvo, não runtime em produção neste repositório.

ConfirmadoObservável no código deste workspace ou no cadastro oficial do cliente.

DocumentadoRegistrado em atas e estudos do Like:Me; precisa ser conferido no produto.

PropostoArquitetura-alvo recomendada para a Adaptive Layer™ e os agentes.

Fontes: Workspace Like:Me · projetos, documentos e reuniões (jun–ago/2026) · Piloto Tabia Health · arquitetura de integração · Migração Social Plus in-house · arquitetura · Repos referenciados · LP-LikeMe, likeme-front-end e likeme-back-end

Arquitetura atual · visão consolidada

O que já existe ou está documentado hoje

Canais & experiência

Confirmado

Landing pública · aquisição e newsletter · App autenticado · marketplace, comunidade e jornadas de saúde · WhatsApp, push e e-mail como canais de relacionamento

Produto Like:Me

Documentado

Backend/API como núcleo de autenticação, domínio e integrações · Assinatura, pagamentos, afiliados, vouchers e perfis · Conteúdo, eventos, comunidade e programas de saúde

Plataformas conectadas

Documentado

Auth0 · identidade · Pagar.me · cobrança e recorrência · Social Plus / Amity · comunidade em migração · Tabia Health · care pathways · Panda · vídeo e conteúdo · SendGrid, WhatsApp/Twilio e push · comunicação

Engenharia & operação

Confirmado

Três repositórios: landing, frontend e backend · Backlog, documentos e reuniões no workspace PixelPulseLab · Entregas e grounding técnico via GitHub

Forças da base atual

Separação explícita entre experiência, API e landing
Ecossistema de parceiros cobre identidade, pagamento, cuidado, comunidade e comunicação
Produto já opera múltiplas jornadas e canais

Tensões que a Layer precisa resolver

Contexto do usuário fragmentado entre produto e parceiros
Exceções de cobrança e integrações ainda exigem acompanhamento manual
Eventos, contratos e ownership entre sistemas precisam de catálogo único
Migração da comunidade e integração Tabia aumentam a superfície operacional
Não há evidência, neste workspace, de trilha unificada de decisão, avaliação de agentes ou guardrails
Adaptive Layer e agentes operacionais ainda não possuem runtime implementado neste repositório

Arquitetura-alvo · Like:Me com Adaptive Layer™

Uma camada de operação entre canais, agentes e sistemas existentes

Experiências

App · web · WhatsApp · push · e-mail · operação interna

Squad de agentes

Jornada de cuidado · engajamento · assinatura · comunidade · operações

Adaptive Layer™

Contexto 360 · eventos · políticas e consentimento · ferramentas · orquestração · memória auditável · avaliações

Produto & parceiros

Backend Like:Me · Auth0 · Pagar.me · Tabia · comunidade · Panda · comunicação

Fundação confiável

Identidade · dados · filas · observabilidade · segurança · LGPD · versionamento

Event Gateway

Normaliza eventos como assinatura ativa, falha de cobrança, entrada em programa, conteúdo concluído e risco de churn.

Contexto 360

Monta uma visão autorizada da jornada sem transformar o LLM em nova fonte da verdade.

Tool Registry

Expõe ações permitidas como consultar assinatura, enviar mensagem, criar tarefa ou acionar atendimento.

Policy Engine

Aplica consentimento, escopo, limites financeiros, aprovação humana e regras de saúde antes de agir.

Orquestração

Coordena agentes, retries, filas, idempotência e handoffs para pessoas ou sistemas.

Memória & auditoria

Registra contexto, decisão, ferramenta, resultado, custo e feedback para investigação e melhoria.

Squad de agentes proposto

Especialização por domínio, coordenação pela mesma Adaptive Layer™

Agente de Jornada de Cuidado

Acompanha a entrada e a progressão em programas, orienta próximos passos e identifica gaps de adesão.

Disparos

· Assinatura ativa
· Entrada no programa
· Etapa não concluída

Ações

· Explicar próximo passo
· Lembrar atividade
· Encaminhar para atendimento

Guardrail principal

Não diagnostica nem altera conduta clínica; escalona sinais sensíveis.

Agente de Engajamento

Seleciona conteúdo, evento e canal adequados ao contexto e à preferência do usuário.

Disparos

· Baixa atividade
· Novo conteúdo
· Evento relevante

Ações

· Recomendar conteúdo
· Programar comunicação
· Testar próxima melhor ação

Guardrail principal

Respeita consentimento, frequência e opt-out por canal.

Agente de Assinatura & Pagamentos

Detecta falhas de cobrança, explica pendências e conduz recuperação sem decisões financeiras opacas.

Disparos

· Pagamento recusado
· Recorrência interrompida
· Cancelamento solicitado

Ações

· Consultar status
· Abrir régua de recuperação
· Acionar atendimento

Guardrail principal

Cobrança, estorno e mudança contratual exigem política explícita e, quando necessário, aprovação humana.

Agente de Comunidade

Apoia onboarding, descoberta e moderação durante e depois da migração Social Plus/Amity.

Disparos

· Primeiro acesso
· Post sinalizado
· Comunidade sem atividade

Ações

· Guiar onboarding
· Recomendar comunidade
· Priorizar moderação

Guardrail principal

Não publica nem pune autonomamente em casos ambíguos; preserva histórico e recurso.

Orquestrador Like:Me

Mantém a jornada ponta a ponta, identifica handoffs quebrados e direciona cada exceção ao agente ou time correto.

Disparos

· SLA vencido
· Evento sem consumidor
· Conflito entre jornadas

Ações

· Correlacionar eventos
· Abrir tarefa
· Escalar exceção
· Consolidar status

Guardrail principal

Coordena; não contorna políticas dos agentes especializados.

Loop operacional de todos os agentes

Observa

Recebe um evento confiável da Adaptive Layer™.

Contextualiza

Busca apenas os dados autorizados para aquela tarefa.

Decide

Avalia política, risco e próxima melhor ação.

Age

Usa ferramenta limitada ou solicita aprovação humana.

Registra

Grava decisão, resultado e feedback na trilha auditável.

Mapa de agentes na jornada Like:Me

Quem atua em cada etapa, sobre a mesma camada e as mesmas fontes

Descoberta & cadastro

Transformar interesse em conta ativa com dados mínimos e consentimento claro.

Assinatura & pagamento

Converter e manter a cobrança saudável, com pendência explicada.

Onboarding & programa

Levar o usuário ao primeiro valor do programa escolhido.

Jornada de cuidado

Sustentar adesão e sinalizar desvios com apoio humano no ciclo.

Comunidade & conteúdo

Gerar pertencimento com curadoria, eventos e moderação.

Retenção & recompra

Antecipar churn e devolver a próxima melhor ação ao time.

A5 · Orquestrador Like:Me

cobre todas as etapas

A2Engajamento

Assinatura & Pagamentos

Jornada de Cuidado

A4Comunidade

Jornada de Cuidado

A2Engajamento

Engajamento

Comunidade

Engajamento

A1Jornada de Cuidado

A3Assinatura & Pagamentos

A4Comunidade

Adaptive Layer™

Eventos · contexto autorizado · políticas · ferramentas · orquestração · auditoria

Backend Like:MeApp & LandingAuth0Pagar.meTabia HealthSocial Plus / AmityPandaSendGrid · WhatsApp · Push

Agente dono da etapaAgente de apoioAdaptive Layer™Canais de comunicação

O orquestrador cobre a jornada inteira. Cada agente especializado é dono das exceções da sua etapa e apoia as vizinhas, sempre consumindo eventos e ferramentas da Adaptive Layer™ — nunca bases paralelas.

Guardrails antes de autonomia

Saúde, pagamento e dados pessoais exigem arquitetura de controle — não só bons prompts

Saúde

Sem diagnóstico ou prescrição
Conteúdo clínico versionado
Escalonamento humano para risco

LGPD & identidade

Consentimento por finalidade
Minimização de contexto
Isolamento e trilha por usuário

Ações

Ferramentas allowlisted
Idempotência e limites
Aprovação para ações irreversíveis

Qualidade

Dataset de avaliação
Versão de prompt/modelo
Métricas de erro, custo e intervenção

A Layer não deve replicar dados clínicos, financeiros ou de identidade sem necessidade. Ela referencia as fontes oficiais, monta contexto mínimo por tarefa e registra por que cada dado foi usado.

Roadmap de adoção

Autonomia cresce depois de contratos, observabilidade e avaliação

Descoberta & contratos

2–3 semanas

Validar os diagramas com os repos privados e donos de domínio
Catálogo de eventos, APIs, dados sensíveis e owners
Baseline de cobrança, engajamento, comunidade e atendimento
Blueprint dos agentes e matriz de risco

Critério de saída: Arquitetura as-is assinada e primeiro caso de uso escolhido por impacto e risco.

Fundação da Adaptive Layer™

4–6 semanas

Event Gateway e contratos versionados
Identidade, consentimento e contexto mínimo
Tool Registry com leitura e ações reversíveis
Logs, tracing, custos e replay de eventos

Critério de saída: Um fluxo real é observável ponta a ponta sem planilha ou consulta manual.

Primeiro agente supervisionado

4–8 semanas

Piloto de Engajamento ou Pagamentos em modo recomendar
Fila de aprovação e handoff humano
Avaliações offline e shadow mode
Dashboard operacional do piloto

Critério de saída: Qualidade, segurança e ganho operacional superam o baseline acordado.

Squad & orquestração

evolução contínua

Jornada, comunidade e assinatura sobre a mesma Layer
Orquestrador e tratamento de exceções
Autonomia progressiva por ferramenta
Governança de versões, avaliações e incidentes

Critério de saída: Agentes compartilham eventos e políticas sem criar bases ou automações paralelas.

Decisões em aberto

Perguntas que precisam ser fechadas com produto, engenharia, dados e parceiros

Qual é o runtime, banco e modelo de deploy atuais do frontend e backend?

Quais domínios são fonte da verdade para perfil, assinatura, jornada, conteúdo e comunidade?

Quais webhooks/eventos já existem em Auth0, Pagar.me, Tabia e Social Plus/Amity?

Onde consentimentos e preferências de comunicação são armazenados e auditados?

Quais ações podem ser automatizadas, quais exigem aprovação e quais são proibidas?

Qual caso de uso oferece maior impacto mensurável com menor risco para o primeiro piloto?

Próximo passo recomendado

Workshop M0 para validar o as-is nos três repositórios e escolher o primeiro piloto.

Abrir boards