AWS AgentCore and AWS-native Knowledge Context Layer

Research Question

What Amazon Web Services (AWS) AgentCore capabilities and AWS-native services are required to design and operate a Knowledge Context Layer (KCL) that continuously acquires, curates, evolves, and serves enterprise knowledge to Artificial Intelligence (AI) agents through ontologies, knowledge graphs, GraphRAG (Graph Retrieval-Augmented Generation), and governed interfaces, and what are the concrete architectural patterns, integration points, and operational constraints for implementing that layer at regulated enterprise scale?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

A Knowledge Context Layer (KCL) built on Amazon Web Services (AWS) composes into three distinct deployable tiers rather than one AWS-native design, and the fully managed tier (Amazon Bedrock Knowledge Bases with Amazon Neptune Analytics GraphRAG (Graph Retrieval-Augmented Generation)) trades away customer-supplied ontology control and non-Amazon Simple Storage Service (Amazon S3) source connectivity for zero-infrastructure operation. Amazon Bedrock AgentCore supplies the governed-serving and memory layers around whichever Knowledge Base tier is chosen, through Gateway's tool/operation/parameter-level access control and Memory's session-scoped and cross-session state. Gateway governs agent-to-tool access while AWS Lake Formation and Knowledge Base Access Control List (ACL) filtering separately govern data-layer access, and the two layers must be designed together because neither substitutes for the other. Enterprises needing a predefined, customer-controlled ontology rather than an auto-extracted graph schema must leave the fully managed feature and use either a self-provisioned Amazon Neptune Database with an external retrieval framework or AWS Labs' open-source graphrag-byokg package, because the managed feature explicitly disallows graph-build customization. The managed feature's seven-Region availability footprint is the binding constraint that forces this same choice on any enterprise with a data-residency mandate outside those Regions, independent of its ontology preference.

Key Findings

1. Amazon Bedrock Knowledge Bases splits into Managed and Customer-managed modes with materially different governance capability: only the Managed mode provides native connectors (Amazon S3, SharePoint, Confluence, Google Drive, OneDrive, web crawler), document-level ACL-based permission filtering at retrieval time, and native integration with AgentCore Gateway.
2. The fully managed GraphRAG feature, which pairs Bedrock Knowledge Bases with Neptune Analytics, supports only Amazon S3 as a data source, disallows customization of the graph-build configuration, does not autoscale the underlying Neptune Analytics graph, and caps each data source at 1,000 files by default.
3. Managed GraphRAG is available in only seven AWS Regions (Frankfurt, London, Ireland, Oregon, N. Virginia, Tokyo, Singapore), while Amazon Neptune Database itself operates in over 30 Regions including the Middle East, Israel, Africa, and AWS GovCloud (US), so data-residency-constrained enterprises outside those seven Regions cannot use the managed GraphRAG feature at all.
4. AWS Labs publishes an open-source graphrag-toolkit containing graphrag-byokg, a package purpose-built for question-answering over a customer's own pre-existing knowledge graph, which is the closest AWS-native path to a predefined-ontology GraphRAG pattern given that the managed Bedrock feature explicitly excludes graph-build customization.
5. AgentCore Gateway enforces access control at four distinct levels, gateway, tool, operation, and parameter, using either REQUEST interceptors validating JSON Web Token (JWT) claims, Open Authorization (OAuth) authentication, or Cedar-policy IAM principal matching, and it separately handles both ingress (verifying caller identity) and egress (injecting downstream credentials) authentication in one managed service.
6. AgentCore Memory and Bedrock Knowledge Bases serve different, complementary roles rather than being substitutable: Memory persists what a specific agent has learned about a user or task across sessions, while Knowledge Bases serves durable, shared enterprise source-of-record content, so a Knowledge Context Layer's governed enterprise knowledge belongs in Knowledge Bases with Memory layered on top for personalization.
7. Bedrock Knowledge Base data-source syncing is incremental at the document level, meaning only added, modified, or deleted files since the last sync are re-parsed and re-embedded, and metadata-only changes to a .metadata.json file can sync without re-embedding the associated content, but the underlying StartIngestionJob API call still processes the entire data source per invocation rather than accepting a targeted file list.
8. Continuous curation on AWS is implemented as an event-driven pipeline, not a dedicated curation service: Amazon S3 Event Notifications routed through Amazon EventBridge trigger AWS Lambda functions that call the Knowledge Base ingestion API, with Amazon SQS, Amazon SNS, and AWS Step Functions added to respect per-data-source ingestion-job concurrency limits.
9. Amazon Neptune is a Virtual Private Cloud (VPC)-only service requiring Transport Layer Security (TLS) 1.2 for all connections, and Amazon Bedrock AgentCore separately supports AWS PrivateLink interface VPC endpoints for Gateway, Runtime, and tool traffic, together enabling an end-to-end private-network deployment for both the graph store and the agent runtime.
10. Amazon Neptune's 2024 engine version 1.3.2.x delivers up to 9 times faster low-latency openCypher query performance and up to 10 times higher openCypher throughput than prior versions, a query-language-specific improvement that AWS's own blog post does not claim extends equally to Gremlin or SPARQL Protocol and RDF Query Language (SPARQL) queries.
11. AWS Lake Formation adds fine-grained column-, row-, and cell-level access control and tag-based access control (TBAC) over data cataloged in AWS Glue, with a hybrid access mode that lets administrators onboard Lake Formation permissions incrementally alongside existing IAM permissions on the same catalog.
12. A prior repository evaluation of hosted ontology-first graph databases found that Stardog Cloud and Ontotext GraphDB provide stronger native ontology reasoning capability than the evidence located for Neptune in this investigation, which surfaced no equivalent native Web Ontology Language (OWL) inference engine for Neptune, making formal-ontology-reasoning requirements a genuine reason to look outside the AWS-native services examined here.

