Your organization learns. Does it remember?

Summary: OMG is a proposed organizational memory graph that connects decisions, people, systems, dependencies, and outcomes across an organization's existing tools. It could help teams preserve institutional knowledge and give approved AI assistants governed company context. OMG is described as a product vision, not a claim that every proposed component is production-ready or generally available.

• As a company grows, important decisions and hard-won lessons get spread across people and tools. Teams can end up repeating work or spending time piecing together what happened before.
• OMG is a proposed shared memory layer that links knowledge across a company's tools and makes it easier for people—and, where appropriate, AI assistants—to find relevant context.
• The opportunity: help growing teams preserve institutional knowledge, reduce avoidable rediscovery, and give decision-makers a clearer picture of how work and systems connect.
• The sections below explain who could benefit, the product vision, and the components being explored. Technical details are optional.

In a small team, people can often ask one another why a decision was made. As a company adds teams, locations, products, and partners, that shared understanding becomes harder to maintain.

The result is familiar well beyond technology: the same research is repeated, handoffs take longer, plans lose their original rationale, and a few key people become the only source of institutional memory.

Consider a startup that changes a core platform decision after a painful outage. The reasoning is documented, but months later a new team revisits the same choice without knowing the earlier trade-offs. People spend time rediscovering the constraints, and the company carries avoidable risk while it catches up.

This is not simply a documentation problem. The relevant story may be spread across conversations, project tools, code, support cases, and the people who were there.

The challenge is becoming more visible as businesses adopt AI tools. An assistant can generate answers quickly, but without company-specific context it may miss the decisions, policies, and experience that make an answer useful.

OMG explores whether organizational memory can become shared infrastructure rather than staying scattered across tools and individuals.

Where the cost shows up

1. People changes. When someone changes roles or leaves, the background behind their decisions can be difficult to transfer.
2. Growth and handoffs. As teams multiply, information that once travelled informally can get lost between departments, offices, or partner organizations.
3. AI without company context. General-purpose assistants may not know an organization's choices, constraints, and ways of working unless that context is made available.

A shared, permission-aware memory could help address these challenges by connecting information as work happens and making relevant context easier to retrieve when a decision is being made.

OMG stands for Organizational Memory Graph — a living, queryable, connected model of the people, decisions, tools, and events that shape how an organization works.

Imagine being able to follow the story behind a business-critical decision: what prompted it, which teams and systems it affected, and what the organization learned afterward. OMG is a product vision for making those connections easier to preserve and use.

In practice, the concept is to connect selected information from the tools a company already uses, organize it by relationships and history, and make that context available to people and approved software assistants. The aim is not to replace a team's existing systems, but to help them work together more meaningfully.

What this idea is—and is not

• Not a replacement for people. Shared context can support judgment and handoffs; it cannot capture every nuance or replace conversation.
• Not just another document store. The distinctive idea is linking information—such as decisions, projects, owners, systems, and outcomes—so it is easier to understand in context.
• Not a rip-and-replace project. The vision is to connect with the tools an organization already relies on, subject to its needs and permissions.
• Not a claim that every answer is automatic. Useful results depend on data quality, integrations, governance, and whether the system can explain where its information came from.

The core idea is simple: help an organization retain useful context as it grows. The value looks different depending on where you sit.

The names below describe parts of the OMG product vision, not requirements for a customer to learn before understanding the idea. In plain language: collect useful signals, connect them into context, and make that context available in the moments it can help. The architecture and delivery status should be evaluated component by component.

Modern systems rely on many package managers, ecosystems, and repositories. UDM is envisioned as a consistent dependency layer across them: discover what is used, understand how it was resolved, and make changes with a view of where those dependencies matter.

UDM complements existing package managers rather than requiring a single ecosystem. It links dependency manifests and lock state to the organizational graph, so a package update can be understood in terms of code ownership, affected services, build history, and prior incidents.

If OMGDB is the memory and OMGQL is the query language, OCE is the active agent that puts that memory to work.

OCE continuously monitors the organizational memory graph and surfaces context at the moment of decision. It is not a search engine that waits for queries. It is a proactive system that pushes context into workflows.

OCE in code review

A PR modifies services/payments/processor.go. OCE notices that this file has been involved in three past incidents. It surfaces the incident summaries and the patterns that preceded them, inline in the review interface:

📎 Context for services/payments/processor.go

  Recent incidents:
    INC-4821 (2024-03-14) — race condition in retry logic
      Root cause: unbounded retry loop
      Fix: exponential backoff with jitter
    INC-4192 (2024-01-08) — timeout under load
      Root cause: shared connection pool exhaustion
      Fix: per-tenant pool isolation
    INC-3871 (2023-11-22) — duplicate charge on retry
      Root cause: missing idempotency key
      Fix: idempotency key + dedup table

  Suggested reviewers with context:
    @alice  (authored 12 changes here, reviewed 34)
    @bob    (fixed INC-4821, owns retry logic)
    @carol  (on-call during INC-4192)

  Pattern warning:
    This diff introduces a retry loop without a backoff cap.
    Similar pattern preceded INC-4821.

