a16z：Quando a interface de usuário não é mais o produto, o que sobra da vantagem competitiva do software?

Editoração: Nos últimos vinte anos, a barreira de entrada do SaaS foi amplamente construída sobre a interface de usuário. Painéis, campos, fluxos de aprovação e hábitos de usuário não são apenas interfaces de operação, mas também moldam a forma como as organizações trabalham e a ordem dos dados. Quando a IA pode ler dados diretamente, chamar ferramentas, executar processos, a dependência da memorização muscular humana e sua adesão começam a diminuir, e a UI deixa de ser necessariamente a interface central do software empresarial.

Isso não significa que os sistemas de registro percam valor, mas que sua defesa está se deslocando: de UI e hábitos de uso, para modelos de dados, sistemas de permissão, conformidade, lógica de negócios, ciclos de execução e redes de colaboração entre múltiplas partes. No futuro, softwares verdadeiramente com barreiras competitivas podem não ser mais apenas bancos de dados que registram o trabalho humano, mas sistemas de ação capazes de captar contexto, iniciar tarefas, coordenar agentes inteligentes e gerar continuamente novos dados durante a execução.

Quando o software se torna headless (sem interface), a questão central do software empresarial também muda: o valor não está mais em quem possui os dados, mas em quem consegue organizar ações em torno deles.

A seguir, o texto original:

No mês passado, a Salesforce anunciou que abriria sua API e lançou um produto headless (sem interface). Essencialmente, isso significa que a Salesforce está apostando: na era dos agentes, seu valor central não vem mais principalmente da UI, mas da camada de dados. Essa é uma reposição bastante inteligente de posicionamento.

No entanto, também é importante apontar que, do ponto de vista técnico, essa atualização aparentemente não trouxe mudanças substanciais. A API que a Salesforce agora reembala como produto headless já existe há muitos anos. Em outras palavras, isso parece mais uma campanha de marketing típica da Salesforce.

A ideia central desse novo produto é que o agente pode acessar diretamente os dados do sistema de registros, sem precisar interagir por uma UI voltada para humanos. A função tradicional da UI era ajudar os usuários humanos a acompanhar processos, gerenciar tarefas e avançar fluxos de trabalho; mas, após a entrada do agente, a necessidade dessa camada de interface começa a diminuir.

O que realmente merece discussão nesta atualização não é apenas o que a Salesforce lançou de novo, mas uma questão mais fundamental: se remover a UI e abrir apenas o banco de dados subjacente, o que sobra de um sistema de registros? Ele ainda difere de um banco de dados Postgres, de um esquema de dados bem projetado e de um conjunto de APIs? Quão grande é essa diferença?

Além disso, os fatores clássicos que davam ao sistema de registros uma defesa de longo prazo — eles ainda se mantêm? Ou novas métricas de competição já surgiram?

Na era SaaS, a barreira de entrada do sistema de registros vinha do fato de os usuários humanos viverem por muito tempo dentro de sua interface. A interface carregava hábitos operacionais, processos organizacionais e sedimentação de dados, criando custos de migração elevados. Mas, na era dos agentes, essa vantagem está sendo enfraquecida. As camadas de defesa mais robustas estão se deslocando, por um lado, para modelos de dados, sistemas de permissão, lógica de fluxo de trabalho e conformidade; por outro, para efeitos de rede, geração de dados proprietários e capacidade de execução no mundo real.

Quando o software se torna headless, onde a barreira de entrada será transferida?

UI já foi a própria essência do produto

O que chamamos de sistema de registros (System of Record, SoR) é a fonte de verdade autoritativa para um tipo de dado comercial. É onde estão as versões oficiais de informações de relacionamento com clientes, registros de funcionários ou transações financeiras, e também o sistema central que outras ferramentas acessam para ler e escrever dados. CRM é o sistema de registros de dados relacionados à receita, HRIS é o sistema de registros de dados de pessoal, e ERP é o sistema de registros de dados financeiros e de capital.

A força desses sistemas não está apenas em armazenar dados, mas em se tornarem a “versão real” na qual toda a organização confia para seu funcionamento.

Nos últimos vinte anos, o que a Salesforce vendeu aos clientes foi, na verdade, uma maneira de ajudar os responsáveis por vendas a gerenciar suas equipes. Painéis, visualizações de pipeline, ferramentas de previsão, fluxos de informações dinâmicos — esses são os verdadeiros produtos vendidos. Seu modelo de negócio é baseado na venda de licenças de uso, que na prática concedem acesso às funcionalidades acima. O banco de dados subjacente é importante, mas funciona mais como uma infraestrutura invisível na experiência do produto.

