Melhor software ERP agentivo: o que procurar

Por que não há classificação aqui

Imagine a lista curta. Quatro fornecedores, quatro propostas e a palavra agentic em cada capa. Um é um conjunto estabelecido com um assistente adicionado no ano passado. Um é um produto mais novo construído em torno de seu próprio agente. Um é uma plataforma que permite que qualquer agente se conecte por meio de um protocolo aberto. Um é uma ferramenta de fluxo de trabalho com um modelo de linguagem no meio. Todos os quatro fazem boas demonstrações. Dois deles ainda esperarão uma pessoa na tela para qualquer coisa que cruze uma fronteira de módulo, e você não descobrirá quais dois a partir das propostas.

Uma lista classificada não pode ajudar com isso, por um motivo que não tem a ver com a qualidade dos produtos. A agenticidade é uma propriedade da arquitetura, e se uma determinada arquitetura é adequada para você depende de quais módulos você utiliza, qual agente sua equipe já usa, quais são seus limites de aprovação e quanto você precisa ver no log. Esses são seus fatos, não de um revisor. O que circula entre as empresas é o conjunto de testes, então esta página fornece os testes e pede que você faça a classificação.

Teste 1: protocolo aberto, 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 no modo desenvolvedor com suporte total para leitura e escrita; agentes de codificação e agentes internos construídos nos SDKs do fornecedor se conectam da mesma forma. Um produto que fala MCP pode ser operado por qualquer um deles. Um produto que só funciona com seu próprio assistente não pode ser operado por mais ninguém, e essa decisão foi tomada por você.

A evidência a ser solicitada é a resposta do servidor a uma solicitação de tools/list, que sob o protocolo é a lista legível por máquina de tudo 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 no formato definido pela especificação MCP. Nomes e cobertura variarão de acordo com o produto; o que importa é que a lista exista, seja tipada e seja longa o suficiente para cobrir os módulos que você usa.

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

Teste 2: permissões por usuário 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. Faça login como um usuário que não pode aprovar pedidos de compra, peça ao seu agente para aprovar um e veja o que acontece. A resposta correta é uma recusa simples no momento da chamada, registrada, com o restante da solicitação ainda sendo concluído. As respostas erradas são uma aprovação que passa, um erro que vaza o que a ferramenta teria feito, ou uma sessão que falha aberta porque a verificação foi apenas na tela.

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

Um agente que raciocina sobre os modelos do fornecedor consome algo toda vez que é executado, e o terceiro teste é se você pode 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 registro por ação do custo de cada execução. Um produto que só pode te informar o total mensal depois do fato não construiu o medidor, e você descobrirá isso quando um loop descontrolado ou um novo usuário entusiasta chegar à conta.

Há uma segunda questão de custo que as páginas de classificação ignoram completamente. Se o produto permite que você traga 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 equipe que já paga por Claude ou ChatGPT, isso transforma o custo do agente em uma linha que você controla, em vez de uma linha que o fornecedor define. Pergunte a cada fornecedor quanto eles cobram quando seu próprio agente faz o raciocínio e anote a resposta.

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

Quando um agente realiza o trabalho, o log se torna a principal forma de um gerente revisá-lo, então o quarto teste é se o registro de auditoria documenta 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 executadas, com quais entradas, com qual resultado e quando. A própria orientação do protocolo é que os clientes devem registrar o uso 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 log em si, após a solicitação da demonstração. Abra-o e verifique quatro coisas: atribuição a uma pessoa, não a um usuário de integração genérico; a sequência de chamadas de ferramentas, não apenas os registros que acabaram mudados; 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 registra suas negações não pode ser ajustado.

Teste 5: um marketplace, e o que ele te diz

O quinto teste é indireto, mas revelador. Se uma plataforma tem um marketplace de aplicativos construídos por pessoas que não são o fornecedor, e esses aplicativos são operados 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 construam sobre ela. Um marketplace é a própria arquitetura do fornecedor sendo testada por estranhos todos os dias. Isso também responde à questão prática do que acontece quando você precisa de uma capacidade que o produto principal não possui: se você espera pelo roadmap, paga por trabalho personalizado ou instala algo que já existe.

A evidência é um aplicativo publicado de um terceiro, instalado em seu espaço de trabalho de teste, aparecendo na lista de ferramentas do agente na próxima solicitação. Se o marketplace existe, mas os aplicativos são todos do próprio fornecedor, ou se instalar um não muda o que o agente pode fazer, o teste só foi parcialmente aprovado.

O placar

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

Sois é uma implementação contra a qual você pode executar esses testes, e como nós a construímos, podemos dizer como ela responde. Um workspace é um servidor MCP; qualquer cliente compatível se conecta adicionando o endereço do workspace e fazendo login uma vez via OAuth, sem token para colar. As ferramentas são filtradas pelo papel do usuário antes de serem oferecidas e verificadas novamente quando são executadas, e o acesso falha de forma restrita. Os gastos podem ser limitados por integração, cada ação é registrada, e quando seu próprio agente faz o raciocínio, a plataforma não realiza nenhuma IA em seu nome e não cobra nada por isso. Os desenvolvedores criam aplicativos com seu próprio agente, validam localmente de graça e publicam em um marketplace onde cada agente conectado pode chamá-los. Execute os mesmos cinco testes contra ele como contra os outros; é para isso que eles servem.

Perguntas que as pessoas fazem

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