O próximo usuário de ERP pode não ser humano

Cada tela é um palpite sobre quem está olhando

Considere o que é um ERP do lado de seu usuário. Por trás da marca, é um conjunto de tabelas e regras: clientes, itens, pedidos, faturas, movimentações de estoque e as restrições que as mantêm consistentes. À frente disso está a parte em que a maior parte do dinheiro foi gasto: várias mil telas que apresentam essas tabelas a uma pessoa, alguns campos de cada vez, em uma ordem que uma pessoa pode seguir, com rótulos que uma pessoa pode ler e botões que uma pessoa pode encontrar.

Cada uma dessas telas codifica uma suposição sobre quem está do outro lado. A suposição é de uma pessoa com uma memória de trabalho limitada, então o formulário é dividido em abas. Uma pessoa que lê da esquerda para a direita, então o campo importante vai para o canto superior esquerdo. Uma pessoa que pode manter aproximadamente sete coisas em mente, então o painel tem seis blocos. Uma pessoa que cometerá erros de digitação, então há validação ao enviar. Uma pessoa que se cansa, então o caminho comum tem menos cliques. Tudo isso é um bom design para o usuário que o designer tinha, e por quatro décadas esse usuário foi o único que existiu.

A consequência é que a interface é uma representação com perda do modelo de dados para um tipo de leitor. O modelo sabe que uma fatura tem linhas, um cliente, uma data de vencimento e um status; a tela mostra as linhas em uma aba, o cliente em outra e o status como uma cor. O trabalho que toca cinco registros significa cinco telas, e a pessoa carrega o fio entre elas em sua cabeça. Esse fio é a maior parte do que uma empresa paga sua equipe administrativa para manter.

O novo usuário tem ferramentas, não mãos

Um agente de IA operando um sistema de negócios não recebe nada disso. O que ele recebe, quando se conecta através do Model Context Protocol, é o resultado de uma solicitação para listar ferramentas: para cada uma, um nome, uma descrição escrita para um modelo ler, um esquema para suas entradas e, opcionalmente, uma anotação dizendo se a ferramenta apenas lê, se pode destruir algo e se chamá-la duas vezes é seguro. O agente escolhe uma ferramenta, a chama com argumentos digitados, lê o resultado e escolhe novamente. O resumo do protocolo é que é uma maneira padronizada de conectar aplicações de IA a sistemas externos, da mesma forma que uma porta comum conecta dispositivos, e os principais clientes agora falam isso: Claude, ChatGPT, Cursor e VS Code entre eles.

Veja o que esse usuário não precisa. Ele não precisa da fatura dividida em abas, porque pode manter todo o registro de uma vez. Ele não precisa do campo importante no canto superior esquerdo, porque não há esquerda. Ele não precisa de seis blocos, porque pode pedir o número que deseja. Ele não se cansa, e não há cliques. Cada concessão que tornou a tela boa para uma pessoa é, para esse usuário, irrelevante ou um obstáculo.

E veja o que ele precisa em vez disso, que a tela nunca forneceu. Ele precisa que a descrição de cada ação seja precisa, porque a descrição é toda a sua compreensão. Ele precisa que o esquema seja completo, porque não pode ver um exemplo. Ele precisa saber quais ações são seguras para tentar novamente. Ele precisa que o resultado diga o que aconteceu e o que pode fazer a seguir. Para este usuário, a documentação é a interface, e nomear é design: uma ferramenta ampla com uma descrição de duas linhas é um produto pior do que a mesma capacidade como três ferramentas com nomes simples e descrições honestas, independentemente de como as telas acima delas se parecem.

O desvio pela tela não vai durar

A primeira resposta a um novo usuário é sempre tratá-lo como o antigo. A automação de processos robóticos fez isso por uma década: um bot faz login com uma conta de serviço e navega pelas telas como se tivesse mãos, encontrando o botão pelo seu seletor ou suas coordenadas. A versão atual dá a um modelo de linguagem uma captura de tela e um cursor. O uso do computador da Anthropic faz exatamente isso, e sua documentação é cuidadosa ao dizer onde ele se encaixa: ele existe para os casos em que nenhuma interface mais restrita está disponível, direciona você para uma ferramenta de navegador quando o trabalho permanece dentro de uma página e pede que uma pessoa confirme qualquer coisa com consequências reais significativas, incluindo transações financeiras.

O custo é alto para usar. Uma tela não faz promessas a uma máquina, então cada mudança feita para a pessoa quebra a automação que finge ser uma. Cada camada entre o agente e a ação, a captura de tela, a suposição de qual pixel é o botão, o texto digitado que pode ou não ter caído no campo certo, é um lugar para errar, e um modelo já é um lugar para errar. A direção por tela é a ponte que você constrói enquanto o sistema por baixo não tem nada melhor, e os fornecedores dos bots dizem isso por si mesmos: agora eles descrevem o robô como uma camada de execução que um agente chama para os sistemas que ainda precisam dela.

O que o software precisa se tornar

