Enterprise Knowledge Layer

Ten agents should not create ten versions of the business

Definitions copied into prompts, tools, and retrieval pipelines drift independently.

  • Private meaning: Each agent carries its own interpretation of the business.
  • Private routing: Each agent decides which source or tool is authoritative.
  • Private policy: Rules are repeated across prompts and integrations.
  • Silent drift: Every answer can sound reasonable while the enterprise loses a consistent view.

Same term, different meanings

"active customer"

Agent A → signed in within 30 days
Agent B → current paid contract
Agent C → open account balance
The problem: Copies change separately, so inconsistency grows with every new agent.

A shared Knowledge Layer makes connected context reusable

Keep meaning in one governed layer so every agent uses consistent definitions, relationships, and rules.

  • One shared layer: Maintain enterprise knowledge once and reuse it across consumers.
  • Connected context: Link concepts to data, policies, owners, and processes.
  • Current by design: Query the layer while work is happening instead of copying it into prompts.
  • Lighter agents: Keep task logic in the agent and enterprise meaning in the shared layer.

Enterprise knowledge becomes queryable and actionable

The Knowledge Layer is shared, governed, executable software that sits between enterprise systems and their consumers.

  • Shared: Reuse business meaning and operating knowledge across consumers.
  • Governed: Keep sources, policies, ownership, and accountability explicit.
  • Queryable: Retrieve the exact context required for each request.
  • Actionable: Map intent to authoritative sources, permitted tools, and executable queries.

Three components ground every request

Combine a governed model of the business, authoritative facts, and experience from previous work.

  • Knowledge Layer ontology: Defines what things mean, how they connect, where their data lives, what rules apply, and who is accountable.
  • Enterprise data: Supplies authoritative facts about what is true now.
  • Memory: Captures previous actions, decisions, outcomes, and reasoning.
Ontology holds what is possible; memory holds what is proven.

“Ontology” has a narrow and a broad meaning

The difference is scope: business meaning alone, or the larger connected model that makes that meaning operational.

Narrow: Conceptual Map

  • Defines what business concepts mean and how they relate.
  • Includes concepts such as Customer, Purchase, and Product.
  • Does not refer to Salesforce, tables, APIs, or other physical systems.

Broad: Knowledge Layer ontology

  • Connects five sub-ontologies: domain, technical, process, policy, and organization.
  • Includes descriptions of technical assets and mappings from business concepts to them.
  • Does not require the actual enterprise records to be stored in the ontology.
Both uses are valid: the Conceptual Map is the meaning; the broader Knowledge Layer ontology also connects that meaning to where the data lives.

The ontology connects meaning to systems and accountability

Five connected sub-ontologies describe how the business operates.

  • Domain: Business concepts and relationships.
  • Technical: Descriptions of systems, sources, and data assets, plus mappings from business concepts to those assets.
  • Process: Tasks, decisions, workflows, and actions.
  • Policy: Access rules, conditions, constraints, and permitted actions.
  • Organization: Roles, ownership, responsibilities, and accountability.

The semantic map bridges business meaning and enterprise data

It uses ontology concepts, technical asset descriptions, and mappings to route requests to authoritative source systems.

  • Domain ontology: Provides concepts such as “Customer,” “Purchase,” and “Product.”
  • Technical ontology: Describes systems and assets such as Salesforce and its Opportunity table.
  • Semantic map: Connects the two: PURCHASE → Salesforce.Opportunity.
  • Enterprise data: Supplies the actual opportunity records from Salesforce.
The semantic map tells agents what a request means, where to find the data, and how the two connect.

  • Business meaning: “Order amount” maps to orders.total_amount.
  • Known relationship: orders.customer_id references customers.id.
Why a graph: Stored relationships connect the meaning, the field, and the join in one map.

Every request becomes a governed action plan

The layer grounds the request. The agent or application executes the plan.

  • Interpret intent: Resolve the business meaning of the request.
  • Assemble context: Select authoritative sources and relationships.
  • Route queries and tools: Translate concepts into calls against AWS systems.
  • Enforce policy: Apply access and action rules during resolution.
  • Explain and learn: Return evidence and lineage, then retain useful outcomes.

Every governed action leaves an inspectable decision trace

The trace links a result to the context that produced it.

  • Meaning: Concepts resolved for the request.
  • Sources: Authoritative systems, queries, and lineage.
  • Policy: Access and action checks applied.
  • Evidence: Facts supporting the current result.
  • Precedent: Prior decisions, only when they influenced the result.
  • Outcome: The result or action, observed outcome, and feedback.

Decision traces explain the current result. Memory makes useful traces available to future requests.

A Context Graph connects knowledge and memory

It links enterprise knowledge and agent memory in one persistent, queryable graph.

  • Knowledge: Entities, relationships, business meaning, policies, and authoritative facts.
  • Memory: Previous interactions, actions, decisions, and outcomes that agents can reuse.
Each request retrieves relevant context and adds new memory. The graph persists and compounds across requests.

Source: /Users/ryanknight/projects/cloud-integration/knowledge-layer/reference/knowledge-layer-official.md

Source: /Users/ryanknight/projects/cloud-integration/knowledge-layer/reference/knowledge-layer-official.md

Source: /Users/ryanknight/projects/cloud-integration/knowledge-layer/reference/knowledge-layer-official.md

Source: /Users/ryanknight/projects/cloud-integration/knowledge-layer/reference/knowledge-layer-official.md

Source: /Users/ryanknight/projects/cloud-integration/knowledge-layer/reference/knowledge-layer-official.md

Source: /Users/ryanknight/projects/cloud-integration/knowledge-layer/reference/knowledge-layer-official.md

Source: /Users/ryanknight/projects/cloud-integration/knowledge-layer/reference/knowledge-layer-official.md

This illustrative path makes the graph concrete. A glossary term is linked to a column. That column belongs to a table. Another column on the same table carries a foreign-key reference to the customer table. The term mapping and foreign key must be loaded from a source or curated. They are stored facts for retrieval to follow. A missing relationship requires more source information or review. Search locates relevant entities and graph traversal supplies related details.

Source: /Users/ryanknight/projects/cloud-integration/knowledge-layer/reference/knowledge-layer-official.md

Source: /Users/ryanknight/projects/cloud-integration/knowledge-layer/reference/knowledge-layer-official.md

Sources: https://neo4j.com/blog/agentic-ai/what-is-context-graph/, https://neo4j.com/blog/agentic-ai/context-graph-ai-agent-memory/, and /Users/ryanknight/projects/cloud-integration/knowledge-layer/reference/knowledge-layer-official.md