Melhor software ERP agentivo: o que procurar

Porque não há classificação aqui

Picture the shortlist. Four vendors, four proposals, and the word agentic on every cover. One is an established suite with an assistant added last year. One is a newer product built around its own agent. One is a platform that lets any agent connect over an open protocol. One is a workflow tool with a language model in the middle. All four demo well. Two of them will still expect a person at the screen for anything that crosses a module boundary, and you will not find out which two from the proposals.

Uma lista classificada não pode ajudar com isso, por uma razão que nada tem a ver com a qualidade dos produtos. A agenticidade é uma propriedade da arquitetura, e se uma determinada arquitetura é adequada para si depende dos módulos que utiliza, de qual agente a sua equipa já usa, quais são os seus limites de aprovação e quanto precisa de ver no registo. Esses são os seus factos, não os de um revisor. O que circula entre empresas é o conjunto de testes, por isso esta página fornece-lhe os testes e pede-lhe para fazer a classificação.

Teste 1: protocolo aberto, o seu agente de fora

O primeiro teste é se um agente que o fornecedor não construiu pode operar o sistema. O padrão aberto para isso é o Model Context Protocol, que os clientes de agentes convencionais utilizam: Claude adiciona um servidor MCP remoto como um conector personalizado com um login OAuth; ChatGPT faz o mesmo em modo de desenvolvedor com suporte total de leitura e escrita; agentes de codificação e agentes internos construídos com os SDKs do fornecedor conectam-se da mesma forma. Um produto que fala MCP pode ser operado por qualquer um deles. Um produto que só funciona com o seu próprio assistente não pode ser operado por mais ninguém, e essa decisão foi tomada por si.

A evidência a solicitar é a resposta do servidor a um pedido de ferramentas/lista, que, de acordo com o protocolo, é a lista legível por máquina de tudo o que o agente pode fazer. Deve parecer algo assim, repetido para cada ação no sistema.

{
  "tools": [
    {
      "name": "contacts.search",
      "description": "Find contacts by name, email or company.",
      "inputSchema": { "type": "object", "properties": { "query": { "type": "string" } }, "required": ["query"] }
    },
    {
      "name": "invoices.create",
      "description": "Create a draft invoice from billable lines. Fails if the caller cannot raise invoices.",
      "inputSchema": { "type": "object", "properties": { "customer_id": { "type": "string" }, "lines": { "type": "array" } }, "required": ["customer_id", "lines"] }
    },
    {
      "name": "purchase_orders.approve",
      "description": "Approve a purchase order within the caller's approval limit.",
      "inputSchema": { "type": "object", "properties": { "purchase_order_id": { "type": "string" } }, "required": ["purchase_order_id"] }
    }
  ]
}

Uma resposta ilustrativa de ferramentas/lista na forma que a especificação MCP define. Os nomes e a cobertura irão diferir por produto; o que importa é que a lista exista, seja tipificada e seja longa o suficiente para cobrir os módulos que utiliza.

Três coisas a verificar na lista. É longa, porque um ERP tem centenas de ações e uma lista de vinte significa que o assistente alcança vinte funcionalidades. Está tipada, com um esquema JSON para cada entrada, porque é isso que permite ao servidor validar chamadas em vez de interpretar prosa. E muda quando um utilizador mais restrito inicia sessão, que é a ponte para o segundo teste.

Teste 2: permissões por utilizador em cada chamada

An agent that can do more than the person it represents is a liability, not a feature. The second test is whether permissions are enforced per user and per call, not per product or per session. The protocol allows a server to vary the tool list by the authorisation presented and requires servers to implement proper access controls, but it cannot enforce either on the vendor's behalf. The good implementations filter the list before the agent sees it and then check again when each tool runs, because a filtered list is a courtesy and an execution-time check is a control.

A evidência é uma recusa ao vivo. Inicie sessão como um utilizador que não pode aprovar ordens de compra, peça ao seu agente para aprovar uma e veja o que acontece. A resposta certa é uma recusa simples no momento da chamada, registada, com o resto do pedido ainda a ser processado. As respostas erradas são uma aprovação que passa, um erro que revela o que a ferramenta teria feito, ou uma sessão que falha em abrir porque a verificação foi apenas no ecrã.

Teste 3: transparência de orçamento e custos

