<\/p>\n
Giving an agent access to enterprise data is not the same as giving it what it needs to make an enterprise decision.<\/strong><\/p>\n Ask whether a customer can receive a 10% discount. The customer identity may live in CRM, current contract terms in a contract platform, product eligibility in ERP, profitability in a warehouse, and approval authority in a policy document. Access to all five sources still does not answer the question.<\/p>\n The agent also needs to know which customer entity is relevant, which contract version is effective, which system is authoritative, how the information relates, and whose authority permits the action.<\/p>\n A model can reason about those questions. It cannot be their source of truth. The architecture must expose the meaning, authority, state, and provenance needed to answer them.<\/p>\n That makes data architecture part of AI architecture.<\/p>\n Retrieval-augmented generation solved an important first problem: a model does not need to contain every fact if an application can retrieve relevant information when needed.<\/p>\n But retrieving a relevant document does not establish its authority.<\/p>\n A search can find a document containing \u201cdiscount policy\u201d without establishing that the document is current, applies to this product and geography, or grants the requesting employee permission to approve anything.<\/p>\n McKinsey\u2019s work on AI data readiness makes the same distinction: making unstructured content searchable does not make it usable. Reliable AI also requires versioning, structure, context, and links to the structured enterprise data that defines customers, contracts, products, policies, and transactions.<\/p>\n Context engineering addresses what should enter a model\u2019s temporary working context\u2014its instructions, tools, history, and external information. Anthropic describes this as continuously curating a finite context window.<\/p>\n The enterprise has a different problem: defining the durable business meaning and authority from which that temporary context is assembled. A larger context window may hold more information. It does not establish which source has contractual authority.<\/p>\n Some organizations describe an enterprise context layer between systems of record and agents. The term is useful if \u201clayer\u201d describes a responsibility rather than another mandatory platform.<\/p>\n For a business decision, the architecture needs to answer four questions:<\/p>\n The answers may come from a semantic model, data catalog, master-data service, knowledge graph, API, policy engine, identity system, or a combination of them. The principle is coherence, not consolidation. Enterprises should not migrate every source into one repository merely to produce a cleaner architecture diagram.<\/p>\n Microsoft\u2019s data-architecture guidance for agents emphasizes authoritative content, governed retrieval, existing security boundaries, and explicit choices about whether a domain is reached through search, APIs, or both.<\/p>\n McKinsey\u2019s agentic software-development research describes knowledge graphs connecting architecture decisions, design documents, tickets, incidents, customer feedback, and compliance rules. Importantly, it recommends that such graphs grow around priority domains rather than begin as a grand, top-down ontology.<\/p>\n The use case should earn the graph, not the other way around. A graph can represent connected meaning exceptionally well. It can also formalize assumptions nobody has validated.<\/p>\n Consider two systems containing different customer addresses. An experienced employee may know that ERP overrides CRM for a particular customer type. A reporting pipeline may already encode that precedence rule. An agent knows neither unless the rule is explicit and discoverable.<\/p>\n The same applies to obsolete policies that remain searchable, duplicate product identifiers, undocumented APIs, operational rules buried in PDFs, and business terms encoded as values such as These were already forms of technical and data debt. Agents turn them into constraints on what can be automated safely.<\/p>\n The failure may look plausible rather than dramatic. The discount agent retrieves a superseded policy, maps the billing account to the wrong legal entity, and produces a well-written recommendation with citations. Without effective dates, entity relationships, and source authority, an answer can look grounded while being wrong.<\/p>\n Better models will navigate imperfect information more effectively. They cannot manufacture contractual authority, invent an undocumented precedence rule, or decide that possession of customer data implies permission to modify it.<\/p>\n Model capability improves reasoning over context. It does not create enterprise truth where the enterprise has not defined it.<\/p>\n The practical response is not a multi-year context-platform program. Select one consequential decision\u2014discount approval, contract assessment, product eligibility, a customer complaint, or an internal access request\u2014and map only the context required to support it.<\/p>\n Identify the relevant entities, two to four source systems, the authoritative source for each fact, the semantics needed to interpret those facts, and the permissions required to retrieve or change them.<\/p>\n Then ask an experienced employee what they know that the systems do not express. Formalizing one tacit rule can be more valuable than indexing another thousand documents.<\/p>\n The trade-off is speed versus control. Explicit semantics, provenance, policy checks, and authorization introduce work and can add latency. Centralizing them can also create a dependency that slows domain teams.<\/p>\n Keep shared controls\u2014identity, authorization, provenance, and source registration\u2014small enough to reuse while leaving domain meaning with accountable domain owners.<\/p>\n Do not judge the experiment only by whether the agent produces the correct answer. That primarily tests the agent. Give the architecture a falsifiable requirement:<\/p>\n For a defined business decision, the agent must identify the relevant enterprise entities, retrieve current information from declared authoritative sources, apply explicit business semantics, remain within independently enforced authorization boundaries, and provide enough provenance for a human to verify the proposed outcome.<\/p><\/blockquote>\n Authorization matters because knowing and acting are different capabilities. The NIST NCCoE work on agent identity and authorization asks how an agent proves its authority, how delegated human authority is bound to its actions, and how those actions can be audited.<\/p>\n An agent should not infer permission from the data it can see.<\/p>\n Once the first use case passes, try another domain. The concepts and source systems should change. If identity, authorization, provenance, context discovery, and authoritative-source patterns survive, they are candidates for shared enterprise building blocks. What does not survive probably belongs in the domain.<\/p>\n The useful question for enterprise architects is not whether the model has enough intelligence. Ask whether the enterprise can explain what its information means, where the current truth lives, and why an agent is allowed to act on it.<\/p>\n If those answers are missing, giving the agent more data or a better model will not solve the underlying architecture problem.<\/strong><\/p>\n AI agents need authoritative business meaning, not merely access to more documents. A practical architecture test for building trustworthy enterprise context.<\/p>\n","protected":false},"author":2,"featured_media":301,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_import_markdown_pro_load_document_selector":0,"_import_markdown_pro_submit_text_textarea":"","footnotes":""},"categories":[131,149,170],"tags":[132,158],"class_list":["post-299","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","category-data-and-knowledge","category-data-architecture","tag-ai","tag-enterprise-architecture"],"blog_post_layout_featured_media_urls":{"thumbnail":["https:\/\/site.beachbot.dk\/wp-content\/uploads\/2026\/09\/ChatGPT-Image-23.-sep.-2026-14.04.10-150x150.png",150,150,true],"full":["https:\/\/site.beachbot.dk\/wp-content\/uploads\/2026\/09\/ChatGPT-Image-23.-sep.-2026-14.04.10.png",1672,941,false]},"categories_names":{"131":{"name":"AI","link":"https:\/\/site.beachbot.dk\/index.php\/category\/ai\/"},"149":{"name":"Data & Knowledge","link":"https:\/\/site.beachbot.dk\/index.php\/category\/data-and-knowledge\/"},"170":{"name":"Data Architecture","link":"https:\/\/site.beachbot.dk\/index.php\/category\/data-architecture\/"}},"tags_names":{"132":{"name":"AI","link":"https:\/\/site.beachbot.dk\/index.php\/tag\/ai\/"},"158":{"name":"Enterprise Architecture","link":"https:\/\/site.beachbot.dk\/index.php\/tag\/enterprise-architecture\/"}},"comments_number":"0","wpmagazine_modules_lite_featured_media_urls":{"thumbnail":["https:\/\/site.beachbot.dk\/wp-content\/uploads\/2026\/09\/ChatGPT-Image-23.-sep.-2026-14.04.10-150x150.png",150,150,true],"cvmm-medium":["https:\/\/site.beachbot.dk\/wp-content\/uploads\/2026\/09\/ChatGPT-Image-23.-sep.-2026-14.04.10-300x300.png",300,300,true],"cvmm-medium-plus":["https:\/\/site.beachbot.dk\/wp-content\/uploads\/2026\/09\/ChatGPT-Image-23.-sep.-2026-14.04.10-305x207.png",305,207,true],"cvmm-portrait":["https:\/\/site.beachbot.dk\/wp-content\/uploads\/2026\/09\/ChatGPT-Image-23.-sep.-2026-14.04.10-400x600.png",400,600,true],"cvmm-medium-square":["https:\/\/site.beachbot.dk\/wp-content\/uploads\/2026\/09\/ChatGPT-Image-23.-sep.-2026-14.04.10-600x600.png",600,600,true],"cvmm-large":["https:\/\/site.beachbot.dk\/wp-content\/uploads\/2026\/09\/ChatGPT-Image-23.-sep.-2026-14.04.10-1024x941.png",1024,941,true],"cvmm-small":["https:\/\/site.beachbot.dk\/wp-content\/uploads\/2026\/09\/ChatGPT-Image-23.-sep.-2026-14.04.10-130x95.png",130,95,true],"full":["https:\/\/site.beachbot.dk\/wp-content\/uploads\/2026\/09\/ChatGPT-Image-23.-sep.-2026-14.04.10.png",1672,941,false]},"_links":{"self":[{"href":"https:\/\/site.beachbot.dk\/index.php\/wp-json\/wp\/v2\/posts\/299","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/site.beachbot.dk\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/site.beachbot.dk\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/site.beachbot.dk\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/site.beachbot.dk\/index.php\/wp-json\/wp\/v2\/comments?post=299"}],"version-history":[{"count":3,"href":"https:\/\/site.beachbot.dk\/index.php\/wp-json\/wp\/v2\/posts\/299\/revisions"}],"predecessor-version":[{"id":307,"href":"https:\/\/site.beachbot.dk\/index.php\/wp-json\/wp\/v2\/posts\/299\/revisions\/307"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/site.beachbot.dk\/index.php\/wp-json\/wp\/v2\/media\/301"}],"wp:attachment":[{"href":"https:\/\/site.beachbot.dk\/index.php\/wp-json\/wp\/v2\/media?parent=299"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/site.beachbot.dk\/index.php\/wp-json\/wp\/v2\/categories?post=299"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/site.beachbot.dk\/index.php\/wp-json\/wp\/v2\/tags?post=299"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Searchable data is not enough<\/h2>\n
Treat context as a responsibility, not a platform<\/h2>\n
\n
Legacy architecture sets a ceiling on automation<\/h2>\n
TYPE=4<\/code>.<\/p>\nTest one decision, not the whole data estate<\/h2>\n
Test the architecture, not just the agent<\/h2>\n
Sources<\/h2>\n
\n