OCE during on-call

An alert fires for the payment service. Instead of a blank incident screen, the on-call engineer sees a context card:

🚨 ALERT: payment-processor p99 latency > 2s

  Recent changes (last 24h):
    • Commit 4f8a2c1 (2h ago) by agent:claude-reviewer — retry logic refactor
    • Deploy v3.14.2 (1h ago) — canary at 25% traffic

  Owning team: platform-payments (4 engineers)
    On-call: @dave (paged)
    Escalation: @alice (owns retry logic)

  Dependency health:
    • postgres-primary: healthy
    • redis-sessions: p99 elevated (+180ms vs baseline)
    • billing-api: healthy

  Prior incidents with this signature:
    INC-4821 — similar latency spike, root cause: retry storm
    Suggested diagnostic: check retry loop counts in payment-processor

  Runbook: platform-payments/latency-spike.md

OCE for AI agents

An autonomous agent is asked to fix a failing test. Before it acts, OCE enriches the request with organizational context:

Agent request: "Fix failing test TestRetryOnTimeout"

OMG context injected:
  • This test is flaky (flakiness score: 0.34, last 90d)
  • 4 prior fixes attempted:
      PR #8812 — increased timeout (reverted)
      PR #8934 — mocked clock (accepted, then regressed)
      PR #9112 — refactored retry loop (accepted)
      PR #9876 — added jitter (current, failing)
  • Owning engineer: @bob (owns retry logic in payments)
  • Related incident: INC-4821 (retry storm)
  • Similar pattern in codebase: services/billing/retry.go

Suggested action: The prior accepted fix (PR #9112) refactored
the retry loop. The current failure may be a regression of that
refactor. Consider reviewing the diff between PR #9112 and the
current HEAD before attempting a new fix.

This is the difference between a smart agent and a wise one. The agent has the same capability either way. But with OCE, it has the context a senior engineer would bring.

These are hypotheses about where connected organizational memory could help. What matters most will vary by company and should be tested with real teams.

A useful pilot should begin with a baseline and a clear question. These are candidate measures—not reported results or guaranteed improvements:

1. AI is entering more workflows. As companies experiment with assistants, the quality and governance of the information those systems use becomes more important.
2. Organizations are more distributed. Teams, partners, and systems change over time, while important decisions and their rationale can remain scattered.
3. Companies need accountable use of information. Better access to context must be balanced with permissions, privacy, security, and clear explanations of where information came from.

The vision is to help existing tools share context—not ask an organization to replace everything at once. Specific integrations, availability, and compatibility need to be confirmed for each use case.

• Project and collaboration tools — places where teams coordinate work. OMG could connect relevant activity and decisions.
• Build and delivery tools — systems that help create and release software. Their outcomes could add operational context.
• Planning and issue tools — where teams record work, priorities, and decisions.
• Support and incident tools — where customer issues and operational events are tracked.
• Analytics and monitoring tools — signals that help teams understand product and service health.
• Search and AI tools — potential ways to find and use approved company context.
• Documents and knowledge bases — the narrative records people create. OMG is intended to connect these with relevant activity and history, not make them irrelevant.

OMG is a product vision under development. The components below describe the proposed direction; this article does not imply that every capability is available today. Ask the team about current releases, evidence, and an appropriate pilot before making a purchasing or investment decision.

For a startup, a client, or an enterprise, a sensible first step is to identify one recurring handoff or decision that is costly today. Define who can access the relevant information, agree on how success will be measured, and test a small, low-risk use case.

These are proposed milestones, not committed release dates. Priorities and timing should change as customer needs, technical feasibility, and validation become clearer. Confirm current status with the team.

Foundation

• Validate the core memory and search use cases with design partners
• Explore integrations with tools teams already use
• Test dependency visibility and reproducible resolution with UDM

Product development

• Evaluate clear, usable experiences for exploring connected context
• Assess governance, privacy, security, and deployment requirements
• Determine whether related build and version-control concepts solve real customer needs

Evidence and scale

• Measure customer outcomes against agreed baselines
• Publish case studies and benchmarks when there is sufficient evidence
• Expand only where reliability, trust, and product-market fit are demonstrated

We are interested in hearing from startups and organizations that want to explore this problem and help shape a practical solution.

Integration priorities should follow partner needs and be confirmed before a pilot is scoped.

The opportunity is to help organizations keep what they learn accessible as people, products, and tools change. Whether OMG can deliver that reliably is a question to answer through customer validation.

Your organization already learns. The opportunity is to make those lessons easier to carry forward.

Make experience easier to find, share, and build on.

If you are a founder thinking about scale, a business evaluating knowledge tools, an investor exploring the category, or simply curious about the idea, start a conversation. We welcome practical questions and candid feedback.