Um agente de IA que opera os sistemas do seu negócio.
Peça o stock, emita uma fatura, avance com um negócio. Em linguagem corrente, sobre os seus próprios dados.
O problema
O seu ERP sabe tudo, e ninguém consegue falar com ele
Níveis de stock, tabelas de preços, encomendas em aberto, todas as faturas, todos os clientes. Está tudo no ERP, atrás de formulários, separadores e uma matriz de permissões. Tirar seja o que for de lá, ou lá pôr, é, por si só, um trabalho.
Por isso o trabalho escapa do sistema que foi criado para o guardar. Há quem confirme o stock indo até ao armazém. Há quem mantenha o verdadeiro livro de encomendas numa folha de cálculo. Um orçamento é acordado por WhatsApp e lançado no ERP dois dias depois, se é que chega a ser lançado.
O resultado é um back office que se aguenta à base de remendos:
- O ERP só responde às perguntas para as quais os seus ecrãs foram feitos. Tudo o resto é um pedido de suporte, uma exportação, ou um favor de quem escreve as queries.
- A folha de cálculo e a conversa de chat passam a ser o verdadeiro registo. O que chega ao ERP é uma cópia tardia, escrita à mão.
- O CRM e o ERP não coincidem. Um diz que o negócio fechou, o outro nunca viu a encomenda. O mesmo cliente existe duas vezes, com NIF diferentes.
- A única pessoa que percebe do ERP torna-se o gargalo, e o back office fica à espera dela.
Nada disto é um problema de dados. Os dados estão bem. O que falta é uma forma de pedir coisas aos sistemas e de lhes dizer o que fazer, em linguagem corrente, sem abrir um único formulário.
A nossa abordagem
Damos uma voz a cada sistema e as ferramentas para atuarem.
Não substituímos o ERP, nem o copiamos para uma base de dados nossa. O ERP continua a ser o sistema de registo. Colocamos à frente dele um agente capaz de o ler e de o operar.
O agente corre sobre a Ardaven, a plataforma de agentes e conhecimento da LayerX, e liga-se a cada sistema através de um MCP server dedicado. A Ardaven trata da conversa, do conhecimento e da política. Os MCP servers ligam-no ao ERP, ao CRM e a tudo o resto de que a empresa depende.
Uma camada de ferramentas tipadas à volta de cada sistema
Cada sistema tem o seu próprio MCP server: um para o Moloni, um para o TOConline, um para o CRM. Cada um expõe ferramentas tipadas com um schema claro para o que entra e o que volta, feitas para aquele sistema e não geradas a partir de uma spec.
A paginação, os rate limits, os retries, a autenticação e a versão que cada fornecedor tem da palavra «fatura» ficam dentro do respetivo server. Acrescentar outro ERP significa escrever outro server, não reescrever o agente.
As credenciais têm âmbito por tenant, por isso o agente de um cliente chega aos dados desse cliente e a mais nada.
As leituras correm livremente, as escritas são limitadas
Consultar o stock é seguro. Emitir uma fatura não é, porque uma fatura é um documento legal.
Por isso cada operação traz uma política: executar, ou preparar e esperar por um aprovador designado. Consultar o stock e preparar um orçamento podem correr sozinhos. Emitir um documento fiscal ou abater stock pode exigir uma pessoa. O limite é configuração, por isso um cliente começa restrito e vai aliviando à medida que ganha confiança.
As escritas levam idempotency keys, por isso um timeout ou um pedido repetido nunca emite a mesma fatura duas vezes.
Configurado a partir do processo real do cliente
Um agente de ERP genérico não serve a nenhuma empresa em concreto. O nosso é configurado a partir do que existe de verdade: séries de documentos, armazéns, fases do pipeline, regras de IVA, catálogo de produtos, nomenclatura.
Antes de escrever seja o que for, o cliente referido numa frase é associado a um cliente no ERP, o produto a um SKU, a encomenda a uma encomenda. Se um nome for ambíguo, o agente pergunta em vez de adivinhar.
A abordagem
Ferramentas tipadas por sistema · ler livre, escrever com limites · o processo real do cliente, não um ERP genérico.
O que construímos
Uma conversa, com todos os sistemas por trás
A equipa vê uma caixa de chat. Por trás dela estão o ERP, o CRM e tudo o mais de que a empresa depende, ao alcance de uma frase em vez de quatro aplicações.
Um agente para todos os sistemas
Ninguém tem de saber que sistema tem a resposta nem qual é preciso atualizar. O agente escolhe as ferramentas, chama-as pela ordem certa, e devolve o que os sistemas responderam.
Este último pedido é o trabalho de quatro sistemas numa só frase: marcar o negócio como ganho no CRM, converter o orçamento em encomenda, verificar o stock, emitir a fatura no ERP.
Stock e logística que respondem
O stock é a pergunta que mais se faz e a que o ERP pior responde, porque a resposta está repartida por armazéns, encomendas pendentes e mercadoria já comprometida. O agente trata de:
- Níveis por armazém e no total, incluindo o que está fisicamente lá contra o que já está prometido.
- Movimentos e transferências entre armazéns, indicados por uma frase e registados no ERP como um documento próprio.
- Pontos de reposição e encomendas a fornecedores, para que «precisamos de comprar mais disto?» tenha resposta antes de a prateleira ficar vazia.
- Expedição e rastreio, ligados à encomenda e ao cliente que está à espera dela.
Faturação fiscalmente correta em Portugal
Um documento fiscal é regulado, sequencial e comunicado à Autoridade Tributária, e é exatamente aqui que a camada de política justifica a sua existência.
O agente usa as séries de documentos reais da empresa, aplica a taxa de IVA correta ou o motivo de isenção, e produz documentos que levam ATCUD e o QR code impresso, alimentam o SAF-T (PT) e chegam à AT como devem chegar.
O ERP mantém o controlo daquilo que não pode ser improvisado: o Moloni ou o TOConline atribui o número, assina o documento e comunica-o. O agente prepara o documento, mostra-o por inteiro, e só o emite quando a política permite.
Vendas e CRM alinhados com o ERP
Um negócio no CRM e um cliente no ERP são a mesma empresa. O agente dá-lhes uma única identidade entre sistemas, associada pelo NIF e não pela forma como alguém escreveu o nome nesse dia. A partir daí a cadeia corre sem voltar a escrever nada: negócio, orçamento, encomenda, fatura.
O que é acordado no CRM torna-se o documento no ERP, e o que acontece no ERP é escrito de volta no CRM, para que o pipeline reflita faturas emitidas e não otimismo.
Comprovado em produção
Isto está a funcionar, não é apenas um slide.
A camada de ferramentas está em produção contra sistemas reais de faturação e de vendas:
- Moloni, para faturação, documentos comerciais e stock.
- TOConline, para faturação e documentos fiscais, incluindo os requisitos de certificação portugueses.
- Sistemas de CRM, para clientes, negócios e orçamentos mantidos alinhados com o ERP.
- Outros ERPs por trás da mesma camada de ferramentas. Um novo sistema é um novo server, não um novo agente.
Assenta em trabalho que já pusemos em produção.
O grounding do Company Brain trata do lado documental, por isso contratos, tabelas de preços e políticas internas informam uma resposta a par dos registos em tempo real do ERP. O Cadence aplica a mesma ideia a uma fábrica: um agente a operar sobre dados operacionais em tempo real, não um dashboard sobre eles.
Como funciona
Transformar uma API que ninguém gosta de usar em algo a que basta perguntar.
Por baixo, é a mesma mecânica para qualquer sistema com uma API.
Dar a um sistema uma superfície de ferramentas
Quando acrescentamos um novo ERP ou CRM:
- Lemos a API do fornecedor uma vez: os seus objetos, as suas restrições, os seus modos de falha, a sua ideia do que é um cliente.
- Modelamo-la como ferramentas tipadas, com schemas explícitos para argumentos e resultados, para que uma chamada inválida falhe antes de chegar ao fornecedor.
- Absorvemos a confusão dentro do server: OAuth com âmbito por tenant, refresh de tokens, paginação, rate limits, retries com backoff, e dialetos de erro traduzidos para algo sobre o qual o agente consegue raciocinar.
O mesmo nome de ferramenta passa a significar a mesma coisa quer vá parar ao Moloni quer ao TOConline, e é isso que torna barato acrescentar um sistema. A Ardaven descobre as ferramentas que cada server oferece, por isso uma nova capacidade aparece sem que o agente seja reescrito.
Executar uma operação
- O pedido é lido como uma intenção, e as entidades que menciona são extraídas.
- Essas entidades são resolvidas contra registos reais, por isso um nome passa a ser um customer ID e um produto passa a ser um SKU. A ambiguidade dá lugar a uma pergunta, não a um palpite.
- É construída uma pré-visualização: exatamente o que seria escrito, em que sistema, com que totais e que tratamento fiscal.
- A verificação de política decide se corre já ou se espera por um aprovador designado.
- Executa com uma idempotency key, e a confirmação cita a referência do próprio documento no ERP.
- Tudo isto fica registado num audit log apenas de adição: quem pediu, o que foi proposto, quem aprovou, o que o sistema devolveu.
Segurança e privacidade
Um agente com chaves precisa de salvaguardas.
As credenciais são de privilégio mínimo e com âmbito por tenant, por isso um agente chega aos sistemas de uma empresa com as permissões que essa empresa concedeu, e leituras entre tenants são impossíveis por conceção. Cada leitura e cada escrita entram num audit log apenas de adição, com o autor associado. O rate limiting absorve picos e abusos. Os requisitos do RGPD e do EU AI Act são tratados ao nível da plataforma, com alojamento na UE disponível.
Quando os dados não podem sair de portas, toda a stack corre dentro do perímetro da própria empresa: os modelos correm na sua infraestrutura, ao lado do ERP, e nada é enviado para terceiros.
O que entrega
O back office operado em frases em vez de formulários.
| Camada | Escolha |
|---|---|
| Plataforma | Ardaven, a plataforma de agentes e conhecimento da LayerX: conversa, conhecimento, política e interfaces |
| Sistemas | Moloni · TOConline · outros ERPs · CRM, cada um mantido como sistema de registo |
| Camada de ferramentas | Um MCP server por sistema · ferramentas tipadas com schemas explícitos · credenciais com âmbito por tenant · particularidades de cada fornecedor absorvidas dentro do server |
| Leituras | Queries em tempo real ao sistema de registo · entidades resolvidas para registos reais · ambiguidade levantada como pergunta |
| Escritas | Política por operação, autónoma ou com aprovação · pré-visualizações antes da execução · idempotency keys · aprovadores designados |
| Fiscal | Séries de documentos · taxas de IVA e motivos de isenção · ATCUD · código QR · SAF-T (PT) · comunicação à AT, tudo emitido pelo ERP |
| Segurança | Credenciais de privilégio mínimo e com âmbito · sem leituras entre tenants · audit log apenas de adição · rate limiting · conformidade com RGPD e EU AI Act · alojamento na UE · implementação on-premise com inferência local |
O resultado é um back office onde perguntar e fazer são a mesma ação. As perguntas sobre stock têm resposta onde são feitas, os documentos são emitidos no momento em que são acordados, o CRM e o ERP contam a mesma história, e ninguém passa a tarde a copiar uma folha de cálculo para dentro de um formulário.
Para além do ERP e do CRM
Qualquer sistema com uma API passa a ser algo que se opera.
O ERP e o CRM são a montra, não o limite.
Faturação, ticketing, RH, e-commerce, banca, logística, back offices internos: a qualquer coisa com uma API pode dar-se uma superfície de ferramentas e pô-la atrás do mesmo agente, com a mesma política a decidir o que corre sozinho e o que espera por uma pessoa.
Sempre que as pessoas passam o dia a mover informação entre sistemas que nunca foram apresentados uns aos outros, esse trabalho pode tornar-se uma conversa.
Vamos ligar um agente aos seus sistemas.
Construímos as camadas de IA e de integração que permitem a uma empresa operar o seu próprio software em linguagem corrente, juntando verdadeira profundidade em agentes e integração de sistemas com práticas modernas de software, e feitas para serem seguras, protegidas e em conformidade para a UE.
Se isto se parece com a sua situação, vamos falar.
Vamos Falar