Assumptions

• The absence of a published numeric sync-latency Service Level Agreement (SLA) is treated as an operational-predictability gap rather than a documented guarantee of either fast or slow sync behavior; only the event-driven design intent to minimize lag is documented.
• A given Amazon Neptune Database cluster is assumed to be provisioned for one graph-model family (property graph or Resource Description Framework (RDF)) at a time rather than exposing both a property-graph and a SPARQL endpoint concurrently, because the consulted documentation phrases the choice as "or" without stating whether concurrent dual-model access on a single cluster is possible.
• The three-tier decision structure in Analysis (fully managed, customer-managed Neptune Database, graphrag-byokg) assumes that an enterprise's data-residency, ontology-control, and connector requirements can be evaluated independently and then combined, whereas in practice a single enterprise may need to satisfy multiple constraints simultaneously, which the located sources do not model as a joint decision.

Analysis

The evidence separates two governance surfaces that must be designed independently: agent-to-tool access, controlled by AgentCore Gateway's interceptor and Cedar-policy mechanisms, and data-layer access, controlled by Knowledge Base ACL filtering or Lake Formation depending on which acquisition path is used. A design that only implements Gateway-level policy while leaving an incoherent source-system permission estate untouched inherits the weaker of the two, because Gateway can restrict which agent may call a Knowledge Base tool but cannot repair document-level permission errors coming from the source system itself.

The managed-versus-hybrid trade-off is not a single binary choice but three separable constraints that happen to point the same direction in several common enterprise scenarios. Ontology control, non-S3 source connectivity, and Region availability each independently rule out the fully managed GraphRAG tier for a meaningfully sized subset of enterprises: those requiring a predefined schema, those whose content lives outside S3-reachable connectors, and those operating exclusively in Regions outside the seven supported ones. Where an enterprise's requirement is specifically formal ontology reasoning, for example Web Ontology Language (OWL)-based inference over a domain ontology, the rival explanation from a prior repository item, that a dedicated ontology-first hosted graph database outperforms Neptune on this specific dimension, is a stronger fit than any of the three AWS-native tiers examined here, and should be weighed against the integration cost of operating a non-AWS-native graph store behind AgentCore Gateway. This item does not resolve that trade-off, because it falls outside the AWS-native scope, but the evidence gathered here establishes that Neptune's documented strengths lie in query throughput and managed operations rather than in native ontology reasoning, which is a narrower claim than "Neptune is the ontology solution for AWS."