Um agente que raciocina sobre os modelos do fornecedor consome algo sempre que é executado, e o terceiro teste é se consegue limitar esse gasto e ver para onde foi. O mecanismo específico importa menos do que as duas propriedades: um limite definido por integração ou por chave que o agente não pode exceder, e um registo por ação do custo de cada execução. Um produto que só lhe diz o total mensal após o facto não construiu o medidor, e você descobrirá isso quando um loop descontrolado ou um novo utilizador entusiasta receber a fatura.

Há uma segunda questão de custo que as páginas de classificação ignoram completamente. Se o produto lhe permitir trazer o seu próprio agente, então quando esse agente faz o raciocínio, o fornecedor pode não realizar nenhuma IA em seu nome, e não cobrar nada por isso. Para uma equipa que já paga por Claude ou ChatGPT, isso transforma o custo do agente numa linha que você controla em vez de uma linha que o fornecedor define. Pergunte a cada fornecedor quanto cobram quando o seu próprio agente faz o raciocínio e anote a resposta.

Teste 4: auditoria que lê como o registo de uma pessoa

Quando um agente faz o trabalho, o registo torna-se a principal forma de um gestor o rever, por isso o quarto teste é se a trilha de auditoria regista as ações do agente tão completamente quanto as de uma pessoa. O mínimo é quem pediu, qual agente atuou em seu nome, quais ferramentas foram utilizadas, com quais entradas, com que resultado e quando. A própria orientação do protocolo é que os clientes devem registar a utilização das ferramentas para auditoria; o servidor deve fazer o mesmo do seu lado, porque é o servidor que sabe o que realmente mudou.

A evidência é o registo em si, após o pedido de demonstração. Abra-o e verifique quatro coisas: atribuição a uma pessoa, não a um utilizador de integração genérico; a sequência de chamadas de ferramentas, não apenas os registos que acabaram por ser alterados; entradas e resultados, para que uma ação errada possa ser rastreada a uma entrada errada; e recusas, porque um modelo de permissões que não regista as suas negações não pode ser ajustado.

Teste 5: um mercado, e o que ele lhe diz

O quinto teste é indireto, mas revelador. Se uma plataforma tem um mercado de aplicações construídas por pessoas que não são o fornecedor, e essas aplicações são operadas por agentes através da mesma interface de ferramenta que os módulos principais, então a interface de ferramenta é real, documentada e estável o suficiente para que estranhos possam construir sobre ela. Um mercado é a própria arquitetura do fornecedor a ser testada por estranhos todos os dias. Também responde à questão prática do que acontece quando você precisa de uma capacidade que o produto principal não possui: se espera pelo roteiro, paga por trabalho personalizado ou instala algo que já existe.

A evidência é uma aplicação publicada de um terceiro, instalada no seu espaço de trabalho de teste, aparecendo na lista de ferramentas do agente no próximo pedido. Se o mercado existir, mas as aplicações forem todas do fornecedor, ou se instalar uma não mudar o que o agente pode fazer, o teste só está meio passado.

O painel de resultados

Leve isto para cada demonstração e preencha no dia. Classifique cada teste como passado, parcial ou falhado, e insista em ver a evidência em vez de ouvir sobre ela. Um produto que falha o primeiro teste é um produto com um assistente, independentemente do que a capa diz, e os outros quatro testes tornam-se académicos.

Sois é uma implementação contra a qual você pode realizar estes testes, e como nós o construímos, podemos dizer como ele responde. Um espaço de trabalho é um servidor MCP; qualquer cliente compatível conecta-se adicionando o endereço do espaço de trabalho e fazendo login uma vez através do OAuth, sem token para colar. As ferramentas são filtradas pelo papel do utilizador antes de serem oferecidas e verificadas novamente quando são executadas, e o acesso falha de forma restrita. O gasto pode ser limitado por integração, cada ação é registada, e quando o seu próprio agente faz o raciocínio, a plataforma não realiza IA em seu nome e não cobra nada por isso. Os desenvolvedores constroem aplicações com o seu próprio agente, validam localmente de forma gratuita e publicam num mercado onde cada agente conectado pode chamá-las. Realize os mesmos cinco testes contra ele como contra todos os outros; é para isso que eles servem.

Perguntas que as pessoas fazem

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