--- title: Knowledge Agent description: Monday morning: support, recs, and a copilot each pull a different product id for the same order. A knowledge agent is the join contract — catalog facts and named read tools — not a research bot or a SQL copilot. url: https://www.joinhorizon.co/ai-agents/knowledge/ publishDate: 2026-09-22 updateDate: 2026-09-22 --- # Knowledge Agent > If orders, customers, products, and inventory cannot be joined, every other agent will guess. Week one is one workflow, one join, named reads — not a chatbot over your lakehouse. Monday morning: support, the recommendation widget, and a copilot each look up the same order and get a different product. The store number, the order-system number, and the warehouse pick ticket do not match. The copilot says "in transit" from last night's stock file. The widget recommends a parent product the warehouse cannot pick. That is not an agent problem. The records do not join. **The job.** Make orders, customers, products, and inventory join on named keys with `asOf` on anything that moves — so support, sales, inventory, and shopping agents read the same facts. **This week.** Pick one workflow join — usually where-is-my-order: platform order id to OMS id. Document it. Name the read tools (`getOrder`, `getInventoryPosition`, `getCustomer`). Reject rows that cannot join. **A person still signs.** Merging customers, editing a product, or overwriting what can actually ship stays with a person. Catalog changes publish through a merchandiser, not an agent. **Skip it** when the plan is a SQL copilot on the warehouse, a generic web-research agent, or auto-publish so "the catalog stays fresh." Week one is catalog facts and join keys, not a research bot. This page is the commercial summary for the **knowledge and catalog** family. The long build is [AI-ready eCommerce data layer](https://www.joinhorizon.co/blog/ai-ready-ecommerce-data-layer-2026/). The SKU contract is [AI-ready product catalog](https://www.joinhorizon.co/blog/ai-ready-product-catalog-agentic-commerce-2026/). **Our take:** runtime comes after the join works. An agent on three identities for one order will invent causality in support, returns, and root-cause analysis. Fix the keys first. ## Catalog facts vs business joins The [AI-ready product catalog](https://www.joinhorizon.co/blog/ai-ready-product-catalog-agentic-commerce-2026/) is the SKU contract shopping agents consume — parent/child, GTIN, required attributes, checkout-true offer. 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 - A finance agent. - Unrestricted SQL with a chat window. - A generic web-research agent that browses outside your commerce data. - Amazon Bedrock as "the data layer." Bedrock is the model. The layer is your keys, your tools, and your as-of stamps. - Auto-publish master data so the feed "stays fresh." CTOs who want the runtime next can go to [Bedrock AgentCore](https://www.joinhorizon.co/services/amazon-bedrock-agentcore/) and the [agentic commerce pattern](https://www.joinhorizon.co/patterns/agentic-commerce-on-aws/). Operators who just need where-is-my-order to tell the truth should stay on this page, then [customer support](https://www.joinhorizon.co/ai-agents/customer-support/). ## Week-one boundary | In scope week one | Out of scope week one | | ----------------- | --------------------- | | One workflow join documented | Boiling the whole lakehouse | | Named read tools with accepted keys | Unrestricted SQL | | `asOf` on inventory and price | Auto-publish catalog or ATP | | Quality monitors that fail broken joins | Generic web research | | Catalog facts from the PIM contract | A second shadow catalog for "AI" | FactualMinds is an AWS Select Tier Services Partner. We do not have published knowledge-agent case studies. The [data-layer](https://www.joinhorizon.co/blog/ai-ready-ecommerce-data-layer-2026/), [data-agent](https://www.joinhorizon.co/blog/ai-data-agent-ecommerce-2026/), and [catalog-management](https://www.joinhorizon.co/blog/ai-product-catalog-management-ecommerce-2026/) field-guide posts are the published depth. ## How we start One workflow. One join. Named reads. A person publishes catalog changes. Then the [eCommerce AI Agents](https://www.joinhorizon.co/services/ecommerce-ai-agents/) engagement — or a readiness pass if the keys are not there yet. ## FAQ ### Is this a research agent? No. This family is catalog quality, join keys, and named read tools for commerce data. A generic web-research agent is out of 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. ## 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 Week one is catalog facts and named read tools over a join contract: orders, customers, products, inventory, returns, and support — with as-of on anything that moves. The agent answers "can these records be the same thing?" and flags quality breaks. It does not browse the web as a generic researcher, does not get unrestricted SQL, and does not publish master data. ## Workflow ### Pick one join Usually where-is-my-order: platform order id to OMS id. Document it. Do not boil the lakehouse first. ### Name the read tools getOrder, getInventoryPosition, getCustomer — each with the keys it accepts. Reject rows that cannot join. ### Stamp as-of on moving facts 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. A person publishes catalog changes. PII leaves the payload unless identity policy allows it. ## How the knowledge agent stays bounded Join identifiers and answer from named read tools with an as-of time. - **Maturity:** Level 2 — reference architecture - **Risk:** medium - **Oversight:** monitored - **Starts when:** Another agent, or a person, needs a fact that lives in more than one system. - **Tools:** Reads only, through named tools. No shell, no unrestricted SQL, and no undeclared API. - **Stops for a person:** Reads only. Master-data writes are human-approved. No web research and no unrestricted SQL. - **Checked by:** The join is shown. A failed join is not filled with a guess. PII stays inside the policy. - **Untrusted data:** Documents and tickets that tell the agent to publish or to ignore the as-of. - **If it fails:** If the knowledge agent stops, name the reason: completed, budget_exceeded, timed_out, cancelled, guardrail_blocked, approval_required, tool_failure, verification_failed, or partial_completion. Retry a timeout at most twice. Back off on rate limits. After repeated verification failure, escalate. Stop when the budget is exhausted or a permission is denied. No unbounded loop. Reads only. Master-data writes are human-approved. No web research and no unrestricted SQL. - **Lifecycle:** Explore, then act, then confirm, then verify. Explore gathers the context for the knowledge agent. Act stays reversible. Confirm stops before an irreversible step. Verify is a separate check of the outcome. Reference architecture, not a published production deployment. The shared contract is the [AWS store-agent architecture](https://www.joinhorizon.co/blog/aws-ai-agents-for-ecommerce-factualminds-2026/#operating-contract). ## 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. This family is catalog quality, join keys, and named read tools for commerce data. A generic web-research agent is out of 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.joinhorizon.co/ai-agents/knowledge/*