Ou seja, o que realmente impulsiona a adesão do usuário é a UI.

A UI limita a norma de dados, molda uma linguagem comum: leads, oportunidades, contas de clientes. Ela faz com que milhares de representantes de vendas continuem inserindo dados que, de outra forma, talvez não quisessem registrar. No passado, a UI era o mecanismo que mantinha a consistência e a usabilidade dos dados. A Salesforce é altamente aderente, a ponto de muitos responsáveis por vendas continuarem usando Salesforce em novas empresas após trocar de emprego, não porque sua interface seja excepcional, mas porque ela virou uma memória muscular.

Porém, os agentes estão começando a desafiar esse padrão. Eles não precisam mais interagir via UI, podendo acessar e modificar diretamente os dados de baixo nível. Isso também impulsiona uma nova geração de ferramentas e alternativas que bypassam interfaces tradicionais. A Salesforce não é o único exemplo: recentemente discutimos como o ecossistema ao redor do SAP está crescendo para suportar chamadas de IA.

Ao mesmo tempo, agentes capazes de operar computadores fazem com que fatores tradicionais humanos — preferências, treinamentos, contextos não documentados — tornem-se cada vez menos relevantes ao longo do tempo. Em outras palavras, as condições para que um sistema de registros seja duradouro estão mudando.

Os critérios de avaliação do passado

Antes de discutir as mudanças na era dos agentes, é importante revisitar com mais precisão: o que, no passado, tornava os sistemas de registros tão aderentes?

Os primeiros fatores estão relacionados ao uso humano do software e às preferências humanas. A dificuldade de substituição depende muito de UI, hábitos de uso, fluxos de trabalho humanos e arranjos institucionais já enraizados na organização.

Primeiro, qual a frequência de acesso?

CRM é utilizado diariamente por equipes de GTM e outros departamentos relacionados. Essa alta frequência faz dele uma infraestrutura crítica. Por trás dele, há uma camada humana — reuniões de equipe, hábitos operacionais, ritmos de gestão — que se consolidaram ao longo de anos, e que muitas vezes nem são percebidas como algo que precise ser migrado.

Segundo, é apenas escrita ou leitura e escrita?

Sistemas de registros altamente aderentes geralmente suportam leitura e escrita bidirecional. No caso do CRM, ele não é apenas um repositório de dados, mas um sistema continuamente acessado. Cada ligação, cada atualização de estágio, cada criação de tarefa é inserida por um usuário que também se importa com o uso posterior desses dados.

Essa dinâmica bidirecional significa que qualquer substituto precisa suportar dados operacionais em tempo real, não apenas exportar dados históricos. A troca de sistema costuma não ter um ponto de corte absolutamente seguro, o que faz com que, uma vez implementado, o sistema original seja mantido por longo tempo.

Por outro lado, sistemas de rastreamento de candidatos (ATS) tendem a ser mais “write-only”. Após a contratação ou rejeição de um candidato, o uso posterior desses dados é limitado.

Terceiro, quanta documentação de SOPs (Procedimentos Operacionais Padrão) não formalizados existe?

O contexto de negócio realmente crítico muitas vezes não está documentado em wikis, mas sedimentado em regras de fluxo de trabalho construídas por administradores e integradores ao longo de anos.

Por exemplo, em sistemas de vendas, esses contextos podem incluir: aprovações de transações acima de 100 mil dólares por um VP; necessidade de revisão de privacidade na região EMEA; descontos estratégicos só aprovados no final do trimestre.

Esses contextos determinam se uma tarefa pode avançar a tempo ou se pode ser concluída sem violar processos essenciais. Migrar um sistema significa desmontar cada regra de automação, caso contrário, parte da memória organizacional será perdida.

Quarto, quão complexas são as dependências internas ou externas?

A questão central é: quantos sistemas internos, processos de equipe ou partes externas dependem desse sistema de registros?

A conectividade interna refere-se a quantos softwares ou fluxos dependem dele. A conectividade externa refere-se a se auditores, contadores, órgãos reguladores precisam acessar os dados diretamente. ERP é um exemplo clássico.

Quanto maior a dependência, mais complexa será a desmontagem e reconstrução dessas relações na migração.

Quinto, do ponto de vista de conformidade, quão crítico é o dado?

A questão aqui é simples: esse sistema é uma fonte de fato legalmente válida?

Sistemas críticos de conformidade, como sistemas de folha de pagamento, ERP, dados de RH, precisam fornecer uma fonte de verdade legalmente sólida, com controle rigoroso de permissões. Qualquer migração pode envolver auditorias e órgãos reguladores, aumentando a aderência.

