O software está perdendo a cabeça?

• Com a Salesforce lançando produtos headless e apostando que a camada de dados, e não a UI, é o centro do valor, surge a pergunta sobre onde permanece a defensabilidade do SaaS na era dos agentes
• Na era do SaaS, o moat dos sistemas de registro (System of Record) era o hábito do usuário formado pela UI, mas essa vantagem enfraquece em uma estrutura em que agentes leem e escrevem diretamente no banco de dados
• A defensabilidade está se deslocando para baixo, em direção a modelo de dados, permissões, lógica de workflow e compliance, e para cima, em direção a rede, geração de dados proprietários e capacidade de execução no mundo real
• A próxima geração de sistemas de registro nativos em IA precisa de novos critérios como modelos de dados amigáveis para agentes, gestão de permissões por agente e fechamento do loop de execução
• Os negócios de próxima geração mais promissores são os que vão além do simples armazenamento de dados e se expandem até a execução no mundo real e a coordenação entre múltiplas partes

---

A pergunta levantada pelo anúncio headless da Salesforce

• No mês passado, a Salesforce anunciou a abertura de APIs e o lançamento de produtos headless, apostando que, na era dos agentes, o valor está na camada de dados, não na UI
  • Tecnicamente, quase nada mudou de fato — as APIs agora vendidas como produtos headless já existiam havia anos, em um lançamento de marketing bem ao estilo típico da Salesforce
  • A ideia central é uma estrutura em que agentes acessam diretamente os dados do sistema de registro, sem passar por uma UI feita para humanos
• Ao remover a UI e deixar apenas o DB, surge a pergunta essencial: em que isso difere de Postgres + um schema bem projetado + API?
  • É preciso revisar se os elementos que sustentavam os sistemas de registro até aqui continuam válidos ou se são necessários novos critérios

A era do SaaS em que a UI era o próprio produto

• Um sistema de registro (System of Record) é a fonte única e autoritativa da verdade para um domínio específico
  • Um CRM é o sistema de registro de receita, um HRIS é o sistema de registro de RH, e um ERP é o sistema de registro de finanças
  • O verdadeiro poder não está em ser apenas um repositório, mas em fornecer uma realidade compartilhada por toda a organização
• Nos últimos 20 anos, o que a Salesforce vendeu foi a forma como líderes de vendas operam suas equipes
  • Dashboards, pipeline views, ferramentas de previsão e activity feeds eram o que de fato se vendia, e o modelo de negócio era baseado na venda de seats de usuário
  • O DB por baixo era essencial, mas secundário
• A UI criou stickiness
  • Ela forçava a higiene dos dados, criava um vocabulário comum (Lead, Opportunity, Account) e fazia os vendedores inserirem dados que eles não colocariam espontaneamente
  • Muitos líderes de vendas levam a Salesforce consigo ao mudar de empresa não porque a UI seja excelente, mas por causa da memória muscular dos hábitos de uso
• Os agentes começaram a inverter esse modelo
  • Eles podem fazer read/write diretamente nos dados sem passar pela UI
  • Um ecossistema amigável a IA também está se espalhando rapidamente ao redor da SAP
  • Agentes que usam o computador podem, com o tempo, neutralizar fatores baseados em humanos, como preferências, treinamento e contexto não documentado

Critérios do passado para avaliar a stickiness dos sistemas de registro

• Fatores baseados na forma como pessoas interagem com software e em suas preferências

• Com que frequência é usado

  • O CRM é usado todos os dias pelas equipes de GTM, tornando-se infraestrutura central
  • Rotinas de trabalho, manipulações já internalizadas e cadências de gestão refinadas ao longo de anos são os elementos mais difíceis de migrar
  • Em muitos casos, ele nem chega a ser percebido como algo que precisa ser migrado

• É write-only ou read-write?

  • Sistemas de registro com stickiness são do tipo read-write
  • Um CRM é lido o tempo todo — registro de chamadas, atualização de etapas e criação de tarefas formam um fluxo bidirecional
  • Como lida com dados operacionais ao vivo, não existe um momento seguro para trocar → depois de adotado, é difícil sair
  • Já um ATS (Applicant Tracking System) é mais próximo de write-only — depois que a contratação termina, quase nunca se volta a consultar aqueles dados

• Quanto SOP não documentado existe

  • O contexto central do negócio fica codificado em regras de workflow, não em wikis
  • Exemplo em vendas: deals enterprise acima de US$ 100 mil exigem aprovação de VP, deals em EMEA exigem revisão de privacidade, e descontos para logos estratégicos só podem contornar Finanças no fim do trimestre
  • Esse contexto define a diferença entre um processamento em tempo hábil e uma falha por omissão
  • Migrar significa fazer engenharia reversa de toda a automação ou perder de uma vez a memória organizacional

• Escala das dependências internas e externas

  • Há necessidade de acesso direto por sistemas internos a jusante, além de auditores externos, contadores e reguladores
  • Quanto maior a conectividade dos dois lados, mais nós precisam ser desatados numa migração

