Atenção: Este conteúdo foi traduzido automaticamente. Enviar feedback

Usuário Headless

15 min read

ai, agents, enterprise-software, labor-markets, principal-agent, verification, salesforce

Quando o principal usuário de software empresarial passa a ser um agente de IA, o framework principal-agente de 1976 de Jensen e Meckling deixa de ser metáfora. A classe verificadora que surge do outro lado é a próxima anomalia de precificação do mercado de trabalho.

De usuário-como-pessoa a usuário-como-agente: a redesignação que está remodelando software e trabalho

Em meados de abril de 2026, a Salesforce anunciou o Headless 360 no TDX: uma reestruturação da plataforma em torno de APIs, ferramentas de Model Context Protocol e interfaces de linha de comando (Salesforce; VentureBeat). O lançamento não foi um refresh de UX. Foi o reconhecimento de que o principal usuário de software empresarial já não é um ser humano.

A escolha das palavras importa. Uma década de ortodoxia do design transformou "usuário" em sinônimo de "pessoa". As personas tinham nome, foto, objetivos; os design sprints começavam com mapas de empatia; wireframes imaginavam os olhos de alguém percorrendo uma tela. O Headless 360 não refina essa ortodoxia. Ele a desmonta. O navegador vira uma superfície legada. A visualização em planilha passa a ser uma entre muitas saídas, não a saída. A tela é opcional.

A imprensa especializada leu essa mudança com a mesma clareza que a Salesforce. A VentureBeat descreveu o lançamento como infraestrutura para agentes de IA, enquanto a PPC.land o enquadrou como um movimento que remove o navegador como interface obrigatória (VentureBeat; PPC.land). A Salesforce disse que o lançamento incluía mais de sessenta MCP tools e mais de trinta coding skills, além de um conjunto mais amplo de superfícies voltadas para agentes (Salesforce). Essa é a escala de uma virada de plataforma, não de um lançamento de produto.

A mudança também é visível em outras partes da camada de tooling. A The New Stack observou neste mês que Cursor, Claude Code e o Codex da OpenAI estavam se fundindo em "uma única stack de AI coding que ninguém planejou" (The New Stack). Plataformas adjacentes também estão adicionando suas próprias camadas de construção de agentes, como deixa claro a documentação do Rovo, da Atlassian (Atlassian). Cada um desses produtos pressupõe um operador capaz de ler, editar e confiar em artefatos gerados sem examiná-los linha por linha. O artefato já não é o dashboard. O artefato é o comportamento.

O que está acontecendo não é um passo adiante em user experience. É uma redesignação de quem é o usuário. Por três décadas, o software empresarial tratou o humano como principal: a entidade cuja atenção, aprovação e erro formavam o loop de feedback do sistema. O humano clicava; o software respondia. O loop era curto porque a latência entre intenção e input era baixa. As empresas de software otimizaram cada centímetro disso: formulários mais rápidos, menos cliques, dashboards mais bonitos.

Esse loop está se rompendo. Não porque o humano esteja sendo eliminado. O humano continua sendo a fonte da intenção, o dono da conta, quem paga a conta. Mas o humano já não é a entidade no console. Outra coisa ocupa esse lugar. Ela digita. Ela faz chamadas de API. Ela opera o software.

Chamar essa coisa de "usuário" força a palavra. Mais precisamente, trata-se de um agente operando em nome de um usuário. E é na distância entre os dois, entre principal e agente, que o novo terreno se abre.

A interface que desaparece

Essa trajetória já vinha sendo preparada havia muito tempo. Na Lenny's Newsletter, Marc Andreessen descreveu a linguagem natural como a próxima camada de abstração acima das linguagens de mais alto nível, depois que o código de máquina e o assembly deram lugar a C e Python (Lenny's Newsletter). Andrej Karpathy, ex-Tesla e OpenAI, formalizou o movimento mais recente com sua taxonomia Software 1.0, 2.0 e 3.0, na qual prompts em inglês viram uma forma de programar LLMs (Y Combinator podcast). Cada camada tornou o computador acessível a uma população mais ampla e tornou obsoleta outra, mais estreita.

