Andrii Bidochko

• Updated: July 8, 2026
• 6 min read

Organizational Memory for Agentic Business Process Execution

Direct Answer

The paper introduces an organizational memory layer that centralizes and governs enterprise‑specific procedural knowledge for Large Language Model (LLM) agents, enabling them to execute business processes reliably without duplicating or siloing information. This matters because it bridges the gap between the general‑purpose intelligence of LLMs and the nuanced, ever‑changing policies that drive real‑world enterprises.

Background: Why This Problem Is Hard

Enterprises have long relied on rule‑based workflow engines, BPMN models, and static SOP documents to codify how work should be done. While these artifacts are human‑readable, they are fragmented across policy manuals, process diagrams, and ad‑hoc knowledge bases. When LLM‑powered agents are introduced, they inherit a powerful language understanding but lack the organization‑specific context required to act correctly.

Existing attempts to feed agents with the needed knowledge typically involve:

• Embedding entire policy documents into a single prompt – which quickly exceeds token limits.
• Building per‑agent retrieval pipelines that query a private vector store – leading to duplicated indexes and inconsistent updates.
• Hard‑coding procedural rules inside the agent’s code – creating maintenance nightmares as policies evolve.

These workarounds do not scale. As the number of agents grows, enterprises face knowledge silos, rule drift, and costly governance overhead. Moreover, any change to a policy must be propagated manually to every agent, increasing the risk of non‑compliance.

What the Researchers Propose

The authors propose a dedicated Organizational Memory (OM) service that acts as a shared, governed, and agent‑consumable reference layer. The OM stores procedural knowledge in a structured, versioned format and exposes it through a unified API. Key components include:

• Curator Engine: Ingests raw artifacts (policies, BPMN models, SOPs), normalizes them, and extracts actionable steps.
• Governance Layer: Enforces access controls, change‑approval workflows, and audit trails to satisfy compliance requirements.
• Retrieval Interface: Provides context‑aware queries that agents can invoke at runtime, returning concise, up‑to‑date instructions.
• Learning Loop: Captures execution feedback from agents and feeds it back into the memory to refine future retrievals.

By decoupling knowledge storage from individual agents, the framework eliminates duplication, ensures consistency, and supports continuous learning across the organization.

How It Works in Practice

The operational workflow can be broken down into three phases: Ingestion, Retrieval, and Execution.

1. Ingestion Phase

Subject‑matter experts upload or link existing documents to the Curator Engine. The engine applies natural‑language parsing, entity extraction, and process mining to transform unstructured text into a graph of Task → Preconditions → Outputs. Each node is versioned, and any modification triggers a governance review.

2. Retrieval Phase

When an LLM agent receives a user request (e.g., “procure 10 laptops”), it first calls the Retrieval Interface with a high‑level intent. The interface performs a semantic match against the stored graph, returning a ranked list of relevant procedural fragments, such as “verify budget approval” or “select approved vendor”. The agent can then ask follow‑up clarification questions to the OM until it has a complete, executable plan.

3. Execution Phase

The agent follows the plan step‑by‑step, invoking external services (ERP, email, ticketing) as needed. After each step, it reports success or failure back to the Learning Loop. If a step fails due to an outdated rule, the loop flags the corresponding memory node for review, closing the feedback cycle.

What sets this approach apart is the single source of truth for procedural knowledge and the ability for any number of agents—across departments or geographies—to draw from the same, governed repository without bespoke prompt engineering.

Illustrative Diagram

Evaluation & Results

The authors built a proof‑of‑concept around a procurement workflow, a domain that typically involves multiple approvals, vendor selections, and compliance checks. They compared three setups:

1. Baseline Rule‑Based Engine: Traditional BPMN with static rules.
2. LLM Agent with Ad‑hoc Prompts: Each agent received a handcrafted prompt containing the entire policy.
3. LLM Agent + Organizational Memory: Agents queried the OM for context.

Key findings included:

• Compliance Accuracy: The OM‑enabled agents achieved 96% correct‑step execution versus 71% for ad‑hoc prompts and 84% for the rule‑based engine.
• Token Efficiency: Average prompt length dropped from 2,400 tokens (ad‑hoc) to 350 tokens (OM), staying well within model limits.
• Update Latency: Policy changes propagated to all agents within minutes through the governance pipeline, whereas the ad‑hoc approach required manual prompt rewrites for each agent.
• Scalability: Adding a new agent required only API integration; no additional knowledge engineering was needed.

These results demonstrate that a shared organizational memory not only improves correctness but also reduces operational overhead and improves the agility of AI‑driven process automation.

Why This Matters for AI Systems and Agents

For AI product managers and enterprise architects, the study offers a concrete blueprint for turning LLMs into trustworthy process executors. The implications are threefold:

• Reduced Engineering Burden: Teams no longer need to craft bespoke prompts for each workflow, freeing resources for higher‑value innovation.
• Governance at Scale: The built‑in approval and audit mechanisms align AI actions with regulatory and internal compliance frameworks, a critical requirement for finance, healthcare, and public sector deployments.
• Continuous Improvement Loop: By feeding execution outcomes back into the memory, organizations can automatically surface policy gaps and evolve SOPs based on real‑world usage.

Practically, the architecture can be layered onto existing AI orchestration platforms. For example, the UBOS platform overview already provides a modular runtime where an OM service could be plugged in as a microservice, exposing the same retrieval API to any registered agent.

What Comes Next

While the proof‑of‑concept validates the core idea, several open challenges remain:

• Semantic Drift: As LLMs evolve, the phrasing of retrieved steps may diverge from the original intent, requiring robust alignment techniques.
• Cross‑Domain Knowledge Fusion: Enterprises often have overlapping processes (e.g., procurement and contract management). Merging memories without creating conflicts is an open research problem.
• Real‑Time Performance: High‑throughput environments demand sub‑second retrieval latencies; optimizing vector indexes and caching strategies will be essential.

Future work could explore hybrid memory models that combine symbolic process graphs with neural embeddings, or integrate external compliance engines for automated policy verification. The authors also suggest extending the framework to support multi‑agent collaboration, where several specialized agents negotiate a shared plan using the same memory.

Enterprises interested in experimenting with this paradigm can start by prototyping an OM layer on top of their existing Enterprise AI platform by UBOS, leveraging the platform’s built‑in workflow automation studio and vector‑store integrations.

References

Organizational Memory for Agentic Business Process Execution (arXiv)

Andrii Bidochko

CTO UBOS

Andrii Bidochko is an AI entrepreneur and researcher focused on AI agents, reinforcement learning, and autonomous systems. He writes about the technologies shaping the future of machine intelligence, from frontier models and agent architectures to real-world AI applications.