← Research

Research · Sep 6, 2026

Enterprise RAG is not an agent

Retrieval-augmented generation answers questions from a corpus. Agents have to complete jobs on live systems. Agentic RAG is still RAG.

Shikhar Mishra · Co-Founder & CEO, EGI

Enterprise RAG embeds a document corpus, retrieves relevant chunks, and places them in the model context before generation. This is effective for search, synthesis, and question answering. It does not, by itself, provide the state management and transaction controls required for enterprise execution.

Retrieval answers what a corpus contains. Execution also needs to know what is true now for this tenant and workflow step, which source is authoritative, and whether an earlier write already committed. A contract PDF can conflict with an ERP record; a retry can duplicate a transaction. Retrieval supplies evidence, but validation, idempotency, recovery, and completion require separate mechanisms.

Why agentic RAG does not fix this

Agentic RAG adds a planner that issues multiple retrievals, maybe a tool call, maybe a citation pass. The substrate is still a document warehouse. The agent still hydrates a window from similar text. Context pollution is the failure mode: the wrong chunk, the stale chunk, the chunk from another legal entity, the chunk that was true last quarter. Similarity is not state.

  • Enterprise RAG treats memory as a library. Agents need a live index of entity handles, policy refs, and workflow position.
  • Vector preload at session start makes records eligible before the runtime knows which execution checkpoint will use them.
  • Citations optimize for answer quality. Jobs optimize for correct writes and constraint adherence.
  • Embedding a record does not define its invalidation policy. Without explicit deletion or freshness filters, stale records remain eligible for retrieval.

The context graph is the replacement, not a prettier RAG

EGI’s common context layer is a tenant-scoped index of current entity handles, policy references, and workflow position. At a tool or policy checkpoint, the runtime binds the minimum required slice and releases it after the step. Explicit addition, update, and eviction reduce the chance that stale or irrelevant records remain eligible for a write.

Document grounding supports explanation; controlled state binding supports execution.

Bruce executes against current operational state such as legal entity, open purchase orders, inventory position, and close status. Documents may inform a checkpoint, but the system of record and the execution policy determine whether an action is permitted and whether the job is complete.

Enterprise execution agent

Bruce

The model is a dependency. Bruce is the agent that keeps the job correct—intent through completion on messy, heterogeneous ERPs. The serious work is posting, receiving, and closing.

Related