a16z: Quando a interface de usuário deixa de ser o produto, o que sobra na vantagem competitiva do software?

Editores: Nos últimos vinte anos, a vantagem competitiva do SaaS baseou-se em grande medida na interface de utilizador. Painéis, campos, fluxos de aprovação e hábitos dos utilizadores 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 e executar processos, a dependência da memória muscular humana e a sua fidelidade começam a diminuir, e a UI deixa de ser necessariamente a interface principal do software empresarial.

Isso não significa que os sistemas de registo percam valor, mas sim que a sua defesa está a mudar: de UI e hábitos de uso para modelos de dados, sistemas de permissões, conformidade, lógica de negócio, ciclos de execução e redes de colaboração entre múltiplas partes. No futuro, o software verdadeiramente diferenciado pode deixar de ser apenas um banco de dados de registo do trabalho humano, para se tornar um sistema de ação capaz de captar contexto, iniciar tarefas, coordenar agentes inteligentes e gerar continuamente novos dados durante a execução.

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

A seguir, o texto original:

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

No entanto, também é importante notar que, do ponto de vista técnico, esta atualização parece não trazer muitas mudanças substanciais. A API, agora reembalada sob o nome de “produto headless” pela Salesforce, na maior parte já existia há anos. Em outras palavras, trata-se mais de uma campanha de marketing típica da Salesforce.

A ideia principal deste novo produto é que os agentes podem aceder diretamente aos dados do sistema de registos, sem precisar de interagir através de uma UI desenhada para humanos. A UI tradicional ajuda os utilizadores humanos a acompanhar processos, gerir tarefas e avançar fluxos de trabalho; mas, após a intervenção dos agentes, 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 eliminarmos a UI e apenas disponibilizarmos o banco de dados subjacente, o que sobra de um sistema de registos? Em que difere ele de um banco de dados Postgres, de um esquema de dados bem desenhado e de um conjunto de APIs?

Mais além, os fatores clássicos que conferiam uma defesa de longo prazo aos sistemas de registos ainda se mantêm? Ou surgiram novos padrões de competição?

Na era SaaS, a vantagem competitiva dos sistemas de registos vinha do fato de os utilizadores humanos viverem há muito tempo na sua interface. Essa interface carregava hábitos de operação, processos organizacionais e sedimentação de dados, criando assim custos de migração elevados. Mas, na era dos agentes, essa vantagem está a ser enfraquecida. Os níveis de defesa mais sólidos estão a migrar, por um lado, para modelos de dados, sistemas de permissões, lógica de fluxos de trabalho e conformidade; por outro, para efeitos de rede, capacidade de geração de dados proprietários e execução no mundo real.

Quando o software evolui para um modelo headless, para onde se desloca a vantagem competitiva?

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

Sistema de Registo (System of Record, SoR) refere-se à fonte de verdade autoritativa de certos dados comerciais. É onde se encontram as versões oficiais de informações de clientes, registos de funcionários ou transações financeiras, sendo também o núcleo de leitura e escrita de outras ferramentas. CRM é o sistema de registo de dados de receita, HRIS de dados de pessoal, e ERP de dados financeiros e de fundos.

A força desses sistemas não reside apenas no armazenamento de dados, mas no fato de que, no final, eles se tornam a “versão da realidade” na qual toda a organização confia para operar.

Nos últimos vinte anos, o que a Salesforce vendeu aos clientes foi, na verdade, um método para os responsáveis de vendas gerirem as suas equipas. Painéis, visualizações de pipeline, ferramentas de previsão, fluxos de informação dinâmicos — esses são os verdadeiros produtos adquiridos. O modelo de negócio baseia-se na venda de licenças de acesso a essas funcionalidades, sendo a base de dados subjacente mais uma infraestrutura invisível.

Ou seja, o que realmente fideliza os utilizadores é a UI.

A UI limita as normas de dados, molda uma linguagem comum: pistas, oportunidades, contas de clientes. Ela faz com que milhares de representantes de vendas continuem a inserir 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 fidelizadora, ao ponto de muitos responsáveis de vendas continuarem a usar Salesforce na nova empresa após mudança de emprego, não por causa da interface, mas porque ela virou uma espécie de memória muscular.

Contudo, os agentes estão a começar a desafiar esse padrão. Eles já não precisam interagir via UI com o software, podendo aceder e modificar os dados de base diretamente. Isso também impulsiona uma nova geração de ferramentas e alternativas que contornam a interface tradicional. A Salesforce não é o único exemplo: recentemente discutimos como o ecossistema ao redor do SAP está a evoluir para algo mais adequado à chamada IA.

