Editor's note: Ao longo das últimas duas décadas, a vantagem competitiva do SaaS foi em grande parte construída sobre a interface do usuário. Painéis, campos, fluxos de aprovação e hábitos dos usuários não são apenas interfaces de operação, mas também moldam a forma como as organizações trabalham e organizam seus dados. Quando a IA puder ler diretamente os dados, chamar ferramentas e executar processos, a fidelidade baseada na memória muscular humana começa a diminuir, e a interface do usuário já não é mais necessariamente a interface central do software empresarial.
Isso não significa que o sistema de registro perdeu seu valor, mas sim que sua defesa está se deslocando: da interface e dos hábitos de uso, para modelos de dados, sistemas de permissões, responsabilidades de conformidade, lógica de negócios, ciclos de execução e redes de colaboração múltipla. O software verdadeiramente com vantagem competitiva no futuro pode não ser mais apenas um banco de dados que registra o trabalho humano, mas um sistema de ação capaz de capturar contexto, iniciar tarefas, coordenar agentes e gerar continuamente novos dados durante a execução.
Quando o software se torna headless, a questão central do software corporativo também muda: o valor não está mais apenas em quem possui os dados, mas em quem consegue organizar ações em torno dos dados.
The following is the original text:
No mês passado, a Salesforce anunciou que abriria sua API e lançaria um produto headless (sem interface). Essencialmente, isso significa que a Salesforce está apostando que, na era dos Agentes, seu valor central não virá mais principalmente da interface, mas sim da camada de dados. Trata-se de uma repositioning bastante inteligente.
No entanto, também é importante observar que, do ponto de vista técnico, este lançamento não parece trazer muitas mudanças substanciais. As APIs que a Salesforce agora apresenta sob o nome de “produtos headless” já existem há muitos anos. Em outras palavras, trata-se mais de um lançamento de marketing típico da Salesforce.
A ideia central deste novo produto é que o Agente possa acessar diretamente os dados no sistema de registro, sem precisar mais interagir por meio de uma interface projetada para humanos. O papel das interfaces tradicionais é ajudar os usuários humanos a rastrear processos, gerenciar tarefas e avançar fluxos de trabalho; mas, após a introdução do Agente, a necessidade dessa camada de interface começa a diminuir.
O verdadeiro ponto a ser discutido neste lançamento não é apenas o que a Salesforce lançou de novo, mas a questão mais fundamental que ela levantou: se removermos a interface do usuário e apenas expormos o banco de dados subjacente, o que resta de um sistema de registro? Qual é realmente a diferença entre isso e um banco de dados Postgres, um esquema de dados bem projetado e um conjunto de APIs?
Mais especificamente, os fatores clássicos que antes garantiam a defesa de longo prazo dos sistemas de registro ainda são válidos? Ou novos padrões de competição já surgiram?
Na era do SaaS, os sistemas de registro possuem uma vantagem competitiva porque os usuários humanos vivem por longos períodos em suas interfaces. As interfaces incorporam hábitos de operação, processos organizacionais e acúmulo de dados, gerando assim altos custos de migração. Mas na era dos Agentes, essa vantagem está sendo enfraquecida. Os níveis verdadeiramente defensivos estão se deslocando, por um lado, para modelos de dados, sistemas de permissões, lógica de fluxo de trabalho e capacidades de conformidade; e, por outro lado, para efeitos de rede, capacidade de geração de dados proprietários e capacidade de execução no mundo real.
Quando o software se torna headless, onde a vantagem competitiva se desloca?
A IU já foi o próprio produto
O chamado Sistema de Registro (System of Record, SoR) é a fonte autorizada de verdade para determinados tipos de dados comerciais. É o local onde reside a “versão oficial” de dados como relacionamento com clientes, registros de funcionários ou transações financeiras, e também o sistema central do qual outras ferramentas leem e gravam dados. O CRM é o sistema de registro para dados relacionados à receita, o HRIS é o sistema de registro para dados relacionados a pessoas e o ERP é o sistema de registro para dados relacionados a capital e finanças.
A força desses sistemas não reside apenas no fato de armazenarem dados, mas no fato de se tornarem, finalmente, a "versão da realidade" na qual toda a organização depende para funcionar.
Nos últimos vinte anos, o que a Salesforce vendeu aos clientes foi, na verdade, um conjunto de ferramentas para gerentes de vendas administrarem suas equipes. Painéis, visualizações de pipeline de vendas, ferramentas de previsão e fluxos de informações dinâmicos são os produtos verdadeiramente comprados. Seu modelo de negócios se baseia na venda de licenças aos usuários, que, em essência, fornecem acesso a essas funcionalidades. O banco de dados subjacente é, sem dúvida, fundamental, mas na experiência do produto funciona mais como uma infraestrutura implícita.
Ou seja, o que realmente impulsiona a fidelização dos usuários é a UI.
A interface do usuário impôs normas de dados e moldou uma linguagem comum: pistas, oportunidades de vendas, contas de clientes. Ela fez com que dezenas de milhares de representantes de vendas continuassem inserindo dados que, de outra forma, talvez não tivessem interesse em inserir. No passado, a interface era precisamente o mecanismo que mantinha a consistência e a disponibilidade dos dados. A Salesforce possui tamanha fidelidade que muitos gerentes de vendas, ao mudarem de empresa, insistem em levar a Salesforce para a nova organização — não porque sua interface seja particularmente excelente, mas porque se tornou um hábito muscular.
Mas os Agentes estão começando a revolucionar esse modelo. Eles não precisam mais interagir com software por meio de interfaces gráficas, mas podem ler e escrever diretamente nos dados subjacentes. Isso também deu origem a uma nova gama de ferramentas e alternativas que contornam as interfaces tradicionais. A Salesforce não é o único exemplo: recentemente também discutimos como um ecossistema inteiro, mais adequado para chamadas de IA, está surgindo ao redor da SAP.
Ao mesmo tempo, agentes capazes de operar computadores farão com que fatores tradicionais humanos, como preferências, treinamento e contexto não documentado, se tornem gradualmente menos importantes ao longo do tempo. Em outras palavras, as condições necessárias para se tornar um sistema de registro duradouro estão mudando.
Critérios de avaliação anteriores
Antes de discutir o que mudará na era dos Agentes, é necessário retornar com mais precisão a uma pergunta: o que, no passado, tornou os sistemas de registro tão persistentes?
Os primeiros fatores estão principalmente relacionados à forma como os seres humanos utilizam o software e às suas próprias preferências. A dificuldade em substituir o software depende em grande parte da interface do usuário, dos hábitos de uso, dos fluxos de trabalho humanos e das estruturas institucionais já incorporadas nos processos organizacionais.
Em primeiro lugar, com que frequência ele é acessado?
O CRM é usado diariamente pela equipe do GTM e por muitos outros departamentos. É exatamente esse uso frequente que o torna infraestrutura crítica. E a camada humana construída sobre ele — como reuniões de equipe, hábitos operacionais e ritmos de gestão, formados ao longo dos anos como inércia organizacional — geralmente é a parte mais difícil de migrar. A razão é que muitas vezes nem é reconhecida como algo “que precisa ser migrado”.
Em segundo lugar, é apenas gravação ou leitura e gravação?
Um sistema de registro verdadeiramente aderente geralmente é um sistema de leitura e escrita bidirecional. Tomando como exemplo o CRM, ele não é apenas um sistema de escrita responsável por arquivar, mas também é constantemente lido. Cada registro de ligação, cada atualização de fase, cada criação de tarefa é inserida por algum usuário, e esse usuário normalmente também se importa com como esses dados serão utilizados posteriormente.
Esse fluxo bidirecional significa que qualquer alternativa deve ser capaz de absorver dados operacionais em tempo real, e não apenas exportar um conjunto de dados históricos. Quase não existe um ponto de transição absolutamente seguro durante a migração. Portanto, uma vez que a empresa conclui a implantação, geralmente permanece a longo prazo no sistema do fornecedor original.
Em contraste, os sistemas de rastreamento de candidatos (ATS) geralmente são mais próximos de sistemas "escreva-only". Após os candidatos serem contratados ou rejeitados, as empresas têm razões relativamente limitadas para retornar e usar esses dados.
Terceiro, quantos SOP não documentados existem?
Os contextos de negócios verdadeiramente críticos muitas vezes não estão escritos em nenhum wiki, mas sim consolidados nas regras de fluxo de trabalho construídas ao longo dos anos por administradores e integradores de sistemas.
Por exemplo, no sistema de vendas, esses contextos não documentados podem incluir: transações corporativas acima de 100 mil dólares exigem aprovação do VP; transações na região EMEA devem passar por revisão de privacidade; descontos para clientes estratégicos só podem contornar a aprovação financeira no final do trimestre.
Esses contextos, muitas vezes, determinam se algo pode ser impulsionado a tempo ou concluído sem violar processos críticos. Migrar sistemas significa reorganizar cada regra automatizada; caso contrário, a empresa pode perder diretamente parte de sua memória organizacional.
Quarto, quão complexas são as dependências internas ou externas?
A questão central é: quantos sistemas internos, processos de equipe ou partes interessadas externas dependem desse sistema de registro?
A conectividade interna refere-se ao número de softwares ou fluxos de trabalho downstream que dependem dela. A conectividade externa refere-se se entidades externas, como auditores, contadores e reguladores, precisam acessar diretamente os dados nela contidos. O ERP é um exemplo típico.
Quanto maior a conectividade, seja interna ou externa, mais complexas se tornam as relações que precisam ser desfeitas e reconstruídas durante a migração.
Quinto, do ponto de vista da conformidade, quão críticos são os dados?
A questão central é simples: este sistema é crítico para conformidade?
Sistemas críticos para conformidade, como sistemas de pagamento, ERP e dados de recursos humanos, devem fornecer uma fonte de fatos legalmente válida e possuir controle rigoroso de permissões de administrador. Qualquer migração pode exigir a intervenção direta de auditores e agências reguladoras. Isso torna sua adesão significativamente mais forte.
Dados de vendas e ferramentas de suporte ao cliente, como Zendesk, estão no outro extremo. As empresas certamente se importam com continuidade e contexto, mas, se os dados forem migrados ou alguém obtiver acesso, geralmente não acarretam imediatamente riscos regulatórios.
Nem todos os sistemas de registro possuem o mesmo nível de custo de mudança. Comparar CRM e ATS na mesma dimensão revela uma diferença muito clara.
ATS é uma ferramenta de fluxo de trabalho voltada para processos limitados, centrada na contratação. Uma vez que o candidato seja contratado ou rejeitado, os registros relacionados tornam-se principalmente dados de gravação única. Seu escopo de integração é mais restrito, e seu público de usuários é menor e mais concentrado.
ERP, por outro lado, está no outro extremo. O livro-razão em si é uma trilha de auditoria, e contadores, auditores e órgãos reguladores se tornarão partes interessadas diretas no processo de migração.
Substituir o ATS é doloroso, mas ainda tolerável. Substituir o CRM é como fazer uma cirurgia de abertura do tórax. Substituir o ERP é como fazer uma cirurgia de abertura do tórax no paciente enquanto ele corre uma maratona.
Tradicionalmente, os sistemas de registro não aproveitaram verdadeiramente fontes de vantagem competitiva como dados proprietários e efeitos de rede; geralmente, o próprio fluxo de trabalho já era suficiente para criar barreiras. Em certa medida, a integração de ferramentas com redes é mais comum em negócios voltados ao consumidor; os SoR históricos não seguiram esse caminho.
Dados proprietários. Muitos sistemas de registro, embora tenham acumulado grandes volumes de dados de clientes, não aproveitaram profundamente esses dados e, em muitos casos, os termos contratuais não permitem que o façam. Portanto, embora o CRM possua conjuntos de dados ricos e, teoricamente, possa consolidar dados de diferentes clientes para gerar insights interclientes, nunca o fez de maneira verdadeiramente significativa. Claro, produtos como o Einstein da Salesforce já fizeram algumas tentativas.
Efeito de rede. Para sistemas de registro, a melhor vantagem competitiva deveria ser o efeito de rede: por exemplo, um CRM se torna mais valioso à medida que vendedores de software conseguem encontrar compradores dentro dele. Mas, assim como os dados, historicamente o efeito de rede em sistemas de registro tem sido fraco, ou até mesmo quase inexistente.
Se a IU desaparecer, o que resta do software após a chegada do agente?
O agente não precisa de um navegador. Ele precisa de API, contexto, instruções e a capacidade de executar ações. Duas coisas permitem que tudo isso seja escalado: primeiro, os LLM já possuem capacidade de raciocínio suficientemente forte, permitindo que os agentes hoje leiam o contexto, planejem, escolham ferramentas, executem ações e revisem os resultados, sem necessidade de intervenção humana na maioria das tarefas; segundo, o MCP padronizou o acesso às ferramentas, fornecendo uma interface universal para os agentes chamarem capacidades externas.
Um Agente com permissão de acesso ao MCP pode realizar, em milissegundos e em grande escala, operações que anteriormente eram executadas por usuários humanos na plataforma, sem necessitar de um navegador. Em contextos suficientemente detalhados, um Agente capaz de operar um computador pode até utilizar interfaces de software existentes diretamente, sem necessariamente depender de APIs.
Em termos simples, os compradores de software agora têm três caminhos:
Primeiro, continue usando o sistema existente e adicione o Agente sobre ele.
Use-os por meio da CLI e da API do sistema existente, podendo utilizar os produtos de Agent nativos do fornecedor, como o Agentforce da Salesforce ou o Joule da SAP, ou construir seus próprios Agents sobre eles. Claro, aqui assume-se temporariamente que a API é completa e disponível, e ignora-se temporariamente a complexidade que a "headlessização" pode trazer na operação real.
Em segundo lugar, sistema de registro totalmente autoconstruído.
As empresas podem construir do zero seus próprios modelos de dados, lógicas operacionais, sistemas de permissões, rastreamento de auditoria e integração de sistemas, bem como sua própria pilha de Agentes. Esse caminho provavelmente utilizará ferramentas de desenvolvimento de Agentes e ferramentas de banco de dados de terceiros.
Terceiro, compre alternativas nativas de IA.
As empresas também podem adquirir novos softwares projetados desde o início para a era dos Agentes. Esses produtos enfatizam a legibilidade por máquinas, tratando o orquestramento de Agentes como uma capacidade principal, em vez de adicionar uma função de IA como um patch em sistemas antigos. Esses produtos também podem ser headless.
Quais elementos do antigo sistema de avaliação serão mantidos?
Fatores impulsionados por comportamentos e preferências humanas, como frequência de acesso e atributos de leitura e escrita bidirecionais, relacionados à memória muscular humana, tenderão a se enfraquecer. Agentes podem reduzir o valor da "memória muscular" como vantagem competitiva, mas não eliminarão as barreiras de entrada ligadas à lógica operacional e ao contexto de negócios. De certa forma, eles tornarão essas lógicas ainda mais importantes, pois os agentes precisam depender de regras, permissões e definições de processos claras para executar tarefas com segurança.
SOPs não documentadas ainda são importantes a curto prazo.
A lógica institucional incorporada nas regras de fluxo de trabalho internas é exatamente o que o Agente precisa para executar corretamente as tarefas em seu nome. Ao mesmo tempo, trata-se da parte mais difícil de reconstruir. Pelo menos por enquanto, ainda não é possível exportá-la limpa, especialmente quando partes dos processos ainda exigem intervenção humana. No entanto, capturar o contexto está se tornando cada vez mais fácil; à medida que os Agentes substituem mais trabalho humano, a importância desse fator diminuirá progressivamente.
A conectividade ainda é difícil de desfazer e se estenderá ainda mais profundamente.
O significado da conectividade está mudando. Não se trata mais apenas de apoiar o trabalho humano, mas de manter a conexão entre funções e softwares que tradicionalmente estavam separados.
Um agente de CRM precisa conectar os dados e o contexto de diferentes etapas, como vendas, faturamento e sucesso do cliente. Se a sua plataforma também se tornar um nó para transações entre várias organizações externas — por exemplo, compradores, vendedores e parceiros realizando interações por meio dela — as dependências serão ainda mais aprofundadas.
Ao adicionar Agentes a fabricantes existentes, pode ser difícil coordenar suavemente entre os objetos e lógicas básicas de diferentes softwares subjacentes; empresas que dependem apenas de um banco de dados próprio e um conjunto de Agentes também enfrentarão problemas semelhantes.
Os dados críticos de conformidade ainda são importantes.
Dados relacionados a agências reguladoras, riscos regulatórios ou riscos legais ainda exigem uma única fonte confiável de fatos. Se os clientes já confiam nos produtos existentes, a probabilidade de eles mudarem de sistema é menor.
Por exemplo, com dados de salários e contabilidade, o agente pode realmente precisar acessar esses dados, mas as empresas geralmente não têm probabilidade de escolher construir e manter a longo prazo tais sistemas internamente.
Num mundo totalmente agentizado, um dos problemas mais difíceis de resolver é: quais agentes estão autorizados a fazer o quê? Em nome de quem eles agem? Como essas ações são auditadas? Se um sistema de registro pudesse se tornar a camada de identidade e permissão para as interações entre agentes, ele adquiriria um papel estrutural verdadeiramente difícil de substituir. A barreira aqui não é apenas quais dados ele detém, mas qual arquitetura de confiança ele executa.
Olhando para frente, para empresas de startup nativas de IA, um novo conjunto de fatores se tornará cada vez mais importante e determinará sua capacidade de formar defesas.
Em primeiro lugar, quão difícil é reconstruir esse sistema de registros?
Os dados se tornarão ainda mais importantes em vários níveis.
Primeiro, a curto prazo, o foco está na facilidade de extrair e reconstruir os dados subjacentes do sistema de registro. A IA está tornando isso mais fácil, e uma série de ferramentas está ajudando os usuários a realizar esse tipo de migração e reconstrução.
No curto prazo, as empresas existentes podem e provavelmente tornarão isso mais difícil: podem tornar as APIs difíceis de usar, limitadas, incompletas ou economicamente inviáveis, ou até mesmo não fornecer APIs. Mas, à medida que as ferramentas de extração avançam, especialmente com o aumento da capacidade dos Agentes capazes de operar computadores, a reconstrução de dados se tornará cada vez mais fácil.
Ao mesmo tempo, a nova empresa também está reconstruindo um conjunto de dados mais rico a partir de e-mails, ligações, agentes de voz e documentos internos. A IA reduziu em 80% o custo de reconstrução de um sistema de registro. O que distingue uma entrada útil de um substituto verdadeiro são os últimos 20%: exceções, processos de aprovação, requisitos de conformidade e fluxos de trabalho em cenários limites.
Em segundo lugar, possui dados proprietários verdadeiramente significativos?
Em segundo lugar, os próprios dados se tornarão mais valiosos.
Os dados verdadeiramente defensivos não são os dados que você importa, mas sim os dados que seu produto cria de forma única. Falamos frequentemente em “jardins murados de dados”: esses dados são ou proprietários, ou sujeitos a restrições regulatórias, ou exigem atualizações contínuas. Um fornecedor de software que investe fortemente na coleta de dados autorizados e completos possui uma vantagem clara sobre fornecedores genéricos ou concorrentes que carecem desses dados.
Os dados também têm outra direção importante: se dependem de ações geradas internamente pelo produto.
As melhores empresas não apenas armazenam dados inseridos de fora. Elas geram continuamente novas pegadas de dados por estarem no meio do processo, como comportamentos observados, taxas de resposta, padrões de tempo, resultados de processos, benchmarks do setor, padrões anômalos e trajetórias de execução dos Agentes.
O ponto-chave é: os dados agora são o contexto.
Terceiro, você domina o nível de ação?
No mundo antigo, armazenar registros já era suficiente. Mas no novo mundo, os Agentes agirão diretamente, e a defesa poderá se voltar para produtos que formem um ciclo fechado: da ação à captura dos resultados e ao uso do feedback para otimizar decisões futuras.
Para o ERP, isso pode incluir aprovar despesas, acionar pagamentos de salários, conferir faturas, enviar notificações, entre outros. Produtos capazes de fechar o ciclo são mais defensivos, pois incorporam o processo de execução, e não se limitam à observação. Eles geram dados exclusivos que se aprimoram com o uso e tornam-se mais difíceis de substituir, pois sua remoção interromperia o fluxo de trabalho.
Of course, as more context is accumulated and edge cases are handled more thoroughly, the value here will continue to rise.
Quarto, inclui etapas de execução no mundo real?
Alguns modelos de negócio estão conectados às operações do mundo real, e esses elementos não são totalmente automatizados. O exemplo mais óbvio são empresas que operam redes, como a DoorDash. Historicamente, elas não pertenciam aos sistemas de registro, mas são muito esclarecedoras aqui.
Mais amplamente, qualquer empresa que consiga estender o ciclo fechado de software até os serviços, execução, logística, operações no local ou pagamentos possui uma defesa diferente daquela das empresas puramente SaaS. Essas empresas não apenas armazenam registros ou recomendam ações; elas enviam pessoas, movem mercadorias ou concluem serviços específicos.
Para empreendedores, isso significa que oportunidades podem surgir em mercados onde o software está cada vez mais capaz de tomar decisões e os agentes estão cada vez mais capazes de coordenar processos, mas a última milha ainda exige execução no mundo real. Por exemplo, software vertical vinculado a serviços presenciais é uma direção típica.
Quinto, existe efeito de rede?
Historicamente, a maioria dos sistemas de registro tinha efeitos de rede fracos, pois eram principalmente software interno. Mas na era dos Agentes, se um sistema incorporar fluxos de trabalho de múltiplas partes, os efeitos de rede podem se tornar muito mais significativos.
Se um sistema for responsável por mediar interações repetidas entre múltiplas partes, como compradores e vendedores, empregadores e funcionários, empresas e auditores, fornecedores e clientes, pagadores e prestadores de serviços, então cada nova parte adicionada pode tornar essa rede mais valiosa para a próxima parte a se juntar.
Uma das maneiras é a colaboração por meio de fluxos de trabalho: o produto se torna o local onde ambas as partes da operação realizam transações, trocam contexto e tratam exceções.
Outra abordagem é a referência e a inteligência: o sistema pode apresentar padrões da indústria, anomalias e recomendações de ação com base nos padrões observados na rede, reforçando mutuamente o valor dos dados mencionado anteriormente.
A terceira abordagem é confiança e padronização: assim que as partes envolvidas começarem a depender do mesmo conjunto de processos para aprovação, transferência, conformidade ou pagamento, o produto deixa de ser apenas um banco de dados e se torna a infraestrutura colaborativa do próprio mercado, tornando-se, portanto, mais difícil de substituir.
Sexto, quão forte é a capacidade técnica dos compradores?
Num mundo onde qualquer pessoa teoricamente pode construir seu próprio agente, as capacidades reais de construção dos diferentes compradores ainda variam enormemente. Especialmente em setores verticais e entre compradores funcionais que anteriormente não tinham recursos de engenharia interna robustos, a probabilidade de eles mesmos construírem, manterem e aprimorarem continuamente bancos de dados, lógicas de fluxo de trabalho, pilhas de agentes e camadas de governança ainda é baixa.
O custo é igualmente importante aqui. Embora o DIY teoricamente possa reduzir as taxas de licença de software, frequentemente transfere despesas para implementação, manutenção e complexidade interna.
Isso significa que ainda existem oportunidades reais em categorias com operações complexas, mas com oferta tecnológica insuficiente, como manufatura, backoffice da construção civil, processos industriais, fluxos de trabalho de serviço no local e contabilidade.
Outros fatores também são igualmente importantes e gradualmente se tornarão o padrão mínimo para software.
Por exemplo, a ontologia precisa mudar. Muitas ideias de “bancos de dados próprios” subestimam o valor intrínseco do modelo de objeto. O software existente foi construído para painéis, relatórios e usuários humanos, capturando objetos no fluxo de trabalho, como oportunidades de vendas, chamados e candidatos.
Mas o schema da era Agent precisa capturar raciocínio, ações, rastreamento de estado, tratamento de exceções, delegação de tarefas e colaboração entre sistemas. O modelo de objetos nativo pode não ser mais oportunidades, tickets e candidatos, mas sim tarefas, intenções, threads, estratégias ou resultados.
Da mesma forma, o sistema de permissões também precisa ser atualizado. Ele não gerencia mais apenas usuários humanos, mas também Agents. Isso inclui: quem pode fazer o quê, por meio de qual Agent, sob qual estratégia, quais aprovações são necessárias, que rastros de auditoria devem ser deixados e como realizar rollback e tratamento de exceções.
Claro, tudo isso depende dos custos, como quanto custa construir e manter Agentes e bancos de dados, e qual é o custo de acesso às APIs. Isso nos leva de volta a algumas questões centrais: quão difícil é reconstruir os dados, quantas dependências existem e quão profundamente o sistema está integrado.
Então, qual é a conclusão?
À medida que os fornecedores de software existentes adotam o modelo headless, eles estão na verdade fazendo uma aposta implícita: que a camada de dados continuará sendo a principal fonte de valor. Em certas categorias, especialmente aquelas como serviços financeiros, fortemente reguladas, essa aposta pode ainda ser válida por algum tempo, e o processo de headless pode ocorrer mais lentamente.
Mas para empreendedores de software, à medida que fabricantes estabelecidos começam a eliminar interfaces, a forma de competir com eles e de construir software com defesa de longo prazo está mudando.
O próximo sistema de registro já está assumindo formas diferentes: não são mais apenas repositórios de dados para registrar o trabalho humano, mas possuem atributos de Agentes — capazes de capturar contexto, iniciar trabalho ativamente e registrar rastros de dados gerados durante a execução.
Ainda mais longe, as empresas mais interessantes se estenderão até o nível de execução no mundo real: elas coordenarão equipes de campo, prestadores de logística, equipes de serviço e ativos físicos, ou atuarão entre múltiplas partes como uma camada intermediária de colaboração múltipla.
Essas empresas combinarão diversos modelos de negócios do mundo tradicional. E o núcleo dos sistemas de registro tradicionais — os dados — gradualmente recuará para o plano de fundo, tornando-se a base subjacente que sustenta todo o sistema.
Clique para saber mais sobre as vagas em aberto na BlockBeats
Bem-vindo ao grupo oficial da BlockBeats:
Grupo de assinatura no Telegram: https://t.me/theblockbeats
Grupo de Telegram: https://t.me/BlockBeats_App
Conta oficial no Twitter: https://twitter.com/BlockBeatsAsia