Context intelligence for AI agents: AWS turns metadata into a product for safer AI automation

• TL;DR
• AI models are fast; context is the safety harness that keeps them correct, compliant, and useful in production.
• AWS Context (coming soon) builds an organizational knowledge graph and exposes agentic search so AI agents can query governed relationships, business rules, and runbooks at runtime.
• Key design moves—publishing metadata as Apache Iceberg on S3, identity‑aware queries via IAM/Lake Formation, and S3 Annotations—focus on portability, governance, and operational discoverability for AI agents.
• Run a focused pilot (6–10 weeks) with skill assets, annotated objects, and clear KPIs before scaling across the enterprise.

AI agents are only as intelligent as the context they can reason over. Models generate outputs quickly; what often breaks deployments is fragmented context—undocumented business rules, disconnected runbooks, and inconsistent permissions. AWS has productized that contextual layer so agents can access trusted, auditable inputs when they act.

Why context matters for AI agents

Think of agents as drivers and context as the road signs, traffic rules, and the map. Without them, even a high‑performance engine takes risky turns. For enterprises, the stakes include compliance failures, automated operational mistakes, and audit gaps. Context spans three things: discoverability (where is the data?), semantics (what does this field mean?), and procedures (how should the agent act?).

Definitions for busy readers:

• Knowledge graph: a structure that maps relationships between business entities (customers, contracts, invoices) so systems can traverse meaningfully connected data.
• Agentic search: search optimized for autonomous agents that need to discover, traverse, and join domain knowledge at runtime.
• Apache Iceberg: an open table format that stores metadata in a way that makes it portable and queryable across engines.
• IAM / Lake Formation: identity and data‑access controls that ensure queries run under the right permissions and remain auditable.

What AWS Context actually does

AWS Context (announced at AWS Summit NYC) automatically maps relationships across your data into an organizational knowledge graph and exposes agentic search APIs so AI agents can discover governed relationships, business rules, and domain knowledge at runtime. The underlying graph extends the same production tech used by Amazon Quick, which already handles heavy production traffic—an important signal for reliability in live workflows.

The offering is not a single product but a stack:

• AWS Context: builds and serves the knowledge graph and agentic search APIs.
• Glue Data Catalog enhancements: business context, semantic search, and new “skill assets” that point to domain runbooks and instructions.
• Amazon S3 Annotations (generally available): attach up to 1 GB of rich, mutable metadata per S3 object and expose it as Iceberg tables for query by agents.
• Agent tooling and integrations: AWS Agent Toolkit, AgentCore, MCP compatibility, and plugins for third‑party agents (examples include Claude Code, Cursor, and Amazon Kiro).

AI agents are only as intelligent as the context they can reason over—and AWS Context is designed to give agents that governed context at runtime.

Portability: Iceberg on S3 matters

One of the clearest architecture choices is publishing key metadata and annotations to Amazon S3 in Apache Iceberg format. That means context isn’t trapped inside a proprietary API; teams can query metadata with Athena, Redshift, Spark, or any Iceberg‑compatible engine. In practical terms, it reduces migration friction and makes audit trails easier to extract for external tools.

Governance: identity‑aware, auditable access

Every agent query inherits the calling user’s IAM and Lake Formation permissions, so agents can only traverse data they’re authorized to see. Queries and traversals are auditable—critical for compliance-heavy industries. This identity‑aware model mitigates a major adoption blocker: CIOs and compliance teams can see who asked what and why an agent made a decision.

Operational features that speed adoption

Three operational pieces lower the bar to entry:

• Skill assets in Glue Data Catalog: pointers to runbooks, playbooks, or code (S3 URIs, git, wikis) that agents can fetch progressively as they act. Agents get rules plus the how‑to.
• S3 Annotations: attach rich, mutable context to objects that travels with the object and becomes queryable via Iceberg tables.
• Prebuilt agent toolkits and plugins: connectors that let popular agent frameworks and Bedrock AgentCore query the graph without building bespoke plumbing.

Context that learns (but needs stewardship)

The graph observes agent queries and usage, ranking sources, join paths, and curated rules based on what produces correct results. That learning loop helps useful patterns propagate without full manual re‑curation. Still, fully automatic promotion of inferred relationships risks propagating errors—domain stewards and governance workflows must remain in the loop.