Se o argumento até agora se sustenta, a forma do software nativo de agente decorre disso, e é mais do que uma API auxiliar. Cinco propriedades precisam ser verdadeiras ao mesmo tempo.

• Toda ação é uma ferramenta. Não a dúzia que o fornecedor achava segura, mas toda a superfície que uma pessoa pode alcançar através das telas: criar, ler, mover, aprovar, enviar, reconciliar. Qualquer coisa a menos, e o agente terá que recorrer à tela pelo resto.
• Cada chamada carrega uma identidade. O agente atua como uma pessoa específica, através de um login normal, e as ferramentas que lhe são oferecidas são filtradas pelo papel dessa pessoa antes que ele as veja e verificadas novamente quando são executadas. Um agente com acesso total ao sistema é uma falha de design, não uma funcionalidade.
• Ele pergunta por design. Algumas ações são executadas; algumas aguardam uma pessoa; algumas são recusadas imediatamente. O protocolo em si diz que deve haver sempre um humano no processo capaz de negar uma chamada de ferramenta, e os principais clientes perguntam antes de uma gravação por padrão. O software deve tornar as categorias explícitas em vez de esperar que o modelo seja educado.
• Os gastos têm um limite. Onde o raciocínio do sistema custa dinheiro, ou onde uma ferramenta compromete dinheiro, há um limite por conexão que o sistema impõe e o modelo não pode contornar.
• O registro é o produto. Cada chamada, seus inputs e seu resultado, sob a identidade que a fez, revisável da mesma forma que as ações de uma pessoa. Para um agente, o histórico de auditoria é como a confiança é construída, uma semana de cada vez.

Uma sexta propriedade é menos uma exigência do que uma consequência. Quando o trabalho é feito por meio de ferramentas, o registro é mantido como um subproduto: o agente que fatura, cobra e reconcilia deixa exatamente a fatura, a cobrança e a reconciliação que uma pessoa teria digitado, sem a digitação. As telas sobrevivem, para olhar, revisar e decidir. Elas deixam de ser o único lugar onde o trabalho pode acontecer.

A objeção que vale a pena levar a sério

A objeção mais forte concede que os agentes podem fazer o trabalho e aponta que às vezes eles o fazem errado, com confiança, em uma escrita. Isso é verdade, e a documentação honesta diz isso: o ChatGPT trata qualquer ferramenta sem uma anotação de somente leitura como uma escrita e requer confirmação por padrão; o Claude pede aprovação antes de invocar uma ferramenta de um conector personalizado e avisa que um servidor malicioso pode carregar instruções ocultas. Os clientes têm razão em ser cautelosos, e uma empresa também deve ser.

Mas note onde a cautela deve residir. Ela não pode residir no modelo, que é a parte que pode estar errada. Ela deve residir no software, que é exatamente onde um bom software já a colocou para os usuários humanos. Validação, permissões, limites de aprovação, desfazer, auditoria: cada um desses existe porque o usuário anterior também cometeu erros, com confiança, em uma escrita. O software nativo de agente leva essa antiga disciplina a sério em cada ação, em vez de apenas nas poucas que o designer da tela se lembrou, e a aplica a um usuário que chamará cem ferramentas antes do almoço.

Uma segunda objeção é o determinismo. Alguns trabalhos devem produzir a mesma saída para a mesma entrada, comprovadamente, toda vez. Esse trabalho deve permanecer um fluxo de trabalho fixo, e o agente deve chamar o fluxo de trabalho como uma ferramenta em vez de improvisá-lo. O julgamento não substitui as regras aqui; o sistema precisa de ambos, expostos a um usuário que pode diferenciá-los.

Quem constrói e para quem

A última consequência é a que o empreendedor deve notar. Se o usuário do software pode ser um agente, o construtor também pode. Um desenvolvedor descreve o aplicativo que deseja a um agente que já possui, o agente o constrói com um conjunto de ferramentas de construção, o desenvolvedor o valida localmente e o publica, e desde o primeiro dia, cada ferramenta que o aplicativo entrega está disponível para cada outro agente na plataforma. A empresa que o instala não aprende suas telas; sua equipe traz o agente que já usa e descreve o resultado. Essa é a estrutura em torno da qual o Sois é construído, oferecida aqui como uma implementação do argumento em vez de como sua conclusão.

A conclusão é mais simples. Durante quarenta anos, a pergunta que um designer de software fazia era o que a pessoa do outro lado precisa ver. O próximo usuário não vê. Ele lê um contrato e chama o que está autorizado a chamar, e fará isso em nome das mesmas pessoas para as quais as telas foram construídas. O software que trata esse usuário como um cidadão de primeira classe será operado fluentemente. O software que mantém a tela como sua única porta ainda será operado, através de uma fechadura, por um agente vestindo uma fantasia, até que seus proprietários se cansem da fantasia e se movam.

Este artigo é revisado quando os produtos que descreve mudam. Próxima revisão agendada: 4 de dezembro de 2026.