The sync-incrementality tension identified in §2 and §4 (document-level incrementality claimed by official docs versus whole-data-source API scope claimed by the AWS sample repository) is resolved as two facts about different layers rather than a genuine contradiction, but it has a practical consequence: an automation pipeline built only on the official incrementality claim, without reading the sample repository's operational note, could under-provision for the cost and duration of a StartIngestionJob call on a large data source, because that call re-scans the entire source even though only changed content is re-embedded.

This item's finding that "neither Bedrock Knowledge Bases nor AgentCore exposes a dedicated 'curation' service" (§2.1.2) is a gap when weighed against a prior repository item's regulated-enterprise governance requirement that authoritative knowledge for AI follow an intake, validation, publication, correction-to-source, and retirement-or-recertification lifecycle with logs and version metadata proving what changed and when. Amazon EventBridge-triggered re-sync, the mechanism this item identifies as AWS's substitute for a dedicated curation service, satisfies only the "publication" step of that prior lifecycle model directly; it provides no native validation gate before content becomes queryable, no correction-to-source workflow, and no explicit retirement-or-recertification state, so a regulated enterprise adopting the AWS-native pattern in this item would need to layer the prior item's governance lifecycle on top of Knowledge Base sync rather than treat sync automation as a substitute for it.

Risks, Gaps, and Uncertainties

• No consulted source states a numeric sync-latency SLA for Bedrock Knowledge Base ingestion jobs, so enterprises cannot plan freshness guarantees against a published figure and must instead measure latency empirically in their own environment.
• Whether a single Amazon Neptune Database cluster can expose both a property-graph endpoint (Gremlin/openCypher) and a SPARQL endpoint concurrently, or whether the choice is exclusive per cluster, is not resolved by the consulted documentation and would require a direct AWS support inquiry or hands-on cluster configuration test to confirm.
• The Neptune engine 1.3.2.x throughput improvement is quantified only for openCypher; no located source quantifies an equivalent improvement, or its absence, for Gremlin or SPARQL query performance on the same engine version, so applying the 9x/10x figures to non-openCypher workloads would be unsupported.
• No AWS re:Invent or re:Inforce 2024/2025 session recording specific to knowledge graphs and agents was located during this investigation; the seeded source pointed to a general channel search rather than a specific session Uniform Resource Locator (URL), so session-level architectural guidance beyond written documentation and blog posts is a genuine gap in this item's evidence base.
• The AWS Labs graphrag-byokg package was evaluated only at README depth; no consulted source documents its production maturity, adoption evidence, or a direct comparison against the customer-managed Neptune Database plus external-framework pattern, so its practical viability as an enterprise-grade tier relative to the other two tiers remains unverified.
• This item does not independently re-verify the three cross-referenced prior-item claims (Stardog/GraphDB ontology strength, TBox seed-schema advantage, permission-safe RAG precondition); those claims carry the confidence levels assigned in their originating items and are cited here as context rather than as newly validated findings.
• No consulted AWS source describes a validation gate, correction-to-source workflow, or explicit retirement-or-recertification state for content ingested through Bedrock Knowledge Base sync, so this item's AWS-native curation pipeline covers only the "publication" step of the governance lifecycle a prior repository item establishes for regulated-enterprise knowledge, and a regulated deployment would need to build the remaining lifecycle stages outside the AWS services examined here.

Open Questions

• Can a single Amazon Neptune Database cluster expose both property-graph and RDF/SPARQL query access concurrently, and if not, what is the operational cost of running parallel clusters for enterprises needing both access patterns over the same underlying knowledge?
• What quantified sync latency, in wall-clock time from source change to queryable Knowledge Base update, do enterprises observe in production for data sources of varying size, and does this vary meaningfully between the Managed and Customer-managed Knowledge Base modes?
• How mature and production-adopted is AWS Labs' graphrag-byokg package relative to the customer-managed Neptune Database plus external-framework pattern, and are there documented enterprise deployments to evaluate against?
• What is the actual cost differential between the three deployment tiers (fully managed GraphRAG, customer-managed Neptune Database, graphrag-byokg-based custom pipeline) at a defined enterprise scale, since this item found operational and capability differences but no side-by-side cost benchmark?
• Does AWS publish or plan to publish a Neptune engine throughput benchmark for Gremlin and SPARQL comparable to the openCypher-specific 2024 figures, and if not, how should enterprises using those query languages estimate expected throughput gains from engine upgrades?

