Skip to content
Systems

What your systems already emit becomes memory, with no AI model in the way.

When an order changes, a bill is disputed or a ticket reopens, the system already emits an event. Niadra receives that event, keeps the raw content and applies a versioned mapping that pulls out the type, the object, the customer’s ID in that system and the time. The order, ticket or bill is tied to the right customer, with a timeline of its events and of the agents’ actions. The official value stays in the system: the memory keeps what the agents need to remember and points to the source.

How it works

From event to memory

example
Arrives from the ERP
POST /v1/ingest/webhook/erp

{
  "event": "invoice.credited",
  "invoice": "0823",
  "customer_id": "48213",
  "amount": 40.00,
  "currency": "USD",
  "at": "2026-09-22T17:06:21Z"
}
Goes into the memory
Object
Bill 0823, from the ERPcredited at 2:06 pm, with a reference to the source record
Customer
Marina Souzarecognized by ID 48213 from the company records
Action
$40 credit appliedBilling agent · internal · 2:06 pm. The action and the ERP event become one record.
Open item
August bill disputeclosed by the 2:06 pm action

No AI model reads the event: the mapping transforms it, and the raw content is kept so it can be remapped later.

  • Comes in by webhook, through the API or as a batch file, for systems with no webhook
  • Only mapped event types come in: an ERP’s volume does not weigh on the memory
  • From one sample event, the configuration assistant proposes the mapping and tests it on a hundred events. A person approves it
  • Free text from inside a system, such as a ticket description, goes through the same reading as conversations
  • The system stays the official source, and Niadra never writes to it

One memory, nine products

The next agent can already show up knowing.

Tell us what you are building. The people who reply are the people who write the code.