Source-linked AI summary
Shared Organizational Memory for Enterprise Coding Agents: System Design and Deployment Snapshot
Harsh Rao Dhanyamraju, Leonidas Raghav
TL;DR
Enterprise coding agents need organization-specific knowledge that tools and documentation may not capture, while existing shared-memory approaches still depend on agents to record useful lessons. This paper reports a deployed system that captures, curates, and retrieves approved memories; its snapshot measures throughput, while retrieval relevance and coding-task utility remain under evaluation.
Problem
Tools and documentation can expose resources without capturing organization-specific conventions, recent fixes, internal DSL semantics, or tacit workflows, while existing shared-memory interfaces leave capture dependent on agents.
Source: §1 · p. 2Method
Results
At the July 22, 2026 snapshot, 900 contributed learnings yielded 1,144 curated memories, while the reported figures characterize throughput rather than retrieval relevance or downstream utility.
Source: §4 · pp. 5–6Takeaways & Limitations
The production deployment establishes a three-stage organizational memory lifecycle, while retrieval relevance and downstream coding-task utility remain under evaluation.
Source: §5 · p. 6Curation occurs after the original task and cannot validate future-context guidance, so an incorrect but unsuspicious memory may be served before negative feedback lowers its trust score.
Source: §6 · p. 6
Abstract
from arXiv · showhide
Enterprise coding agents rely on tools and retrieval, yet enterprise knowledge often remains outside public training data and formal documentation: internal DSLs, proprietary platforms, local conventions, recent fixes, and tacit workflows. Existing knowledge interfaces expose stored resources but still depend on agents recognizing and explicitly recording lessons worth reusing, disconnecting capture from the coding workflow and leaving development experience repeatedly rediscovered. We report an ongoing production deployment of a shared organizational memory system that makes capture a platform-level part of coding work: it collects task-adjacent experience with contributor approval, curates it into reusable question-answer memories, gates obvious security and privacy risks, and retrieves memories for future agents. This short paper describes the deployed lifecycle and an operational snapshot. Effects on retrieval and coding tasks remain under evaluation.
1 Introduction
Enterprise coding agents need private, organization-specific knowledge that may be poorly documented or absent from public training data. Existing tools can expose resources, but do not ensure useful lessons are captured and reused; this paper reports a production memory system that addresses that lifecycle gap.
1 Introduction
- Internal DSLs and organization-specific conventions can encode knowledge unavailable in public training data or poorly documented, leaving agents to learn from repositories, tools, and prior outcomes.This includes version-specific behavior, edge cases, and proprietary configuration, policy, schema, build, and deployment languages.Source: §1 · p. 1
- Access to files, APIs, tools, and documentation does not itself capture local conventions, recent fixes, internal DSL semantics, or tacit workflows.Documentation may be incomplete or stale, and private behavior may become clear only through debugging, tests, failures, and fixes.Source: §1 · p. 2
- Persistent agent memory can retain private development experience across tasks rather than leaving it to be repeatedly rediscovered.Prior work describes memory as durable state distinct from transient context and demonstrates compressing, retrieving, and reusing development state.Source: §1 · p. 2
- CQ supports shared knowledge reuse, but relies on agents to invoke contribution tools and does not deliver memories natively within coding workflows.Human confirmation and review may also be difficult to scale across large organizations.Source: §1 · p. 2
- The reported organizational memory layer initiates task-adjacent capture with contributor approval, curates accepted contributions under provenance and policy controls, and retrieves memories for future agents.The approach makes capture and reuse of private development experience part of the coding workflow.Source: §1 · p. 2
2 System Architecture
The architecture links local capture, governed curation, and retrieval through API, MCP, and UI boundaries. Its clients collect approved task-adjacent edits, convert them into curated memories, and make structured memories available to future coding tasks.
2 System Architecture
- The three-stage lifecycle connects local knowledge capture, governed curation, and retrieval for later coding tasks through explicit API, MCP, and UI boundaries.The stages are designed to remain independently controllable.Source: §2 · p. 2, Figure 1 · p. 3
2.1 Contributor Client
- The Contributor Client detects local knowledge-base edits, constructs contextualized diffs, and automatically initiates contribution, sending candidates only after user approval.It observes task-adjacent memory edits and avoids asking the coding assistant to package its own changes.Source: §2.1 · p. 3, Figure 2 · p. 4
2.2 Curation Pipeline
- The Curation Pipeline records approved edits with provenance and local context, then enriches them into self-contained question–answer memories when reusable knowledge is present.It filters hunks with insufficient context and can merge related hunks, split dense ones, or produce no memory.Source: §2.2 · p. 4
- The deployed gate combines security scanning and collision checks before storing curated memories and initializing feedback tracking.Security decisions can persist a candidate unchanged, persist a rewritten memory, or drop it; the described decision contract has no quarantine state.Source: §2.2 · pp. 4–5
- Across three identical runs of 56 synthetic cases, 135 (80.4%) outcomes were appropriate, 32 (19.0%) cautious but non-blocking, 1 (0.6%) overcautious, and 0 (0.0%) unsafe acceptances.The cases covered dependency risks, secrets, unsafe code, personal or internal information, unsafe workflows, and benign controls.Source: §2.2 · p. 4
2.3 Consumer Client
- The Consumer Client exposes structured memories over MCP, REST APIs, and a human-user interface, with Fast, Normal, and Deep Research retrieval tiers.Returned memories include questions, answers, examples, caveats, tags, trust scores, and related-memory links.Source: §2.3 · p. 5
- Authenticated feedback updates agent and human vote counters and recalculates a heuristic 0–10 trust score that shrinks sparse feedback toward a prior.The score has not been calibrated against downstream task success.Source: §2.3 · p. 5
3 Design Considerations
The design treats memory format and governance as parts of retrieval. It stores reusable knowledge as question–answer units and applies curation, gating, trust scoring, and feedback to keep shared memories revisable rather than authoritative.
3 Design Considerations
- Raw traces, diffs, and implementation notes may align poorly with later queries, so the system treats memory format as part of retrieval design.The passage frames this as a gap between input text and the knowledge needed for retrieval.Source: §3 · p. 5
- Curated Memory uses a developer-facing question, direct answer, working examples, and caveats; search matches both questions and answers.Question matching serves problem-shaped queries, while answer matching can capture implementation details, error messages, and API names.Source: §3 · p. 5
- Because one corrupted memory can influence future agents, the system uses gating, curation, trust scoring, and feedback to keep accepted memories revisable rather than permanently authoritative.These measures aim to prevent unsafe or low-quality memories from becoming organization-wide guidance.Source: §3 · p. 5
4 Deployment Snapshot
The July 22, 2026 deployment snapshot reports memory production and semantic-link scale for selected internal teams. These figures describe throughput, not retrieval relevance or downstream utility.
4 Deployment Snapshot
- 900 contributed learnings yielded 1,144 curated memories; 483 (53.7%) produced at least one persisted memory and 417 (46.3%) produced none.That is 2.37 memories per productive learning at the July 22, 2026 snapshot.Source: §4 · p. 5
- The snapshot covers selected internal teams at SAP SE, and current telemetry cannot identify which pipeline stage was responsible for no-yield cases.Finer-grained stage-level disposition logging is planned.Source: §4 · pp. 5–6
- 1,100 persisted memories (96.2%) had at least one semantic link, with 7,863 links across 35 tools and frameworks.The reported figures characterize deployment scale and throughput, not retrieval relevance or downstream utility.Source: §4 · p. 6
5 Conclusion
The deployed system addresses the gap between reusable shared knowledge and capture that depends on agents explicitly recording lessons. It connects approved task-adjacent capture, governed curation, and retrieval, while retrieval relevance and coding-task utility remain under evaluation.
5 Conclusion
- Existing shared-memory systems leave contribution dependent on agents recognizing and explicitly recording useful lessons.This disconnects knowledge capture from the coding workflow.Source: §5 · p. 6
- The deployed substrate links task-adjacent capture with user approval, curation into governed, trust-aware question–answer memories, and MCP retrieval for future agents.The three stages are the Contributor Client, Curation Pipeline, and Consumer Client.Source: §5 · p. 6
- Retrieval relevance, downstream coding-task utility, memory freshness, and heuristic trust-score calibration remain under evaluation.Source: §5 · p. 6
6 Limitations
The system’s capture, feedback, and curation depend on configured assistant behavior and cannot guarantee that stored guidance is correct or safe. Its security-gate evaluation also has a developer-authored-case limitation.
6 Limitations
- Capture observes only learnings externalized into designated memory files, requiring assistant-facing configuration that keeps the collection surface small and reviewable.Source: §6 · p. 6
- Feedback requires a tangential post-consumption action, and incorrect but non-suspicious memories may reach agents before negative feedback lowers their trust score.Curation follows the original task and does not validate guidance in future contexts.Source: §6 · p. 6
- The gate’s reported agreement may reflect its developers’ assumptions because they authored the synthetic cases, acceptable actions, and postconditions without independent adjudication.Source: §6 · p. 6
- Curation, trust scoring, and gated persistence reduce but cannot eliminate memory-injection risk; retrieved guidance still requires inspection, testing, and review.Source: §6 · pp. 6–7
7 Ethical Considerations
The ethical discussion treats privacy, memory poisoning, and contributor accountability as continuing governance concerns. The appendices describe collection and curation fields, including their retrieval and governance roles.
7 Ethical Considerations
- Local contextualization, designated memory files, user approval, and secret and personal-data scanning reduce unnecessary disclosure but cannot eliminate it.Production hardening also calls for encryption, tenant isolation, least-privilege access, auditable controls, and retention and deletion policies.Source: §7 · p. 7
- Curation, provenance, validation gates, trust scores, and feedback reduce but do not eliminate memory poisoning; retrieved memories remain advisory and need inspection and testing.Source: §7 · p. 7
- Contributor identities should be pseudonymous in routine records, with identity mappings separately controlled; contribution metrics must not be repurposed for performance assessment.Source: §7 · p. 7
A Captured Learning Schema
- Collection retains approved edits as raw learnings, preserves textual patches for provenance, and renders them into structured hunks; the validated hunk-count invariant is not enforced at intake.Table 1 summarizes the raw-learning intake fields.Source: A Captured Learning Schema · p. 11, Table 1 · p. 11
B Curated Memory Schema
- Curated-memory fields are classified by searchability, display to consuming agents, or governance-only use; question and answer are embedded separately, and governance fields are not searchable.The optional security_scan property is reserved for audit metadata but is not stored by the production persistence path.Source: B Curated Memory Schema · p. 11
C Curation Agent Contracts
The deployed curation pipeline uses distinct agent roles to turn captured hunks into reusable memories, assign controlled tags, scan security risks, and check for collisions. Its LLM calls use a fixed model configuration and validated JSON outputs.
C Curation Agent Contracts
- All LLM calls used Claude Sonnet 4.5 at temperature 0, with schema-validated JSON outputs and retries for transient connection, timeout, and server errors.The tag-validation call alone had max_tokens set to 150.Source: C Curation Agent Contracts · p. 11
- The Enrichment Agent filters hunks with insufficient context and converts survivors into grounded question–answer memories, merging related hunks or splitting dense ones as needed.It emits nothing when no reusable knowledge exists.Source: C Curation Agent Contracts · p. 12
- The Bucketing Agent assigns registry tool and type tags, validates proposed new tags separately, and uses generic fallbacks when a dimension remains empty.Deterministic tag identifiers make upserts idempotent.Source: C Curation Agent Contracts · p. 12
- The Security Scan Agent runs a lightweight, non-exhaustive scan using at most six relevant tools in parallel and preserves useful grounded content when rewriting.Source: C Curation Agent Contracts · p. 12
- The Collision Checker uses tag-filtered keyword and vector similarity over questions and answers, then accepts, clarifies, or rejects candidates and can link retained memories.Source: C Curation Agent Contracts · p. 12
D Security and Privacy Gate
The production security and privacy gate scores candidates across six categories, then aggregates their statuses to determine a persistence action. Its in-repository checks are reproducible for fixed inputs and configuration, but model routing and rewriting can vary unless settings are pinned.
D Security and Privacy Gate
- The gate scores each candidate across six categories using Safe, Unsafe, Safe with caveats, or N.A.Its checks are placed after enrichment and before trust scoring, bucketing, collision checking, and persistence.Source: D Security and Privacy Gate · pp. 12–13
- For fixed input and configuration, in-repository rule-based checks are reproducible, but agent routing and rewriting can vary unless model, prompt, and decoding settings are pinned.The checks are not pinned invocations of external scanner binaries.Source: D Security and Privacy Gate · p. 13
- Any Unsafe category status takes precedence, followed by Safe with caveats, Safe, and N.A. when aggregating candidate statuses.The aggregate status drives one persistence decision; there is no quarantine state.Source: D Security and Privacy Gate · p. 13
- Secret and PII checks can return replacement hints, while the production path consumes the gate decision and discards scan details.Persisting statuses, action, and comments in a governance-only, non-searchable security_scan field remains a design property, not production behavior.Source: D Security and Privacy Gate · p. 13
D.1 Offline Functional Sanity Check
The paper reports an offline functional check of the deployed gate on synthetic cases, alongside a description of the retrieval interfaces. Most executions matched expected behavior or were cautious without blocking, while the results do not establish a general security guarantee.
D.1 Offline Functional Sanity Check
- The controlled synthetic check used one configured LLM and does not establish robustness to adaptive attacks, production data, or the full range of security defects.The authors describe it as a functional sanity check rather than a security benchmark and call for continued calibration and production monitoring.Source: §D.1 · pp. 13, 16
- The 56-case suite comprised 33 risk-seeded memories and 23 benign controls across five security-relevant categories, without a separate adversarial grounding evaluation.The categories include dependencies, secrets, unsafe code, personal or internal information, and unsafe workflows.Source: §D.1 · p. 14, Table 5 · p. 14
- 80.4% of 168 executions showed expected behavior, 19.0% were cautious but non-blocking, 0.6% were overcautious, and none was an unsafe acceptance.The practical outcome table covers three complete executions of the 56-case suite.Source: §D.1 · p. 15, Table 7 · p. 15
- Among 99 risk-bearing executions, 87 were appropriate and 12 cautious but non-blocking; among 69 benign executions, 68 remained persistable and 20 received cautionary text.The 33 risk-bearing and 23 benign cases were each run three times.Source: §D.1 · p. 15
- Across three runs, exact persistence actions matched for 37 of 56 cases (66.1%), while practical safety classifications matched for 43 of 56 (76.8%).Practical classifications group actions with the same safety effect.Source: §D.1 · p. 15
E Retrieval Interfaces
- Fast retrieval combines tag matching, query embedding, and hybrid multi-vector search; Normal expands the pool and reranks results.The serving layer also provides Deep Research for iterative search, link following, and cited synthesis.Source: E Retrieval Interfaces · p. 16, Table 8 · p. 16
- Deep Research iteratively searches questions and answers, follows links, and synthesizes a cited response; read_memory resolves links for graph traversal.MCP also exposes query, read_memory, and feedback functions.Source: E Retrieval Interfaces · p. 16
F Trust Score Computation
The trust score combines deterministic evidence from examples, caveats, and recency with Bayesian agent and human feedback. Its prior dampens the effect of a few early votes, while authenticated voting limits repeat votes per identity.
F Trust Score Computation
- A working example, caveats, recency, agent feedback, and human feedback contribute to a 0–10 trust score; the first three are deterministic and the feedback components Bayesian.Recency earns its full point for 30 days, then decays linearly to zero by 730 days.Source: F Trust Score Computation · p. 17
- Each feedback component scales its maximum by a Bayesian average of observed upvotes and a prior, with the prior mean set to 0.5 and weights of 10 for agent votes and 3 for human votes.With no votes, the component returns the prior mean times its maximum.Source: F Trust Score Computation · p. 17
- Four unanimous votes move the example’s score from 7.0 to only 7.71, while authenticated serving limits each identity to one vote per memory in each channel.This illustrates prior damping; coordinated abuse across authenticated identities still requires monitoring.Source: F Trust Score Computation · p. 17