sources

• [x] AWS Bedrock Knowledge Bases documentation: primary reference for managed vs. customer-managed Knowledge Base capabilities, connectors, and document-level Access Control List (ACL) filtering
• [x] AWS Neptune documentation: graph database overview: primary reference for RDF/property-graph hosting on AWS
• [x] Amazon Neptune Limits: VPC-only requirement, Transport Layer Security (TLS) requirement, storage/replica/payload limits
• [x] AWS Neptune Analytics documentation: Neptune Analytics graph-RAG and in-memory analytics surface
• [x] Build a knowledge base with Amazon Neptune Analytics graphs: managed GraphRAG mechanics, Region availability, and documented limitations (Uniform Resource Locator (URL) corrected/added; not in the originally seeded Sources list but the direct authoritative page for the item's central GraphRAG claims)
• [x] What is Amazon Bedrock AgentCore?: AgentCore service catalog overview (URL corrected from the seeded agents-overview.html, which is a Bedrock Agents page, not the AgentCore devguide root)
• [x] Add memory to your Amazon Bedrock AgentCore agent: AgentCore Memory short-term/long-term mechanics
• [x] Amazon Bedrock AgentCore Gateway: Gateway capabilities and Model Context Protocol (MCP)/Agent-to-Agent (A2A) tool-conversion mechanics
• [x] Fine-grained access control for Amazon Bedrock AgentCore Gateway: interceptor- and Cedar-policy-based access control levels
• [x] Provide identity and credential management with Amazon Bedrock AgentCore Identity: workload identity and credential-provider mechanics
• [x] Observe your agent applications on Amazon Bedrock AgentCore Observability: CloudWatch/OpenTelemetry-based audit and monitoring surface
• [x] Protecting your data using VPC and AWS PrivateLink: private connectivity options for AgentCore Runtime, Gateway, and tools
• [x] Using knowledge graphs to build GraphRAG applications with Amazon Bedrock and Amazon Neptune: AWS Database Blog customer-managed Neptune Database + LlamaIndex reference pattern (replaces the seeded generic blog-index URL with the specific post)
• [x] New Amazon Neptune engine version delivers up to 9 times faster and 10 times higher throughput for openCypher query performance: Neptune engine 1.3.2.x openCypher throughput data
• [x] AWS prescriptive guidance: enterprise-ready generative AI platform: AWS-curated best practices for enterprise-scale Bedrock deployments
• [x] Prerequisites for using a vector store you created for a knowledge base: vector store integration reference (URL corrected from the seeded knowledge-base-setup-oss.html, which redirects here)
• [x] AWS Glue documentation: Extract, Transform, Load (ETL) pipeline service for data ingestion into the KCL
• [x] AWS Lake Formation: data governance: fine-grained data access controls relevant to governed knowledge interfaces
• [x] Sync your data with your Amazon Bedrock knowledge base: incremental sync mechanics (added; the specific page underlying the item's continuous-curation sub-question)
• [x] Amazon Bedrock Knowledge Base Auto-Sync Solution: AWS-authored open-source event-driven ingestion reference architecture (added)
• [x] awslabs/graphrag-toolkit: AWS Labs open-source lexical-graph and bring-your-own-knowledge-graph (BYOKG-RAG) packages (added; the AWS-native answer to customer-controlled ontology GraphRAG)
• [ ] AWS re:Invent 2024 / 2025 session recordings on knowledge graphs and agents: identified but not consulted; the seeded URL is a general channel search rather than a specific session, and no individual session on this exact topic was located during this investigation