Ao mesmo tempo, agentes capazes de operar computadores tornam fatores humanos tradicionais — preferências, formação, contexto não documentado — cada vez menos relevantes ao longo do tempo. Em outras palavras, as condições para que um sistema de registos seja duradouro estão a mudar.

Antigos critérios de avaliação

Antes de discutir as mudanças na era dos agentes, é importante revisitar com mais precisão o que, no passado, tornava os sistemas de registos tão resistentes.

Os primeiros fatores estão relacionados com o modo como os humanos usam o software e com as suas preferências. A dificuldade de substituição depende, em grande parte, de UI, hábitos de uso, fluxos de trabalho humanos e arranjos institucionais já enraizados nos processos organizacionais.

Primeiro, qual a frequência de acesso?

CRM é utilizado diariamente por equipas de GTM e outros departamentos relacionados. Essa alta frequência de uso faz dele uma infraestrutura crítica. No entanto, a maior resistência à migração vem da camada humana — reuniões, hábitos operacionais, ritmos de gestão — que se formaram ao longo de anos e muitas vezes nem sequer são reconhecidas como algo que precise de ser migrado.

Segundo, é apenas uma entrada de dados ou também leitura?

Sistemas de registos altamente fiáveis são geralmente sistemas de leitura e escrita bidirecionais. Por exemplo, o CRM não é apenas um arquivo de armazenamento, mas um sistema continuamente consultado. Cada chamada telefónica, atualização de fase ou criação de tarefa é inserida por um utilizador que também se preocupa com o uso posterior desses dados.

Essa circulação bidirecional significa que qualquer alternativa deve suportar dados operacionais em tempo real, não apenas exportar dados históricos. A migração não tem um momento de troca absolutamente seguro; uma vez implementado, o sistema tende a permanecer na mesma plataforma por longos períodos.

Por outro lado, sistemas de rastreamento de candidatos (ATS) tendem a ser mais próximos de sistemas de apenas escrita. Após a contratação ou rejeição de um candidato, o uso posterior desses dados é relativamente limitado.

Terceiro, quão bem documentados estão os SOPs?

Os contextos de negócio realmente críticos muitas vezes não estão escritos em wikis, mas sedimentados em regras de fluxo de trabalho criadas 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; revisões de privacidade na região EMEA; descontos para clientes 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 pode ser perdida.

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

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

A conectividade interna refere-se ao número de softwares ou fluxos de trabalho dependentes dele. A conectividade externa refere-se à necessidade de acesso direto por auditores, contabilistas ou reguladores. ERP é um exemplo clássico.

Quanto maior a dependência, mais complexa será a desmontagem e reconstrução dessas ligações durante a 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 verdade legalmente válida?

Sistemas críticos de conformidade, como sistemas de remuneração, ERP ou dados de RH, devem fornecer uma fonte de fatos legalmente sólida, com controlo rigoroso de acessos administrativos. Qualquer migração pode envolver auditores e reguladores, reforçando a sua fidelidade.

Dados de vendas ou ferramentas de suporte ao cliente, como Zendesk, estão numa posição diferente. As empresas valorizam a continuidade e o contexto, mas, se os dados forem migrados ou acessados por terceiros, normalmente não há risco imediato de sanções regulatórias.

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

ATS é uma ferramenta de fluxo de trabalho para processos de recrutamento. Uma vez que o candidato é contratado ou rejeitado, esses dados tornam-se de uso único. A sua integração é mais limitada, com um grupo de utilizadores mais pequeno e focado.

ERP, por outro lado, é uma contabilidade que gera trilhas de auditoria, com reguladores e auditores como partes interessadas na migração.

Substituir um ATS é difícil, mas possível. Substituir um CRM é como fazer uma cirurgia de peito aberto. Trocar um ERP é como fazer uma cirurgia de peito aberto enquanto o paciente corre uma maratona.

Tradicionalmente, os sistemas de registos não exploraram realmente o valor de dados proprietários ou efeitos de rede; geralmente, os fluxos de trabalho por si só já criam barreiras. Em certa medida, a combinação de ferramentas e rede é mais comum em negócios de consumo; os sistemas SoR históricos não seguiram esse caminho.

Dados proprietários. Muitos sistemas de registos acumulam grandes volumes de dados de clientes, mas não os utilizam de forma aprofundada, e muitas vezes os contratos impedem essa exploração. Assim, apesar de possuírem conjuntos de dados ricos, teoricamente capazes de gerar insights transclientes, na prática, raramente o fazem de forma significativa. Produtos como o Einstein da Salesforce tentaram algumas abordagens nesse sentido.

