O próximo utilizador de ERP pode não ser humano

Cada ecrã é um palpite sobre quem está a olhar.

Considere o que é um ERP do lado do seu utilizador. Por trás da marca, é um conjunto de tabelas e regras: clientes, itens, encomendas, faturas, movimentos de stock e as restrições que as mantêm consistentes. À frente disso está a parte em que a maior parte do dinheiro foi gasto: vários milhares de ecrãs que apresentam essas tabelas a uma pessoa, alguns campos de cada vez, numa ordem que uma pessoa pode seguir, com rótulos que uma pessoa pode ler e botões que uma pessoa pode encontrar.

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

A consequência é que a interface é uma representação com perdas 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 estado; o ecrã mostra as linhas num separador, o cliente em outro, e o estado como uma cor. O trabalho que toca cinco registos significa cinco ecrãs, e a pessoa transporta o fio entre eles na sua cabeça. Esse fio é a maior parte do que uma empresa paga ao seu pessoal administrativo para manter.

O novo utilizador tem ferramentas, não mãos

Um agente de IA a operar um sistema empresarial não recebe nada disso. O que recebe, quando se conecta através do Model Context Protocol, é o resultado de um pedido para listar ferramentas: para cada uma, um nome, uma descrição escrita para um modelo ler, um esquema para as 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, chama-a com argumentos digitados, lê o resultado e escolhe novamente. O resumo do protocolo é que é uma forma 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 este utilizador não precisa. Não precisa da fatura dividida em separadores, porque pode manter o registo inteiro de uma vez. Não precisa do campo importante no canto superior esquerdo, porque não há esquerda. Não precisa de seis blocos, porque pode pedir o número que deseja. Não se cansa, e não há cliques. Cada concessão que tornou o ecrã bom para uma pessoa é, para este utilizador, irrelevante ou um obstáculo.

E veja o que precisa em vez disso, que o ecrã nunca forneceu. Precisa que a descrição de cada ação seja precisa, porque a descrição é a totalidade da sua compreensão. Precisa que o esquema seja completo, porque não consegue ver um exemplo. Precisa de saber quais ações são seguras para repetir. Precisa que o resultado diga o que aconteceu e o que pode fazer a seguir. Para este utilizador, a documentação é a interface, e a nomeação é 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 os ecrãs acima delas parecem.

O desvio pelo ecrã não vai durar

A primeira resposta a um novo utilizador é sempre vestir-se como o antigo. A automação de processos robóticos fez isso durante uma década: um bot inicia sessão com uma conta de serviço e controla os ecrãs como se tivesse mãos, encontrando o botão pelo seu seletor ou pelas suas coordenadas. A versão atual dá a um modelo de linguagem uma captura de ecrã e um cursor. O uso de computador da Anthropic faz exatamente isso, e a sua documentação é cuidadosa ao dizer onde pertence: existe para os casos em que não há uma interface mais restrita disponível, orienta-o para uma ferramenta de navegador quando o trabalho permanece dentro de uma página, e pede a uma pessoa para confirmar qualquer coisa com consequências reais significativas, incluindo transações financeiras.

O fato é caro de usar. Um ecrã não faz promessas a uma máquina, por isso cada alteração feita para a pessoa quebra a automação que finge ser uma. Cada camada entre o agente e a ação, o screenshot, a suposição sobre qual pixel é o botão, o texto digitado que pode ou não ter caído no campo certo, é um lugar para estar errado, e um modelo já é um lugar para estar errado. A condução por ecrã é a ponte que constróis enquanto o sistema por baixo não tem nada melhor, e os fornecedores dos bots dizem isso eles próprios: agora descrevem o robô como uma camada de execução que um agente chama para os sistemas que ainda precisam dela.

O que o software tem de se tornar

Se o argumento até agora se mantiver, a forma do software nativo de agente decorre disso, e é mais do que uma API à parte. Cinco propriedades têm de ser verdadeiras ao mesmo tempo.

• Cada ação é uma ferramenta. Não as dúzias que o fornecedor pensava serem seguras, mas toda a superfície que uma pessoa pode alcançar através dos ecrãs: criar, ler, mover, aprovar, enviar, reconciliar. Qualquer coisa menos, e o agente tem de recorrer ao ecrã pelo resto.
• Cada chamada transporta uma identidade. O agente atua como uma pessoa específica, através de um acesso normal, e as ferramentas que lhe são oferecidas são filtradas pelo papel dessa pessoa antes de as ver e verificadas novamente quando são utilizadas. Um agente com acesso total ao sistema é uma falha de design, não uma funcionalidade.
• Pede por design. Algumas ações são executadas; algumas aguardam por uma pessoa; algumas são recusadas de imediato. 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 escrita por padrão. O software tem de tornar as categorias explícitas em vez de esperar que o modelo seja educado.
• O gasto tem 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 registo é o produto. Cada chamada, os seus inputs e o seu resultado, sob a identidade que a fez, é revisável da mesma forma que as ações de uma pessoa. Para um agente, o rasto de auditoria é como a confiança é construída, uma semana de cada vez.

Uma sexta propriedade é menos um requisito do que uma consequência. Quando o trabalho é feito através de ferramentas, o registo é mantido como um subproduto: o agente que fatura, persegue e reconcilia deixa exatamente a fatura, o perseguidor e a reconciliação que uma pessoa teria digitado, sem a digitação. Os ecrãs sobrevivem, para olhar, rever e decidir. Eles 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 o fazem de forma errada, com confiança, numa escrita. Isso é verdade, e a documentação honesta diz isso: o ChatGPT trata qualquer ferramenta sem uma anotação de só 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 conter instruções ocultas. Os clientes têm razão em ser cautelosos, e uma empresa também deve ser.

Mas repare onde a cautela deve residir. Não pode residir no modelo, que é a parte que pode estar errada. Tem de residir no software, que é exatamente onde o bom software já a colocou para os utilizadores humanos. Validação, permissões, limiares de aprovação, desfazer, auditoria: cada um desses existe porque o utilizador anterior também cometeu erros, com confiança, numa escrita. O software nativo de agente leva essa antiga disciplina a sério em cada ação, em vez de nas poucas que o designer de ecrã se lembrou, e aplica-a a um utilizador que chamará a 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, todas as vezes. 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 regras aqui; o sistema precisa de ambos, expostos a um utilizador que os possa distinguir.

Quem o constrói, e para quem

A última consequência é aquela que o empreendedor deve notar. Se o utilizador do software pode ser um agente, o construtor também pode. Um desenvolvedor descreve a aplicação que deseja a um agente que já tem, o agente constrói-a com um conjunto de ferramentas de construção, o desenvolvedor valida-a localmente e publica-a, e desde o primeiro dia cada ferramenta que a aplicação disponibiliza está disponível para cada outro agente na plataforma. A empresa que a instala não aprende os seus ecrãs; a sua equipa traz o agente que já utiliza e descreve o resultado. Essa é a disposição em torno da qual a Sois é construída, oferecida aqui como uma implementação do argumento em vez de como a sua conclusão.

A conclusão é mais simples. Durante quarenta anos, a pergunta que um designer de software fez foi o que a pessoa do outro lado precisa ver. O próximo utilizador não vê. Lê um contrato e chama o que lhe é permitido chamar, e fará isso em nome das mesmas pessoas para quem os ecrãs foram construídos. O software que trata esse utilizador como um cidadão de primeira classe será operado fluentemente. O software que mantém o ecrã como a sua única porta ainda será operado, através de uma fechadura, por um agente vestido de forma diferente, até que os seus proprietários se cansem do disfarce e se movam.

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