Three quick vignettes

Procurement — An agent preparing purchase orders checks supplier contracts, supplier risk scores, and procurement runbooks before executing. Skill assets provide the approval flow; identity‑aware access ensures the agent can’t see confidential sourcing data it shouldn’t.

Finance close — A close‑automation agent retrieves reconciliation rules and the latest policy doc (annotated on relevant S3 objects), applies them, and records provenance for every posting, reducing manual review time and improving audit trails.

Customer support — An agent triages escalations by joining CRM entities, contract SLAs, and prior cases surfaced via the knowledge graph; skill assets point to escalation playbooks the agent should follow before escalating to a human.

Tradeoffs and open questions

Useful, but not magic. Key considerations for decision makers:

• Automated inference speeds curation but can surface incorrect joins—plan for human validation and rollback paths.
• Iceberg aids portability, yet true cross‑cloud portability depends on ecosystem adoption and integration parity.
• Costs and latency will vary with annotation volume and query load—bench these in a pilot. Expect to balance depth of annotations with cost per query.
• Operational complexity: instrument provenance, mutation tracking, and lifecycle rules for annotations and skill assets.

Pilot checklist (6–10 weeks) and KPIs

• Scope: choose one business domain (procurement approvals, finance close, or one escalation workflow).
• Assets: attach 5–10 skill assets; annotate ~100 representative S3 objects with S3 Annotations.
• Validation: get 2 domain stewards to review inferred joins and sign off on the canonical mappings.
• Integration: connect an existing agent (Bedrock AgentCore / Agent Toolkit or a third‑party agent) to agentic search APIs.
• Duration: 6 weeks build + 2–4 weeks live testing under constrained load.
• KPIs to track:
  • Accuracy: % of agent actions judged correct by domain stewards (target: >90% for core flows).
  • Audit completeness: % of actions with full provenance logged (target: 100%).
  • Latency: median agentic search latency under test load (target depends on workflow; aim <500ms for interactive).
  • Cost: $ per 1,000 agent queries and storage cost for annotations (monitor to scale economically).
  • MTTR: mean time to remediate incorrect agent decisions (goal: measurable reduction versus manual process).
• Rollout trigger: >90% accuracy, acceptable latency under expected load, and business sign‑off on governance flows.

How AWS Context compares to other approaches

Options leaders typically evaluate:

• Homegrown graph + connectors: flexible but expensive to maintain; slow to mature and often lacks agent integrations or production SLAs.
• Vendor products like AWS Context: faster time‑to‑value, built‑in governance and Iceberg portability; tradeoff is ecosystem dependency—even though Iceberg mitigates some lock‑in.
• ChatGPT or LLM connectors: useful for prototyping; less suitable for production agentic workflows that require fine‑grained access control, auditable provenance, and runbook execution.

Key questions for leaders

• What does AWS Context do for AI agents?
  

  AWS Context constructs an organizational knowledge graph and provides agentic search so agents can access governed relationships, business rules, and domain knowledge at runtime.

• How is metadata kept portable and queryable?
  

  Key metadata and annotations are published to Amazon S3 using Apache Iceberg, enabling queries via Athena, Redshift, Spark, or any Iceberg‑compatible engine.

• How is access and compliance enforced?
  

  Each agent query runs with the identity and permissions of the triggering user via IAM and Lake Formation, and interactions are auditable.

• How do agents get domain procedures and runbooks?
  

  Glue’s “skill assets” point to URIs (S3, git, wikis) so agents can fetch domain instructions progressively while executing.

• Do I have to build new pipelines?
  

  No. Teams can enable features and start curating context from the AWS Management Console without building bespoke ingestion pipelines, though validation and governance workflows are recommended.

What to do next

Start with a narrow pilot. Pick a revenue‑critical or compliance‑sensitive workflow, attach skill assets and a handful of annotations, and measure the KPIs listed above. Validate inferred relationships with domain stewards and stress‑test agentic search for latency and cost. If the pilot meets accuracy and auditability thresholds, broaden to adjacent workflows.

Context intelligence is now infrastructure. The teams that treat metadata, runbooks, and identity‑aware controls as strategic plumbing will get safer, faster returns from AI agents—and avoid the classic trap of building clever models that can’t be trusted in production.