--- title: Knowledge Agent description: The data layer that makes every other agent honest — join keys across orders, customers, products, and inventory. Not a generic research agent. Not a warehouse copilot. url: https://www.factualminds.com/ai-agents/knowledge/ publishDate: 2026-08-31 updateDate: 2026-08-31 --- # Knowledge Agent > If orders, customers, products, and inventory cannot be joined, an agent will guess. This is the contract that stops the guess — not a chatbot over your lakehouse. This page is the commercial summary for the **knowledge and catalog** family. It is not a generic research agent, not a chatbot over a data lake, and not a rewrite of the data-layer field-guide post. ## Catalog vs business data The [AI-ready product catalog](/blog/ai-ready-product-catalog-agentic-commerce-2026/) is the SKU contract shopping agents consume. This family is the **business** join: orders, customers, products, inventory, returns, support. If SKUs fail the catalog contract, fix that first. If an order cannot find its customer, stay here. ## What this is not - `/ai-agents/research/` or `/ai-agents/finance/` — those URLs are not in v1. - Unrestricted SQL with a chat window. - Amazon Bedrock as "the data layer." Bedrock is the model. The layer is your keys, your tools, and your as-of stamps. CTOs who want the runtime next can go to [Bedrock AgentCore](/services/amazon-bedrock-agentcore/) and the [agentic commerce pattern](/patterns/agentic-commerce-on-aws/). Operators who just need WISMO to tell the truth should stay on this page, then [customer support](/ai-agents/customer-support/). ## How we start One workflow. One join. Named reads. Then the [eCommerce AI Agents](/services/ecommerce-ai-agents/) engagement — or a readiness pass if the keys are not there yet. ## Problem Teams buy an agent runtime, then discover Shopify order ids, OMS ids, and WMS ids disagree; inventory is a nightly dump with no as-of; guest and account records duplicate the same shopper. The model treats a guessed join as a fact. A pretty dashboard is not a data layer. A SQL copilot on the warehouse is the anti-pattern. ## Agent A knowledge agent — and the data work underneath it — exposes named read tools over a join contract: orders, customers, products, inventory, returns, and support, with as-of on anything that moves. It answers "can these records be the same thing?" and flags quality breaks. It does not browse the web as a generic researcher, and it does not get unrestricted SQL. ## Workflow ### Pick one workflow join Usually WISMO: platform order id to OMS id. Document it. Do not boil the lakehouse first. ### Name the tools getOrder, getInventoryPosition, getCustomer — each with the keys it accepts. Reject rows that cannot join. ### Stamp as-of Inventory and price without a timestamp are how afternoon agents lie. Quality monitors watch the contract, not a vibe. ### Then host an agent Runtime comes after the join works. An agent on three identities for one order will invent causality in support, returns, and RCA. ## Systems ### Orders, customers, products, inventory The four domains every other family needs. Returns and support tickets join here or they stay unknown. ### Catalog contract Parent/child, identifiers, required attributes, checkout-true offer. Shopping agents and internal tools consume the same SKU truth. ### Quality monitors Break the join, fail the eval. Do not let the model fill a missing campaign id with a channel story. ## Approval Knowledge tools are reads. Writes to master data (merge customers, edit a SKU, overwrite ATP) are human-approved or they do not exist. PII leaves the payload unless identity policy allows it. ## Outcomes ### Other agents can tell the truth Support, inventory, and sales stop inventing joins. That is the outcome. It is not a research assistant for the exec team. ### A contract you can test Named keys, as-of stamps, and evals that fail when a tool returns two identities for one order. ### Catalog and ops share one picture Inbound shopping agents and internal tools read the same product and inventory facts. Fix the attributes once. ## Field-guide posts - /blog/ai-ready-ecommerce-data-layer-2026/ - /blog/ai-data-agent-ecommerce-2026/ - /blog/ai-product-catalog-management-ecommerce-2026/ - /blog/ai-agent-vs-workflow-automation-ecommerce-2026/ - /blog/human-in-the-loop-ai-agents-ecommerce-2026/ - /blog/ecommerce-ai-agent-readiness-assessment-2026/ ## FAQ ### Is this a research agent? No. We did not create /ai-agents/research/. This family is catalog quality, join keys, and named read tools for commerce data. A generic web-research agent is out of v1 scope. ### Do we need a lakehouse before the first agent? No. Pick one workflow, document one join, expose named read tools, stamp as-of on inventory and price. A warehouse copilot is the thing we are trying to avoid. ### Should we start with AgentCore or with the data layer? Join keys first. Hosting a loop that calls three tools returning three identities for one order spends platform money on a demo that cannot name a canonical order id. ### Do you have knowledge-agent case studies? Not yet. The data-layer, data-agent, and catalog-management field-guide posts are the published depth. AWS analytics cases on this site are not this product. --- *Source: https://www.factualminds.com/ai-agents/knowledge/*