Dados de vendas e ferramentas de suporte ao cliente, como Zendesk, estão em outro extremo. Empresas se preocupam com continuidade e contexto, mas uma migração ou mudança de acesso geralmente não acarreta riscos regulatórios imediatos.

Nem todos os sistemas de registros têm o mesmo custo de troca. Comparando CRM e ATS, a diferença é evidente.

ATS é uma ferramenta de fluxo de trabalho voltada ao recrutamento. Uma vez que o candidato é contratado ou rejeitado, o registro vira uma entrada única, de uso pontual. Sua integração é mais limitada, com um público menor e mais focado.

ERP, por outro lado, é uma espécie de livro-razão, com trilha de auditoria, acessada por contadores, auditores e órgãos reguladores, que são partes interessadas na migração.

Substituir um ATS é difícil, mas gerenciável. Substituir um CRM é como fazer uma cirurgia de abertura no peito. Trocar um ERP é como fazer uma cirurgia de coração aberto enquanto o paciente corre uma maratona.

Historicamente, os sistemas de registros não exploraram realmente o valor de dados proprietários ou efeitos de rede; geralmente, os fluxos de trabalho já eram suficientes para criar barreiras. Em certa medida, a combinação de ferramentas e rede é mais comum em negócios de consumo; os SoRs históricos não seguiram esse caminho.

Dados proprietários. Muitos sistemas de registros acumulam grandes volumes de dados de clientes, mas não os utilizam de forma aprofundada, e muitas vezes contratos impedem isso. Assim, apesar de possuírem conjuntos de dados ricos, teoricamente capazes de gerar insights transclientes, eles nunca fizeram isso de forma significativa. Produtos como o Einstein da Salesforce tentaram algumas abordagens nesse sentido.

Efeitos de rede. Para sistemas de registros, o ideal seria um efeito de rede: por exemplo, um CRM se torna mais valioso à medida que vendedores encontram compradores nele. Mas, assim como os dados, os efeitos de rede históricos desses sistemas sempre foram fracos ou quase inexistentes.

Se a UI desaparecer, após a chegada dos agentes, o que sobra do software?

Agentes não precisam de navegador. Eles precisam de APIs, contexto, comandos e capacidade de executar ações. Duas coisas possibilitam essa escala: primeiro, os LLMs já possuem raciocínio suficiente para que agentes possam ler contexto, planejar, escolher ferramentas, executar ações e revisar resultados, na maioria das tarefas, sem intervenção humana; segundo, o padrão MCP padronizou o acesso às ferramentas, oferecendo uma interface universal para chamadas externas.

Um agente com acesso ao MCP pode realizar, em milissegundos, uma grande quantidade de operações que antes eram feitas por humanos na plataforma, sem precisar de navegador. Com contexto suficiente, agentes capazes de operar computadores podem até usar interfaces de software existentes, sem APIs.

De forma simples, os compradores de software têm três caminhos:

Primeiro, continuar usando sistemas existentes, adicionando agentes sobre eles.
Através de CLI e APIs, podem usar agentes nativos do fornecedor, como o Agentforce da Salesforce ou o Joule da SAP, ou criar seus próprios agentes. Aqui, assumimos que as APIs são completas e acessíveis, e ignoramos a complexidade de uma operação headless na prática.

Segundo, construir um sistema de registros do zero.
A empresa pode criar seu próprio modelo de dados, lógica operacional, sistema de permissões, auditoria, integrações e sua pilha de agentes, possivelmente usando ferramentas de terceiros.

Terceiro, adquirir substitutos nativos de IA.
Empresas podem comprar softwares de nova geração, projetados desde o início para a era dos agentes. Esses produtos enfatizam a legibilidade por máquina, a orquestração de agentes como uma capacidade de primeira classe, e podem ser headless.

Então, quais critérios do passado permanecem?

Fatores impulsionados por comportamento e preferência humana, como frequência de acesso e atributos de leitura e escrita bidirecional, tendem a diminuir. Agentes podem enfraquecer o valor da “memória muscular” como barreira, mas não eliminam as barreiras de lógica operacional e contexto de negócio. Pelo contrário, podem torná-las ainda mais importantes, pois agentes precisam de regras claras, permissões e processos bem definidos para executar tarefas com segurança.

SOPs não documentados ainda são relevantes no curto prazo.
As regras de fluxo de trabalho sedimentadas na organização representam o conhecimento necessário para que agentes executem tarefas corretamente. Ainda é difícil exportar isso de forma limpa, especialmente quando há processos que envolvem humanos. Mas capturar contexto está ficando mais fácil, e à medida que agentes substituem trabalho manual, essa importância tende a diminuir.