Guillermo Rauch, fundador da Vercel, colocou a implicação em termos duros no mesmo podcast: muitos trabalhos de programação que antes eram especializados estão virando tarefas de tradução, especialmente da intenção ou do design para a implementação (Lenny's Newsletter). Tradução, de design para código, de política para configuração, de especificação para schema, foi a camada intermediária do trabalho white-collar em software por duas gerações. A tese de Rauch não é que programar desaparece. É que os tradutores desaparecem.

O Headless 360 é a versão enterprise do mesmo movimento, e não é um caso isolado. Na mesma janela, Oracle, SAP, Workday, e ServiceNow lançaram movimentos paralelos de plataforma para agentes. O navegador era uma camada de tradução: intenção humana expressa por cliques em formulários que escreviam em tabelas por meio de middleware que chamava APIs. Remova o navegador e a cadeia se contrai: a intenção vira chamada de API, com o agente fazendo a tradução. O administrador que sabia clicar por dezessete telas para configurar uma regra de compliance perde o fosso competitivo que as telas forneciam. O especialista de operações que memorizou a ordem dos checkboxes também. O instrutor que ensinava o click path para novos contratados também.

O que substitui esses fossos? Não novos fossos na mesma camada. A própria camada está se dissolvendo. Em seu lugar aparece um conjunto diferente de artefatos (o system prompt, o schema da ferramenta, o harness de avaliação) e um conjunto diferente de profissionais que os produzem. Anthropic, OpenAI e Salesforce estão, cada uma à sua maneira, lançando os componentes básicos dessa camada substituta (Anthropic MCP docs; OpenAI function calling; Salesforce).

A parte contraintuitiva de uma interface que desaparece é que o trabalho não desaparece com ela. O trabalho se desloca. Alguém ainda precisa decidir o que uma regra de compliance significa, quais exceções são aceitáveis e o que deve acontecer quando a proposta do agente encosta no limite da política. Essa pessoa já não está clicando. Cada vez mais, ela está revisando.

A pergunta é como chamá-la.

O problema principal-agente, em versão máquina

A literatura econômica tem um framework de cinquenta anos para exatamente esse tipo de situação. Em 1973, Stephen Ross publicou um artigo apresentando o que chamou de problema do principal: uma situação em que uma parte delega uma ação a outra e o agente detém informação privada que o principal não consegue observar por completo (Ross 1973). Três anos depois, Michael Jensen e William Meckling formalizaram o framework em Theory of the Firm: Managerial Behavior, Agency Costs and Ownership Structure, definindo custos de agência como a soma dos gastos de monitoramento do principal, dos gastos de bonding do agente e da perda residual (Jensen and Meckling 1976). A distância entre o que o principal queria e o que o agente entregou é toda a lógica do framework.

Por meio século, o framework foi aplicado a agentes humanos. Acionistas delegavam a executivos. Clientes delegavam a advogados. Pacientes delegavam a médicos. Cada elaboração da teoria (remuneração atrelada a performance, dever fiduciário, comitês de auditoria, regras de independência de conselho) era uma tentativa de reduzir a perda residual ao remodelar o monitoramento.

Em 2026, o framework se aplica com uma literalidade incomum. Software não tem interesse próprio nem dever fiduciário, então a analogia não é perfeita, mas os pressupostos estruturais atravessam bem o suficiente para que as categorias de custo se encaixem sem muito esforço. Dois artigos recentes de management, Humberd and Latham (2026), no Journal of Management Studies, e Jarrahi and Ritala (2025), na California Management Review, fazem o mesmo movimento de forma independente: tratam a IA como um novo tipo de agente dentro da firma e perguntam como ficam o monitoramento e o bonding quando o agente é software.

Informação privada, no framework original, era o conhecimento superior do agente sobre condições que o principal não conseguia observar. Na versão máquina, a informação privada é o raciocínio interno do modelo: a cadeia de ativações que produziu a saída, e que não pode ser inspecionada pela superfície da API. Divergência de interesses, no original, era o agente perseguindo ganho pessoal às custas do principal. Na versão máquina, é o objetivo de treinamento divergindo da intenção do usuário: o modelo otimiza plausibilidade em vez de correção, aparência de utilidade em vez de substância. Custo de monitoramento, no original, era o preço de auditar as ações do agente. Na versão máquina, é o custo de verificar outputs de modelo em escala de produção, um custo que cresce com o volume de saída, não com a importância da tarefa. Perda residual, no original, era o delta entre o resultado pretendido e o realizado. Na versão máquina, é alucinação, deriva de escopo, falha silenciosa: a taxonomia inteira de erros que um principal talvez nunca detecte.

A teoria antecipou cada dinâmica que as equipes de deploy de agentes estão redescobrindo agora. O que ela não antecipou foi a escala. Um advogado humano produz um documento por vez. Um executivo humano toma uma decisão por vez. Monitorar esse volume é caro, mas limitado. Um agente de software produz documentos, decisões e efeitos colaterais em um ritmo que nenhum principal consegue supervisionar por padrão. O custo de monitoramento, no framework clássico, era uma questão de diligência. Na edição das máquinas, é uma questão de capacidade.

Essa capacidade, quando existe, está concentrada em um grupo pequeno e sem nome. Eles são o gargalo. São, embora ninguém tenha dito isso ainda, uma classe.

A classe verificadora

Alexander Embiricos, da equipe do Codex da OpenAI, descreveu o gargalo atual como validação humana e code review, e não geração bruta de código (Lenny's Newsletter). Embiricos estava descrevendo um workflow específico (agentes de coding assíncronos que iniciam o trabalho, produzem mudanças e devolvem tudo para aprovação), mas o diagnóstico se generaliza. Em diferentes domínios, o passo que determina se a saída de um agente entra em produção é o crivo humano que vem depois.

Esse crivo é mais difícil do que parece. Hamel Husain e Shreya Shankar, pesquisadores de AI evals, argumentaram que os critérios de avaliação mudam à medida que as pessoas inspecionam mais saídas, o que significa que a rubrica não pode ser totalmente fixada de antemão (Lenny's Newsletter). O verificador não está apenas comparando o trabalho do agente com uma especificação; ele está construindo a especificação em tempo real, em resposta à distribuição de saídas que o agente realmente produz. Avaliar, nesse regime, não é uma questão de aplicar uma test suite. É uma questão de inventar uma sob pressão.

Na prática, isso se parece com um piso de defeitos que o gerador introduz de forma confiável e um teto de capacidade de revisão que o verificador consegue fornecer com consistência, com a lacuna entre os dois crescendo à medida que o uso escala. O piso é mensurável: a atualização de primavera de 2026 da Veracode constatou que 55 por cento das tarefas testadas de geração de código por IA eram seguras, implicando uma taxa aproximada de 45 por cento de falhas de segurança conhecidas no conjunto avaliado (Veracode). Uma discussão da Y Combinator sobre sua turma W25, reportada pela TechCrunch, disse que cerca de um quarto da turma tinha codebases 95 por cento geradas por IA (TechCrunch). Geração em alto volume encontrando produção pouco auditada não é previsão; já é rotina.

Nada disso é exclusivo de código. O padrão se repete na revisão jurídica, na documentação médica, na análise financeira, no copy de marketing. Em cada domínio, o agente produz em volume; um humano checa; quem checa é a restrição. O detalhe específico de cada área muda. O formato da função, não.

Essa função não tem título. Não tem carreira estruturada. Não aparece em organogramas. Hoje, ela é ocupada pelas pessoas que por acaso estão por perto: o engenheiro sênior que deveria estar escrevendo features, a staff lawyer que deveria estar aconselhando clientes, a lead designer que deveria estar criando. O cargo explícito delas é outra coisa. O trabalho real é revisar o que um agente produziu e decidir se aquilo vai para produção.

Eles são a Classe Verificadora. O nome é novo; a função, não. Mas as condições são.

O que distingue um verificador de um revisor, editor, auditor ou aprovador não é o ato de revisar. É a coocorrência de três condições.

A fila a montante não tem teto: a saída é produzida por um sistema cujo throughput escala com gasto em API, não com as horas de trabalho de outro humano. O throughput do próprio verificador não: ele é limitado pela largura de banda cognitiva humana e não escala com a mesma alavanca. A rubrica é emergente: como descrevem Husain e Shankar, ela precisa se formar em resposta à distribuição de saídas que o sistema realmente produz, e não ser definida de antemão.

Editores e auditores atendem uma ou duas dessas condições. O verificador atende às três ao mesmo tempo. Esse é o coração econômico da função.

A questão distributiva

A narrativa dominante sobre o efeito da IA no trabalho se concentrou em deslocamento: sistemas generativos comprimiriam o meio da distribuição de habilidades, tornando trabalhadores do conhecimento de nível intermediário redundantes, enquanto concentram ganhos nos donos do capital e no talento de fronteira. Essa narrativa assume o caso sem fricção: um agente que coloca sua própria saída em produção sem revisão.

A verificação muda o formato. Diferentemente da geração, a verificação é intensiva em domínio. Um agente de propósito geral pode redigir um pedido de patente, um laudo radiológico, um release de resultados trimestrais e uma aprovação de crédito. O verificador de cada um precisa possuir o conhecimento de domínio de um advogado de patentes, um radiologista, um controller e um analista de crédito, respectivamente. Esse conhecimento não é transferível. Não se sintetiza rápido. É adquirido ao longo de anos de treinamento específico em um contexto específico, e é a parte mais difícil de terceirizar.

A consequência contraintuitiva é que a verificação pode relocalizar certos tipos de expertise. Nas décadas anteriores, o offshoring dependia de a execução ser desacoplada do contexto: a especificação era escrita uma vez, no país de origem, e executada muitas vezes, no exterior. A verificação não pode ser desacoplada. Cada saída exige um novo julgamento. Cada julgamento exige o contexto que o agente não forneceu.

O State of the Designer 2026 da Figma, uma pesquisa com 906 designers digitais conduzida com a NewtonX, documentou uma reconfiguração acentuada da própria função (Figma report; Figma blog). O trabalho de execução (produção de mockups, wireframes, prototypes) despencou em custo, enquanto o trabalho de julgamento (seleção, curadoria e direção editorial das opções geradas) se tornou o gargalo que os respondentes descrevem. Em um post separado com foco em contratação, a Figma argumentou que a IA está aumentando a demanda por designers, especialmente por contratações sêniores com julgamento e experiência mais fortes (Figma hiring post). As duas afirmações operam em níveis diferentes. Uma é o que os designers relatam sobre o próprio trabalho; a outra é como a Figma interpreta isso para seus clientes enterprise. Ambas apontam na mesma direção. O cargo não mudou. O trabalho mudou.

Na entrevista de fevereiro de 2026 de Lenny Rachitsky, Lazar Jovanovic, da Lovable, enquadrou a habilidade substituta como clareza, repertório, julgamento e melhor tomada de decisão, e não velocidade bruta de coding (Lenny's Newsletter). Clareza, nesse contexto, é a capacidade de especificar uma intenção que o agente não consiga interpretar errado e de reconhecer quando ele interpretou errado. É o mesmo movimento cognitivo que a verificação exige, só descrito a partir da direção oposta.

Essas observações apontam numa direção. O mercado de trabalho não está se achatando rumo a uma elite estreita de fronteira. Ele está se estratificando ao longo de um novo eixo (gerador versus verificador) que atravessa funções já existentes. A posição de maior vantagem é a do verificador em um domínio que importa, com o contexto que não pode ser facilmente roteirizado e o julgamento que não pode ser facilmente automatizado. A remuneração vai acompanhar isso. E a fricção de contratação também: o número de pessoas capazes de gerar em escala está explodindo; o número de pessoas capazes de verificar em escala, não.

Essa assimetria é a próxima anomalia de precificação do mercado de trabalho.

As duas interfaces

Todo produto de software construído nos próximos cinco anos carregará duas interfaces, quer seus designers as nomeiem, quer não.

A primeira é a interface de protocolo: a superfície por meio da qual agentes operam o sistema. Seus primitivos são o endpoint de API, a definição da MCP tool, o comando de CLI, o escopo de permissão, o rate limit. Sua disciplina de design é legibilidade para um modelo: naming que resiste à ambiguidade, schemas que falham para o lado seguro, documentação densa o suficiente para retrieval, mas estruturada o suficiente para tool selection. O Headless 360 da Salesforce é uma das primeiras declarações públicas do que essa interface parece em escala enterprise, enquanto o Model Context Protocol da Anthropic e as especificações de tool use da OpenAI fazem parte da infraestrutura do ecossistema ao redor dela (Salesforce; Anthropic MCP docs; OpenAI function calling).

A segunda é a interface de julgamento: a superfície por meio da qual um verificador revisa, aprova, corrige ou rejeita o que o agente fez. Seus primitivos são o diff, o rollback, o trace, a cadeia de atribuição, a fila de aprovação. Sua disciplina de design não é legibilidade para um modelo, mas legibilidade para um especialista de domínio operando sob pressão de tempo. O que aconteceu. Por quê. O que muda se isso permanecer. O que quebra se isso for revertido. Uma interface de julgamento bem desenhada permite que um especialista de domínio confirme rapidamente uma saída assistida por IA; uma interface ruim o força a refazer o trabalho manualmente e apaga o ganho de eficiência que o agente deveria entregar.

Hoje, a maioria das empresas está construindo a primeira interface com agressividade e a segunda quase não está sendo construída. A superfície de protocolo recebe roadmap, equipe dedicada e atenção em nível de conselho. A superfície de julgamento recebe um admin panel adaptado às pressas, um CSV export ou, cada vez mais, nada, sob a premissa de que o agente é "good enough" para ir à produção sem revisão. Todo verificador que hoje trabalha a partir de um sistema de tickets desmente essa premissa.

Uma previsão testável: até o fim de 2028, espero que a maioria dos principais fornecedores de software enterprise lance uma interface de julgamento nomeada e de primeira classe. A força motriz será procurement, não teoria da agência. À medida que os primeiros contratos da era dos agentes entrarem em renovação, será difícil responder à pergunta do burnout dos verificadores sem uma superfície dedicada.

A mudança mais profunda é mais antiga do que qualquer uma dessas tecnologias. O framework de 1976 de Jensen e Meckling sai dos departamentos de economia e entra nos roadmaps de produto. Os custos de monitoramento que eles modelaram viram itens de orçamento de UX. A perda residual que eles nomearam vira métrica trimestral. A teoria da agência, por cinco décadas a linguagem da governança corporativa, passa a ser a linguagem do design de software.

Quando o usuário é um agente, o cliente é um verificador. A distinção não é retórica. Ela é o formato da próxima década de software empresarial, e do mercado de trabalho que o sustenta. Os produtos e as carreiras que entenderem isso vão acumular vantagem. Os demais continuarão otimizando para um principal que já saiu da tela.

Sources