• Importância do compliance

  • Dados de payroll, ERP e RH exigem uma fonte única da verdade defensável juridicamente, controle rígido de acesso administrativo e intervenção direta de auditores e reguladores
  • A stickiness é muito alta
  • Dados de vendas e ferramentas de atendimento como Zendesk ficam no lado oposto — continuidade e contexto importam, mas não há exposição regulatória

• Comparação dos custos de troca entre sistemas de registro

  • Um ATS é uma ferramenta de workflow com fronteiras claras, centrada em contratação, com integrações mais estreitas e menos usuários
  • Um ERP é o extremo oposto — o razão geral é a própria trilha de auditoria, e contadores, auditores e reguladores são stakeholders diretos
  • Trocar um ATS é doloroso, mas suportável; trocar um CRM é uma cirurgia cardíaca aberta; trocar um ERP é fazer cirurgia cardíaca aberta em um paciente no meio de uma maratona

• Elementos de moat tradicionalmente fracos

  • Dados proprietários — CRMs tinham dados ricos, mas tentaram pouco gerar insights entre clientes (com algumas iniciativas como Salesforce Einstein)
  • Efeitos de rede — eram o santo graal, mas historicamente foram fracos em sistemas de registro

O que sobra quando a UI desaparece e os agentes chegam

• Agentes não precisam de navegador — basta terem API, contexto, instruções e capacidade de agir

• Duas mudanças tornam isso possível

  • Melhora da capacidade de raciocínio dos LLMs: agentes conseguem ler contexto, planejar, escolher ferramentas, executar e revisar resultados sem intervenção humana
  • Padronização do acesso a ferramentas via MCP: agentes podem chamar funções externas por uma interface comum
  • Agentes que usam o computador também conseguem navegar interfaces de software legadas mesmo sem API, desde que tenham o contexto apropriado

• Três caminhos para compradores de software

  • Sistema existente + agente: usar CLI/API dos líderes atuais de SaaS, produtos nativos de agente (Salesforce Agentforce, SAP Joule) ou construir agentes próprios — mas isso pressupõe APIs completas e utilizáveis, e que a transição para headless seja operacionalmente simples
  • Construir seu próprio sistema de registro (DIY): criar do zero modelo de dados, lógica operacional, permissões, auditoria, integrações e agentes próprios (eventualmente com ferramentas de terceiros)
  • Comprar um substituto AI-native: uma nova geração de software criada desde o início com base em legibilidade por máquina, com orquestração de agentes como recurso de primeira classe e capacidade headless

• O que sobrevive dos critérios antigos

  • Fatores baseados em comportamento humano (frequência de uso, read vs read-write) → desaparecem junto com os hábitos de uso
  • Agentes matam o moat dos hábitos de uso, mas não matam o moat da lógica operacional e do contexto
  • Pelo contrário: para que agentes ajam com segurança, regras explícitas, permissões e definição de processos tornam-se ainda mais importantes

• No curto prazo, SOP não documentado continua importante

  • A lógica organizacional codificada nas regras de workflow é essencial para que agentes funcionem corretamente
  • Não é algo que se exporta de forma limpa (especialmente quando humanos ainda permanecem em parte do processo)
  • Ainda assim, isso tende a perder importância gradualmente à medida que capturar contexto fica mais fácil e os agentes substituem trabalho

• Conectividade ainda é difícil e se expande ainda mais

  • Mais do que seguir pessoas, o foco passa a ser manter a conectividade entre funções e softwares fragmentados
  • Um agente de CRM precisa costurar dados e contexto entre vendas, billing e customer success
  • Se ele se tornar um nó onde agentes de várias organizações externas negociam entre si, as dependências ficam ainda mais profundas
  • Tanto a combinação incumbente + agente quanto a combinação DB próprio + agente têm dificuldade para atravessar os diversos softwares subjacentes

• Dados de compliance continuam importantes

  • Dados com risco regulatório e jurídico continuam exigindo uma fonte única confiável de dados
  • É improvável que payroll e dados contábeis sejam construídos e mantidos internamente
  • O problema em aberto mais difícil de um mundo totalmente orientado por agentes: qual agente, agindo em nome de quem, pode fazer o quê, com qual auditabilidade
  • Um sistema de registro que se torne a camada de identidade e permissões das interações entre agentes impõe uma arquitetura de confiança, o que o torna estruturalmente difícil de substituir

Novos elementos de defensabilidade para startups AI-native

• Dificuldade de reproduzir o sistema de registro

  • No curto prazo, a facilidade de extrair e recriar os dados de um sistema de registro é central
  • Incumbentes de SaaS podem dificultar isso tornando APIs dolorosas, incompletas, bloqueadas ou economicamente inviáveis
  • Com a evolução das ferramentas de extração, especialmente agentes que usam o computador, isso vai ficando mais fácil
  • Ao mesmo tempo, surgem novas empresas reconstruindo dados mais ricos a partir de email, telefone, agentes de voz e documentos internos
  • A IA reduz o custo de reproduzir os primeiros 80% de um sistema de registro, mas os 20% restantes — tratamento de exceções, aprovações, compliance e workflows de edge cases — são o que realmente separa um substituto real de um wedge