Efeitos de rede. Para sistemas de registos, o ideal seria um efeito de rede: por exemplo, um CRM torna-se mais valioso à medida que mais compradores e vendedores nele participam. Mas, tal como os dados, esses efeitos de rede têm sido fracos ou inexistentes na história.

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

Os agentes não precisam de navegador. O que eles precisam são APIs, contexto, comandos e capacidade de executar ações. Duas coisas possibilitam que tudo isso aconteça em escala: primeiro, os LLMs já possuem raciocínio suficiente para que os agentes possam ler contexto, planejar, escolher ferramentas, executar ações e rever resultados, na maioria das tarefas, sem intervenção humana; segundo, o padrão MCP padronizou a forma de 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, um agente que opera computadores pode até usar interfaces de software existentes, sem necessidade de APIs.

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

Primeiro, continuar a usar os sistemas existentes, adicionando agentes sobre eles.
Utilizando CLI e APIs, podem usar produtos 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 registos do zero.
A empresa pode criar seu próprio modelo de dados, lógica operacional, sistema de permissões, auditoria e seu próprio stack de agentes, possivelmente usando ferramentas de terceiros.

Terceiro, adquirir substitutos nativos de IA.
Produtos de nova geração, projetados desde o início para a era dos agentes, enfatizam a legibilidade por máquina e a orquestração de agentes como capacidades de primeira classe, ao invés de simplesmente acrescentar uma funcionalidade de IA a sistemas antigos. Esses produtos também podem ser headless.

Então, quais critérios antigos de avaliação permanecem?

Fatores impulsionados por comportamento e preferência humana, como frequência de acesso e atributos de leitura/gravação bidirecional, vão diminuir com o tempo. Os agentes podem enfraquecer o valor da “memória muscular” como barreira, mas não eliminam as defesas baseadas em lógica operacional e contexto de negócio. Pelo contrário, esses fatores podem se tornar 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 a lógica de negócio que os agentes precisam para executar tarefas corretamente. Essa é a parte mais difícil de reconstruir, pois ainda não é possível exportar tudo de forma limpa, especialmente quando há processos que ainda requerem intervenção humana. No entanto, capturar contexto está cada vez mais fácil; à medida que os agentes substituem tarefas humanas, essa importância tende a diminuir.

A conectividade ainda é difícil de desmontar e tende a aprofundar-se.
O significado de conectividade está mudando. Não é mais apenas para apoiar o trabalho humano, mas para manter a ligação entre funções e softwares que tradicionalmente eram isolados.

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

Quando fornecedores tradicionais adicionam agentes, pode ser difícil fazer a integração fluida entre objetos e lógica de diferentes softwares de base; uma solução própria com banco de dados e agentes também enfrentará desafios semelhantes.

Dados críticos de conformidade continuam importantes.
Dados que envolvem órgãos reguladores, riscos legais ou de supervisão precisam de uma fonte única e confiável de verdade. Se os clientes confiam nos produtos atuais, a mudança de sistema será mais difícil.

Por exemplo, dados de remuneração e contabilidade podem precisar de acesso por agentes, mas as empresas geralmente não criam e mantêm esses sistemas internamente por longos períodos.

Num 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 registos puder atuar como camada de identidade e permissões entre agentes, ele adquire um papel estrutural verdadeiramente difícil de substituir. A barreira aqui não é apenas o dado que possui, mas a arquitetura de confiança que constrói.

Para o futuro, para startups de IA nativa, um conjunto de fatores emergentes será cada vez mais importante e determinará sua capacidade de criar defesas.

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

Os dados passarão a ser mais importantes em vários níveis.

Primeiro, no curto prazo, o mais importante é a facilidade de extrair e reconstruir os dados subjacentes. A IA está a tornar isso mais fácil, com ferramentas que ajudam na migração e reconstrução.

No curto prazo, fornecedores existentes podem — e provavelmente vão — dificultar esse processo: limitando APIs, tornando-as difíceis de usar, incompletas ou economicamente inviáveis, ou até não fornecendo APIs. Mas, à medida que as ferramentas de extração evoluem, especialmente com agentes capazes de operar computadores, a reconstrução de dados ficará mais acessível.

Simultaneamente, novas empresas estão a reconstruir conjuntos de dados mais ricos a partir de emails, chamadas, voz, documentos internos. A IA reduz o custo de reconstruir 80% de um sistema de registos. O que diferencia um bom ponto de entrada de uma substituição real é os últimos 20%: casos excepcionais, aprovações, requisitos de conformidade e fluxos de trabalho de cenários extremos.

