O que os seus sistemas já emitem vira memória, sem modelo de IA no caminho.
Quando um pedido muda, uma fatura é contestada ou um ticket reabre, o sistema já emite um evento. A Niadra recebe esse evento, guarda o conteúdo cru e aplica um mapeamento versionado que tira dele o tipo, o objeto, o ID do cliente naquele sistema e o horário. O pedido, o ticket ou a fatura fica ligado ao cliente certo, com a linha do tempo dos eventos e das ações dos agentes. O valor oficial continua no sistema: a memória guarda o que os agentes precisam lembrar e aponta para a origem.
Como funciona
Do evento à memória
exemploPOST /v1/ingest/webhook/erp
{
"event": "invoice.credited",
"invoice": "0823",
"customer_id": "48213",
"amount": 40.00,
"currency": "BRL",
"at": "2026-09-22T17:06:21Z"
}- Objeto
- Fatura 0823, do ERPcreditada às 14h06, com a referência ao registro de origem
- Cliente
- Marina Souzareconhecida pelo ID 48213 do cadastro
- Ação
- Crédito de R$ 40 lançadoAgente de cobrança · interno · 14h06. A ação e o evento do ERP viram um registro só.
- Pendência
- Contestação da fatura de agostofechada pela ação das 14h06
Nenhum modelo de IA lê o evento: o mapeamento transforma, e o conteúdo cru fica guardado para remapear depois.
- Entra por webhook, pela API ou em lote, por arquivo, para o sistema que não tem webhook
- Só os tipos de evento mapeados entram: o volume de um ERP não pesa na memória
- A partir de um exemplo de evento, o assistente de configuração propõe o mapeamento e testa em cem eventos. Uma pessoa aprova
- Texto livre de dentro de um sistema, como a descrição de um ticket, passa pela mesma leitura das conversas
- O sistema continua sendo a fonte oficial, e a Niadra nunca escreve nele
Uma memória, nove produtos
- SistemasVocê está aquiOs eventos que os seus sistemas já emitem, ligados ao cliente certo.
Qualquer agente se liga à memória com três chamadas, em Python, TypeScript, HTTP ou MCP.
Ver a documentação