• Existência de dados proprietários relevantes

  • Dados defensáveis não são os importados, mas os dados que o produto gera de forma única
  • O walled garden dos dados — dados proprietários, regulados ou que exigem atualização contínua
  • Provedores de software que investem em dados autoritativos e completos conquistam vantagem sobre provedores genéricos
  • Dados comportamentais gerados internamente: comportamento observado, taxa de resposta, padrões de timing, resultados de processo, benchmarks, padrões de exceção e rastreamento de performance de agentes
  • Dados são o contexto

• Quem controla a camada de ação

  • Antes, bastava armazenar o registro; na nova era, agentes agem
  • A defensabilidade migra para produtos com loop fechado de ação → captura de resultado → feedback → melhoria da decisão
  • Exemplo em ERP: aprovar gastos, disparar payroll, reconciliar invoices, enviar notificações
  • Produtos que fecham o loop ficam dentro da execução, não apenas da observação → geram dados únicos, melhoram com o uso e são difíceis de remover sem quebrar o workflow

• Elemento de execução no mundo real

  • Modelos de negócio com conectividade a operações do mundo real que não serão totalmente automatizadas
  • Casos como a rede operacional da DoorDash — historicamente não eram sistemas de registro, mas oferecem uma indicação importante
  • Softwares que fecham o loop com serviços, fulfillment, logística, operações de campo e pagamentos têm um tipo de defensabilidade diferente do SaaS puro
  • Não apenas armazenam registros ou recomendam, mas despacham pessoas, movimentam mercadorias e concluem serviços
  • Para builders, há oportunidade em mercados onde o software decide cada vez mais e agentes coordenam, mas a última milha ainda exige execução no mundo real — por exemplo, software vertical combinado com field service

• Efeitos de rede

  • Em sistemas de registro do passado, eles eram fracos porque o software era majoritariamente interno
  • Se o software ficar embutido em workflows multiparte, efeitos de rede podem se tornar muito mais importantes
  • Comprador-vendedor, empregador-empregado, empresa-auditor, fornecedor-cliente, pagador-prestador e outras interações recorrentes podem fazer o valor da rede crescer conforme mais participantes entram
  • Formas de implementação
    • Coordenação de workflows compartilhados — tornar-se o lugar onde ambos os lados transacionam, trocam contexto e resolvem exceções
    • Benchmarking e inteligência — oferecer normas, anomalias e recomendações com base nos padrões da rede
    • Confiança e padronização — ao se tornar o trilho comum de aprovações, handoffs, compliance e pagamentos, deixa de ser apenas um DB e passa a integrar a infraestrutura de coordenação de mercado

• Capacidade técnica do comprador

  • Mesmo numa era em que, em teoria, qualquer um pode criar agentes, a capacidade real varia muito
  • Em mercados verticais e para compradores funcionais com poucos recursos internos de engenharia, é improvável que consigam construir, manter e melhorar DB próprio, lógica de workflow, stack de agentes e governança
  • Custo também é central — o DIY reduz licenças, mas transfere o gasto para implementação, manutenção e complexidade interna
  • Há oportunidade em categorias operacionalmente complexas, mas tecnicamente pouco atendidas — manufatura, backoffice de construção, workflows industriais e de field service, contabilidade

Outros elementos obrigatórios (table stakes)

• Novo modelo de dados (ontologia)

  • A mentalidade de “DIY DB” tende a subestimar o valor do próprio modelo de objetos
  • Softwares legados foram feitos para capturar dashboards, relatórios e workflows humanos → Opportunity, Ticket, Candidate etc.
  • Schemas para agentes precisam capturar raciocínio, ação, rastreamento de estado, tratamento de exceções, delegação e coordenação entre sistemas
  • O modelo nativo de objetos muda para formas como task, intent, thread, policy e outcome

• Gestão de permissões de agentes

  • É necessário um sistema de permissões voltado não só para humanos, mas também para agentes
  • Definir quem, por meio de qual agente, sob quais políticas, com quais aprovações, trilhas de auditoria, rollback e tratamento de exceções pode fazer o quê

• Contexto de custo

  • Custos de construir e manter agentes e DBs, além de custo de acesso a APIs
  • Isso também se conecta à dificuldade de reproduzir dados e ao número de dependências

Conclusão — a direção da evolução dos sistemas de registro

• O movimento dos incumbentes de SaaS rumo ao headless é uma aposta implícita de que a camada de dados continuará sendo a fonte de valor
• Em categorias profundamente ligadas a compliance, como serviços financeiros, essa aposta deve continuar válida por algum tempo, e a transição para headless também está mais distante
• Para builders, a estrutura de oportunidade muda ao competir com incumbentes que estão migrando para o headless
• A próxima geração de sistemas de registro não será apenas um repositório de registros, mas uma forma amigável para agentes, capaz de capturar contexto, iniciar tarefas e registrar data exhaust
• Os negócios mais interessantes serão os que se expandem para a execução no mundo real — coordenando equipes de campo, provedores de logística, times de serviço e ativos físicos — ou os que se posicionam entre múltiplas partes
• Misturam o núcleo dos modelos de negócio do velho mundo e dos sistemas de registro tradicionais (dados), mas com os dados ficando em segundo plano