Slack como superfície agentic: a arquitetura de quatro camadas que a Salesforce está construindo para o futuro do trabalho
Entenda como o Slack deixa de ser ferramenta de comunicação e passa a ser a interface principal entre humanos e agentes na empresa agentic
A Salesforce apresentou um framework arquitetural com quatro camadas — Slack, Agentforce, Customer 360 e Data 360 — que reposiciona o Slack como o ponto central de orquestração do trabalho humano-agente. Se você arquiteta soluções Salesforce, esse modelo muda o que você precisa expor nas suas integrações.
Por muito tempo, o Slack foi tratado como canal de comunicação — útil, mas lateral ao núcleo das operações no Salesforce. Essa leitura está ficando obsoleta.
Em um artigo publicado no Salesforce Architecture Blog em maio de 2026, Mike Reynolds apresenta um framework arquitetural que posiciona o Slack como a camada de engajamento principal da empresa agentic. Não é marketing. É uma definição estrutural com implicações práticas para quem projeta soluções.
As quatro camadas da arquitetura agentic da Salesforce
O modelo organiza o ecossistema em quatro níveis bem definidos:
- Slack — System of Engagement (onde humanos e agentes se encontram)
- Agentforce — System of Agency (onde os agentes operam)
- Customer 360 — System of Work (onde o trabalho está registrado)
- Data 360 — System of Context (onde o contexto é construído)
Abaixo de tudo isso existe uma camada de Trust que abrange os principais modelos de linguagem do mercado — OpenAI, Anthropic, Gemini, LLaMA e modelos open-source. A arquitetura é deliberadamente agnóstica em relação ao modelo.
O que muda para arquitetos é a direção da lógica: as camadas abaixo do Slack deixam de expor dados e interfaces visuais para expor capacidades executáveis. O consumidor dessas capacidades não é mais apenas o usuário humano — é também o agente de software.
Slack como super app conversacional
O artigo referencia o relatório TechnoVision 2026 da Capgemini, que observa que "chat é o novo super app" — uma plataforma que consolida múltiplos serviços em uma interface única, eliminando a necessidade de alternar entre sistemas. O argumento é direto: o custo cognitivo de transitar entre CRM, inbox, rastreador de projetos e ferramentas de analytics para tomar uma única decisão não é sustentável à medida que o trabalho se torna mais colaborativo e menos centrado em entrada de dados.
O Slack resolve isso ao permitir que o usuário veja dados e aja sobre eles sem sair da conversa.
A arquitetura técnica por trás do Slack
Um ponto que o artigo aborda com seriedade é a infraestrutura que torna tudo isso possível. O Slack separa deliberadamente a lógica de aplicação (servidores PHP/Hack rodando em HHVM, responsáveis por autenticação, escrita em banco e validação de mensagens) da entrega em tempo real (servidores Java com conexões WebSocket stateful). Esse desacoplamento é o que permite escala horizontal sem comprometer performance.
No lado de dados, o Slack usa o workspace como unidade atômica de particionamento, com shards MySQL mapeados por workspace. A adoção do Vitess sobre o MySQL permitiu usar channel_id como chave de shard, reduzindo hotspots e suportando failover automático.
Para o problema do "thundering herd" — milhares de reconexões simultâneas após quedas de rede — a resposta é o Flannel, um edge query engine com cache distribuído globalmente. Ele serve apenas os dados essenciais no momento do boot do cliente, protegendo os bancos centrais de falhas em cascata.
Essa base técnica não é detalhe — ela é o que justifica apostar no Slack como camada de orquestração. Um sistema frágil não aguenta ser o ponto central de uma arquitetura agentic.
O papel do Slackbot como agente nativo
A mudança mais interessante do ponto de vista prático é o novo Slackbot, anunciado em outubro de 2025. Diferente de assistentes que exigem que o usuário recriar contexto a cada interação, o Slackbot opera a partir do contexto já acumulado — histórico de conversas, arquivos, canvases e dados conectados do Salesforce.
Isso é possível porque cada mensagem enviada no Slack passa por um pipeline de pós-processamento em milissegundos: indexação, roteamento de eventos e preparação para recuperação futura. Quando você faz uma pergunta ao Slackbot, o trabalho de estruturação já foi feito. A resposta é imediata porque o contexto não está sendo extraído no momento da pergunta — ele já foi processado.
Além de recuperar contexto, o Slackbot pode tomar ação: criar registros no Salesforce, registrar interações, gerenciar eventos no Google Calendar. O padrão arquitetural usado é o "tools in a loop" — o agente recebe a solicitação, identifica as ferramentas necessárias, chama essas ferramentas em paralelo quando possível, alimenta os resultados de volta no loop de raciocínio e repete até ter o suficiente para responder.
Antes de qualquer escrita em sistemas externos, uma etapa de confirmação humana é exibida inline na própria conversa. O agente suspende a execução, apresenta a ação proposta e só prossegue após confirmação do usuário — a menos que permissões ou políticas já tenham pré-autorizado aquela ação. Humano no controle, sem fricção desnecessária.
Protocolos emergentes: MCP e A2A
O artigo menciona dois protocolos que ampliam ainda mais o alcance dessa arquitetura: o Model Context Protocol (MCP) e o Agent-to-Agent (A2A). Eles conectam o Slack a sistemas externos que os agentes precisam consultar e sobre os quais precisam raciocinar. Os detalhes técnicos de implementação não são aprofundados no texto original, mas a menção reforça que a arquitetura foi desenhada para ser aberta — não um jardim murado.
O que muda na prática para quem arquiteta no Salesforce
Se você projeta soluções hoje pensando em Lightning Experience como superfície principal, esse framework sugere que vale revisar essa premissa — não necessariamente para abandoná-la agora, mas para entender que a direção está mudando.
As perguntas que passam a fazer sentido no design de integrações e automações: o que essa capacidade precisa expor para ser consumível por um agente? Onde está o ponto de confirmação humana? Como o contexto vai chegar ao agente sem precisar ser recriado pelo usuário?
Não é uma ruptura imediata. Organizações ainda estão em diferentes estágios de adoção. Mas o modelo arquitetural está posto, e ignorá-lo significa projetar sistemas com vida útil mais curta do que o necessário.
Para quem trabalha com arquitetura Salesforce, esse framework redefine o que precisa ser exposto nas integrações e automações. A lógica deixa de ser 'exibir dados em uma interface' e passa a ser 'expor capacidades executáveis para humanos e agentes'. Isso afeta decisões de design em Flow, Agentforce, integrações via MuleSoft e qualquer componente que hoje serve uma UI no Lightning Experience.
O artigo original é de Mike Reynolds, publicado no Salesforce Architecture Blog em maio de 2026. Os detalhes técnicos sobre a infraestrutura do Slack (PHP/Hack, HHVM, Vitess, Flannel) são apresentados como fatos arquiteturais — parte deles é verificável na documentação pública do Slack Engineering. A menção ao Slackbot atualizado é datada de outubro de 2025 pelo autor original.
Revise seus designs de integração e automação perguntando: essa solução expõe capacidades executáveis ou apenas dados visuais? Avalie onde os agentes do Agentforce precisam de contexto e como o Slack pode ser o ponto de superfície dessa interação. Para projetos novos, considere desde o início o padrão de confirmação humana inline — o Slackbot já implementa esse padrão nativamente. Se sua organização já usa Slack + Salesforce, o ponto de atenção imediato é garantir que as integrações existentes estejam prontas para ser consumidas por agentes, não apenas por usuários humanos via UI.
A arquitetura de quatro camadas descrita é o modelo conceitual da Salesforce — não necessariamente o estado atual de todos os produtos em GA. Verifique o roadmap do Agentforce e do Slackbot antes de comprometer um design de solução baseado nesse framework. Os protocolos MCP e A2A ainda estão em fase de adoção ampla; dependendo do seu ambiente, a maturidade de implementação pode variar. Organizações sem licença Slack Enterprise ou sem integração Slack-Salesforce ativa terão um gap significativo para chegar nesse modelo.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.