Segundo, possuir dados proprietários realmente relevantes?

Os dados que oferecem defesa não são apenas os que você importa, mas aqueles que seu produto gera de forma única, por estar inserido em processos. Falamos de “muralhas 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 clara sobre fornecedores genéricos ou concorrentes que não possuem esses dados.

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

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

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

Terceiro, quem controla o nível de ação?

No mundo antigo, armazenar registros era suficiente. No novo, os agentes tomam ações diretamente, e a defesa passa a depender de produtos que possam fechar o ciclo: agir, capturar resultados, usar feedback para melhorar decisões futuras.

Para ERP, isso pode incluir aprovar despesas, disparar salários, verificar faturas, enviar notificações. Produtos que fecham o ciclo são mais defensivos, pois incorporam a execução, não apenas a observação. Eles geram dados únicos, que evoluem com o uso, e que se tornariam difíceis de substituir se removidos.

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

Quarto, há envolvimento na execução do mundo real?

Alguns modelos de negócio estão ligados à operação no mundo físico, e esses processos não podem ser totalmente automatizados. Exemplos claros são empresas com redes de operação, como a DoorDash. Elas não são sistemas de registos tradicionais, mas são exemplos inspiradores.

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

Para empreendedores, isso abre oportunidades em mercados onde o software toma cada vez mais decisões, agentes coordenam processos, mas a última etapa ainda depende de execução física. Por exemplo, softwares verticais ligados a operações presenciais.

Quinto, existe efeito de rede?

Historicamente, a maioria dos sistemas de registos tinha efeitos de rede fracos, pois eram softwares internos. Mas, na era dos agentes, se um sistema integra múltiplas partes em processos repetitivos, o efeito de rede pode tornar-se muito mais relevante.

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

Uma forma é a partilha de fluxos de trabalho colaborativos: o produto torna-se o espaço de transação, troca de contexto e resolução de exceções entre as partes.

Outra é a criação de benchmarks e recomendações inteligentes: o sistema pode mostrar padrões setoriais, anomalias e sugestões de ação, reforçando o valor dos dados.

Por fim, a confiança e a padronização: ao dependerem de uma mesma trilha para aprovações, transferências, conformidade ou pagamentos, as partes envolvidas passam a confiar na plataforma como infraestrutura de colaboração de mercado, tornando-a mais difícil de substituir.

Sexto, qual o nível de capacidade tecnológica do comprador?

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

O custo também importa. Fazer por conta própria pode reduzir custos de licença, mas aumenta despesas de 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, serviços no local e contabilidade.

Alguns fatores também se tornam essenciais e podem se tornar requisitos básicos de software.

Por exemplo, a ontologia precisa evoluir. Muitas ideias de “auto-construção de bancos de dados” subestimam o valor do modelo de objetos. Softwares tradicionais foram feitos para dashboards, relatórios e usuários humanos, capturando objetos como oportunidades, ordens de serviço ou candidatos.

Na era dos agentes, o esquema precisa capturar raciocínio, ações, rastreamento de estados, tratamento de 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.

Da mesma forma, os sistemas de permissões também precisam ser atualizados. Não basta gerenciar usuários humanos, mas também agentes. Isso inclui: quem pode fazer o quê, através de qual agente, sob que política, com quais aprovações, qual o rastro de auditoria, e como fazer rollback ou tratar exceções.

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

Então, qual é a conclusão?

À medida que os fornecedores tradicionais evoluem para o modelo headless, estão implicitamente a apostar que a camada de dados continuará a ser a fonte de valor principal. Em alguns setores, especialmente finanças, onde a conformidade é rigorosa, essa aposta pode manter-se por algum tempo, e o processo de headless pode ser mais lento.

Para startups de IA nativa, no entanto, à medida que os fornecedores tradicionais se tornam headless, a questão de como competir e construir software com defesa de longo prazo está a mudar.

As próximas gerações de sistemas de registos já começam a assumir formas diferentes: deixam de ser apenas armazéns de dados de trabalho humano, para se tornarem mais agentes, capazes de captar contexto, iniciar tarefas ativamente e registrar dados gerados durante a execução.

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

Essas empresas irão mesclar vários modelos de negócio tradicionais, enquanto o núcleo dos sistemas de registos — os dados — gradualmente recuarão para o fundo, sustentando toda a operação.

[Link para o artigo original]

Clique para conhecer as vagas na BlockBeats em recrutamento

Junte-se à comunidade oficial da BlockBeats:

Grupo Telegram de subscrição: https://t.me/theblockbeats

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

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