Enterprise RAG: how the agentic ERP learned to remember

An ERP already remembers: invoices, bookings, stock entries, tickets, contacts, and projects are durable records. But that memory is structured for transactions, not for questions that cross sources.

“What has this customer been asking about?” may require conversations from several channels. “What do we know about this service problem?” may need messages, support records, notes, and product context. MINION’s Brains work began when a single chat context was no longer a credible representation of organizational knowledge.

Memory is not a transcript dump

The naive version of organizational memory is to put every message into a vector database. That improves recall demos and creates several new problems:

• the same conversation can be represented more than once;
• source freshness becomes unclear;
• exact identifiers and names perform poorly when semantic similarity dominates;
• retrieved text loses its business record and organization boundary;
• deletion or correction becomes difficult to reason about;
• an agent with a narrow job can accidentally inherit a broad corpus.

The Brains architecture instead treats raw evidence, normalized corpus units, retrieval indexes, and focused knowledge scopes as different layers.

Normalize before retrieving

Messages arrive from different channels with different identifiers, timestamps, threading rules, and payload shapes. Business records have their own schemas. A useful corpus needs a stable representation that preserves:

• organization and source;
• conversation or business-record identity;
• occurrence time and freshness state;
• participant or party linkage where supported;
• deterministic text evidence;
• derived summaries or bursts without replacing the raw source.

Normalization makes later retrieval comparable without pretending the original systems are identical.

One retrieval method is not enough

Semantic vectors are good at conceptual neighbors. They are not automatically good at exact names, codes, dates, or short identifiers. Exact and fuzzy search can solve those cases while missing paraphrases.

MINION therefore evolved toward multiple routes:

• exact or lexical search for names, phrases, and codes;
• fuzzy matching for imperfect identifiers and aliases;
• vector search for semantic neighborhoods;
• source and organization filters applied before results become context;
• focused Brains that compose allowed sources for a specific purpose.

The result is not “AI chooses the best database.” It is an explicit retrieval system whose routes can be inspected and tested.

Freshness is part of relevance

A highly similar result from a stale source may be less useful than a slightly weaker result from a current one. That makes ingestion state an editorial fact, not only an operational metric.

The platform added corpus backfills, source-specific freshness work, targeted reprocessing, and a private Qdrant serving bridge. Those changes were necessary because a search interface can look healthy while one source has quietly stopped advancing.

An honest Brain should be able to say “these are the closest results,” then add a caveat when needed: “this source has not been refreshed since this point” or “this source is not available in the current scope.”

A Brain is also a permission boundary

MINION’s managing Brain agents use a deliberately narrow principal. Their capabilities are restricted to the Brains surface, and access to an individual Brain is checked separately. That matters because the existence of a knowledge index must not grant access to every operational module that produced its evidence.

This creates two layers of authorization:

1. Can this principal use the Brains capability at all?
2. Can it access this specific Brain and its allowed sources?

The second question prevents “organization knowledge” from becoming a universal context bucket.

Memory and events meet at freshness

Knowledge becomes useful when new evidence can advance the corpus reliably. The Hub currently emits small committed domain events through PostgreSQL notification and retains scheduled work as a durability fallback. Separately, a private JetStream path was designed and validated for durable burst absorption and bounded workers.

Those are different maturity states. The important lesson is that retrieval freshness needs a durable job ledger and observable source checkpoints regardless of which wake-up transport is used. A broker can wake work; it does not replace the canonical database record of what must happen and what completed.

Keep evidence, routes, and scope together

I would preserve normalized source evidence, multiple retrieval routes, explicit freshness, focused Brains, organization scope, and the brains-only managing principal. These choices make retrieval a governed subsystem rather than an opaque feature.

Expose the receipt and correction path

I would expose a retrieval receipt with every answer: source set, route used, source freshness, ranking contribution, and any excluded source. I would also make re-index and correction workflows first-class so an operator can repair one source or record without running a broad backfill.

Organizational memory earns its value when the system can explain what it remembered, why it retrieved it, how current it is, and whether the caller was allowed to know it.