A conectividade ainda é difícil de desmontar e tende a se aprofundar.
A noção de conectividade está mudando: não é mais apenas para facilitar o trabalho humano, mas para manter a integração entre funções e softwares que tradicionalmente operavam de forma separada.

Um CRM com agente precisa conectar dados e contexto de vendas, faturamento, sucesso do cliente, etc. Se sua plataforma se torna um ponto de troca entre múltiplas organizações, como compradores, vendedores e parceiros, as dependências se aprofundam.

Quando fornecedores tradicionais adicionam agentes, pode ser difícil fazer a integração entre objetos e lógica de diferentes softwares. Empresas que usam apenas um banco de dados próprio e uma equipe de agentes também enfrentam desafios semelhantes.

Dados críticos de conformidade continuam importantes.
Dados que envolvem órgãos reguladores, riscos legais ou de compliance precisam de uma fonte única e confiável. Se os clientes confiam na solução atual, a troca de sistema será mais difícil.

Por exemplo, dados de folha de pagamento e contabilidade, que requerem conformidade, podem precisar de acesso a sistemas específicos, mas empresas geralmente não criam esses sistemas internamente de forma duradoura.

Em um mundo totalmente agentizado, uma das questões mais difíceis é: quais agentes estão autorizados a fazer o quê? Quem eles representam? Como suas ações podem ser auditadas? Se um sistema de registros puder atuar como camada de identidade e permissão entre agentes, ele terá um papel estrutural difícil de substituir. A barreira aqui não é apenas o dado que possui, mas a arquitetura de confiança que constrói.

Olhar para o futuro, para startups nativas de IA, fatores novos se tornarão cada vez mais relevantes e determinarão sua capacidade de criar defesas.

Primeiro, quão difícil é reconstruir esse sistema de registros?

Dados se tornarão mais importantes em vários níveis.

Primeiro, no curto prazo, o desafio é extrair e reconstruir os dados do sistema de registros. A IA está facilitando isso, com ferramentas que ajudam na migração e reconstrução.

No curto prazo, fornecedores existentes podem dificultar esse processo: dificultando APIs, limitando acessos, tornando-as incompletas ou economicamente inviáveis, ou simplesmente não oferecendo APIs. Mas, com o avanço de ferramentas de extração e agentes capazes de operar computadores, a reconstrução de dados ficará mais fácil.

Simultaneamente, novas empresas estão reconstruindo dados a partir de e-mails, ligações, voz, documentos internos, criando conjuntos de dados mais ricos. A IA reduz o custo de reconstruir 80% de um sistema de registros. O diferencial está nos últimos 20%: casos excepcionais, aprovações, requisitos de conformidade e fluxos de trabalho de cenários extremos.

Segundo, possuir dados proprietários realmente relevantes?

Dados que oferecem defesa não são apenas os que você importa, mas aqueles que sua solução gera de forma única, por estar inserida em processos. Conhecemos a ideia de “muralha de dados”: dados proprietários, regulados ou que requerem atualização contínua. Empresas que investem em coletar dados autoritativos e completos terão vantagem competitiva.

Além disso, os dados dependem das ações internas do produto.

As melhores empresas não apenas armazenam dados de fontes externas, mas geram novos dados ao longo do fluxo de trabalho, como comportamentos observados, taxas de resposta, padrões de tempo, resultados de processos, benchmarks, anomalias e trilhas de execução de agentes.

O ponto-chave é: dados hoje são contexto.

Terceiro, dominar a camada de ações?

No passado, armazenar registros era suficiente. No novo mundo, agentes que tomam ações podem criar produtos de ciclo fechado: desde a ação, captura do resultado, até a retroalimentação para melhorar decisões futuras.

Para ERP, isso pode incluir aprovar despesas, disparar pagamentos, verificar faturas, enviar notificações. Produtos com ciclo fechado são mais defensivos, pois embutem a execução, geram dados únicos e se aprimoram com o uso, tornando-se mais difíceis de substituir.

À medida que o contexto se acumula e os cenários extremos são melhor tratados, esse valor aumenta.

Quarto, incluir etapas de execução no mundo real?

Algumas operações comerciais estão conectadas ao mundo físico, e essas etapas não serão totalmente automatizadas. Exemplos claros são empresas com redes de operação, como DoorDash. Elas não são sistemas de registros, mas são exemplos de integração com o mundo real.

