Plataforma ECOSIRE

O que é o ERP agêntico?

ERP agêntico é um ERP em que os agentes de IA são contas de pleno direito, e não uma janela de chat. Um agente da ECOSIRE tem o seu próprio registo com a lista explícita de ferramentas que pode invocar, o nível de risco máximo em que pode agir sem uma pessoa e um limite de ações por hora. Cada ação que tenta segue um único caminho — proposta, verificação de política, aprovação quando necessária, execução duradoura, entrada no registo — e nenhuma escrita de agente pode contorná-lo. As ações classificadas como críticas, como lançar um movimento contabilístico ou registar um pagamento, exigem uma pessoa em todos os níveis de autonomia, incluindo o mais alto.

Política: 110; low · medium · high · critical
A escada de autonomia: 3; L0 · L1 · L2
Ligue os seus próprios agentes por MCP: POST /api/mcp; eco_live_…

O único caminho que qualquer ação de agente percorre

Não existe uma segunda rota. Um agente não pode escrever diretamente na base de dados e uma ferramenta não pode ser invocada fora de banda — o gateway é a única porta, e é ele que escreve o registo.

Propor
O agente nomeia uma ferramenta e fornece os seus argumentos. Um nome de ferramenta desconhecido, ou argumentos que falham o esquema, são rejeitados de imediato, antes de existir qualquer entrada no registo — o registo anota decisões sobre propostas válidas, não chamadas malformadas.
Política
Três verificações podem negar de imediato: o agente está ativo, esta ferramenta está na sua lista branca, e ainda está dentro do seu orçamento de ações por hora. Uma negação em qualquer uma delas é escrita no registo com o motivo. Uma quarta verificação não é uma negação — se o nível de risco da ferramenta ficar acima do teto do agente, ou for classificado como crítico, a proposta é encaminhada a uma pessoa em vez de recusada.
Aprovar
Tudo o que ultrapasse o teto do agente — e tudo o que seja classificado como crítico, sempre — chega a uma caixa de aprovações como proposta pendente e deixa uma nota na linha temporal do registo. Uma pessoa aprova ou rejeita, e a sua identidade fica guardada com a decisão.
Executar
O trabalho aprovado entra numa fila duradoura sob um id derivado da ação, para que uma nova tentativa não o execute duas vezes. O worker volta a confirmar que o agente continua ativo e que a ferramenta ainda existe antes de mexer em seja o que for, e um trabalho que morre a meio é recolhido em vez de ficar preso.
Registo
Sucesso ou falha, o resultado é guardado com o motivo da decisão — e, quando esteve envolvido um modelo, com o modelo e a versão de prompt, os tokens consumidos e o custo em micro-dólares inteiros, nunca um decimal. As entradas não são editadas nem apagadas de forma lógica em operação normal; remover uma conta de agente remove o seu histórico com ela. Exporte em JSON para o registo completo, ou em CSV para os campos de decisão. A linha temporal do registo também recebe o resultado, por isso quem trabalha esse registo vê o que o agente fez sem abrir um ecrã de administração.

A escada de autonomia

Um seletor por agente, três posições. O que o seletor realmente define é um único número: o nível de risco acima do qual uma pessoa tem de aprovar. Arranque cada agente em L0, leia o seu registo durante uma semana e depois decida se o sobe.

A escada de autonomia	Aprovar
L0 Suggest	executa sozinho até none
L1 Assist	executa sozinho até low
L2 Operate	executa sozinho até high

Nenhum nível corresponde a um teto crítico, porque o crítico nunca se autoexecuta. O nível mais alto selecionável é L2 — subir o seletor alarga o que corre sem supervisão, nunca remove a exigência de aprovação nas ações críticas.

Ligue os seus próprios agentes por MCP

POST /api/mcp implementa o Model Context Protocol sobre HTTP transmissível sem estado. Autentique-se com uma chave de agente emitida na consola de administração — a chave em bruto é mostrada uma única vez — e o servidor lista as ferramentas de negócio da lista branca desse agente, mais quatro controlos internos para ler o estado das ações e conduzir as execuções de ciclo. Nada fora da lista branca é oferecido. Um tools/call entra no mesmo gateway dos nossos agentes: as mesmas verificações de política, a mesma caixa de aprovações, o mesmo registo. O GET responde 405 de propósito; aqui, MCP é só POST.

Um exemplo prático: o agente de cobranças

É opcional por organização: sem conta de agente de cobranças, não há análise. Todas as manhãs revê as faturas vencidas e propõe um aviso de pagamento por fatura aos 7, 14 ou 30 dias, com uma chave que impede uma segunda passagem no mesmo dia de o duplicar. Abaixo de L2 não consegue enviar de todo — a proposta fica na caixa de aprovações. O envio depende da lista de supressão, e um erro nessa verificação significa não enviar. Propor uma reconciliação de pagamentos é classificado como crítico, por isso é uma proposta para sempre, em todos os níveis.

O que impede um agente de correr mal

Uma chave de agente está isolada de todos os caminhos de chaves de utilizador, por isso nunca pode agir como uma pessoa. Cada consulta é delimitada à sua organização no código da aplicação — esse é o controlo principal; a segurança ao nível da linha na base de dados está provisionada sobre as tabelas de negócio centrais e ainda corre em modo permissivo enquanto é implantada, por isso trate-a como defesa em profundidade e não como o que segura a linha. Suspender um agente para-o à porta e a meio: o executor volta a confirmar que continua ativo antes de correr uma ação já aprovada. As mensagens de saída falham em fechado contra a lista de supressão. As execuções de ciclo não assistidas têm ainda um interruptor de emergência: uma flag para toda a frota e um campo por agente.

Quer vê-lo com os seus próprios dados?

Diga-nos em que processo colocaria um agente primeiro e percorremo-lo consigo pela escada de autonomia — a começar em L0, onde propõe e não executa nada.