De forma mais ampla, qualquer negócio que estenda o ciclo de software para serviços, entregas, logística, operações de campo ou pagamentos possui uma defesa diferente de SaaS puro. Essas empresas não apenas armazenam registros, mas também enviam equipes, movimentam bens ou realizam serviços específicos.

Para empreendedores, há oportunidades em mercados onde o software toma decisões, agentes coordenam processos, mas a última milha ainda depende do mundo físico. Software de operações no local é um exemplo.

Quinto, efeitos de rede?

Historicamente, a maioria dos sistemas de registros tinha efeitos de rede fracos, pois eram softwares internos. Na era dos agentes, se um sistema conecta múltiplas partes em fluxos repetitivos, os efeitos de rede podem se tornar mais relevantes.

Se um sistema facilita interações entre várias partes — compradores e vendedores, empregadores e empregados, empresas e auditores, fornecedores e clientes, pagadores e prestadores — cada novo participante aumenta o valor para os demais.

Uma forma é a troca de fluxo de trabalho compartilhado: o produto vira um espaço de negociação, troca de contexto e resolução de exceções.

Outra é a apresentação de benchmarks e recomendações: com base em padrões observados na rede, o sistema pode mostrar tendências, anomalias e sugestões de ação, reforçando o valor dos dados.

Por fim, confiança e padronização: se os parceiros começam a usar a mesma trilha para aprovações, transferências, conformidade ou pagamentos, o produto se torna uma infraestrutura de colaboração de mercado, difícil de substituir.

Sexto, quão forte é a capacidade tecnológica do comprador?

Num mundo onde qualquer um pode criar seu próprio agente, a capacidade de construção varia muito. Em setores verticais ou entre compradores com poucos recursos internos de engenharia, a probabilidade de montar, manter e evoluir bancos de dados, fluxos e agentes é baixa.

Custo também importa. Fazer por conta própria pode reduzir custos de licença, mas aumenta gastos com implementação, manutenção e complexidade interna.

Isso cria oportunidades reais em setores com operações complexas e recursos tecnológicos limitados, como manufatura, construção, processos industriais, operações de campo e contabilidade.

Alguns fatores também se tornam barreiras de entrada: por exemplo, a ontologia do sistema precisa evoluir. Muitas ideias de “auto-construção” subestimam o valor do modelo de objetos. Sistemas tradicionais foram feitos para dashboards, relatórios e usuários humanos, capturando objetos como oportunidades, ordens de serviço, candidatos.

Na era dos agentes, o esquema precisa capturar raciocínio, ações, rastreamento de estados, exceções, delegação de tarefas e colaboração entre sistemas. Os objetos nativos podem passar a ser tarefas, intenções, threads, estratégias ou resultados.

A gestão de permissões também precisa ser atualizada. Não basta gerenciar usuários humanos, mas também agentes, incluindo quem pode fazer o quê, sob qual estratégia, com quais aprovações, rastreabilidade, rollback e tratamento de exceções.

Claro, tudo isso depende de custos: quanto custa montar e manter agentes e bancos de dados, qual o custo de APIs. E isso volta às questões centrais: quão difícil é reconstruir dados, quantas dependências existem, e o quão profundo o sistema está embutido.

E qual é a conclusão?

À medida que fornecedores tradicionais se tornam headless, eles implicitamente apostam que a camada de dados continuará sendo a fonte de valor principal. Em alguns setores, especialmente finanças, onde a conformidade é rigorosa, essa aposta pode se sustentar por mais tempo, e o processo de headless pode ser mais lento.

Para startups nativas de IA, porém, a mudança na estrutura do software está mudando o jogo: como competir com esses fornecedores, como construir softwares com defesa de longo prazo?

As próximas gerações de sistemas de registros já estão assumindo formas diferentes: não mais apenas armazéns de dados de trabalho humano, mas sistemas com atributos de agentes — capazes de captar contexto, iniciar tarefas ativamente e registrar dados de execução.

Mais ainda, as empresas mais interessantes irão se estender ao nível de execução no mundo real: coordenar equipes de campo, fornecedores de logística, times de serviço ou ativos físicos, ou atuar como intermediários entre múltiplas partes.

Essas empresas irão mesclar modelos de negócios tradicionais de registros. E o núcleo, os dados, que sempre foi a base, gradualmente ficará em segundo plano, sustentando toda a operação.

[Link para o artigo original]

Clique para conhecer as vagas na BlockBeats em recrutamento

Participe da comunidade oficial da BlockBeats:

Telegram: https://t.me/theblockbeats

Grupo de Telegram: https://t.me/BlockBeats_App

Conta oficial no Twitter: https://twitter.com/BlockBeatsAsia