Atlan’s Case for Creating AI Value With Enterprise Context Shifts Attention Beyond Models
Atlan is challenging the model-first approach to enterprise AI, arguing that capable systems still lack the business understanding required for useful work. Creating AI value with enterprise context, the subject of an October 28 MIT Technology Review Insights piece, puts that claim under scrutiny. The question is whether organizations need another infrastructure layer, better management of existing knowledge, or both.
The argument arrives with a commercial context of its own. The piece comes from MIT Technology Review’s custom content arm, rather than its editorial newsroom. Atlan’s conference materials identify the associated research as produced with the company. That relationship matters when evaluating a diagnosis that also supports the vendor’s product positioning.
Microsoft’s Work IQ offers a useful comparison: another supplier is organizing its enterprise AI strategy around business context. The central tension extends beyond vendor competition. Organizations want AI that can perform work, yet their definitions, permissions, and operating rules often require human interpretation. Buying access to a model does not settle those questions.
Creating AI Value With Enterprise Context Moves Beyond the Model
The October 28 enterprise context analysis presents a familiar deployment problem through Atlan’s preferred lens. AI tools can respond quickly while misunderstanding the business they serve. Atlan co-founder Prukalpa Sankar argues that context infrastructure can help close that gap.
A context layer is infrastructure that supplies AI systems with business definitions, relationships, policies, and other information needed to interpret company data. The concept matters because finding information and understanding its business meaning are different tasks. A document can contain an answer without establishing whether that answer remains authoritative.
The development is a more explicit commercial argument about where enterprise AI value comes from, rather than a newly verified technical breakthrough.
That distinction keeps the news in proportion. The article does not establish that context infrastructure alone causes better financial returns. It advances an explanation for disappointing deployments and a direction for addressing them. Buyers should assess the explanation separately from any particular implementation.
Consider an illustrative sales workflow. An assistant finds a customer record, summarizes recent conversations, and drafts a renewal recommendation. Every retrieved document might be accurate individually. The recommendation can still fail if the assistant confuses the billing entity with its parent company or overlooks an approved exception.
A better model might recognize ambiguity and ask a useful question. A maintained business definition might resolve the ambiguity before generation begins. These approaches complement each other, but they address different parts of the failure. Treating every mistake as a model problem obscures that distinction.
Creating AI value with enterprise context therefore changes the purchasing conversation. Instead of asking only which system produces the strongest answer, buyers must ask what makes an answer valid inside their organization. That includes who approved the underlying rule and when it last changed.
The publishing relationship also deserves attention. Atlan’s context research event promoted early access to research produced in association with the company. This supports treating the argument as a vendor-backed contribution to the debate. It does not justify dismissing the underlying problem.
The practical implication is narrower than the broad sales narrative. Context is a credible source of enterprise AI failure, but its importance must be established for each workflow. Organizations still need evidence connecting the proposed intervention to a measurable improvement. Without that connection, context becomes another explanation that is difficult to test.
Business Owners Inherit the AI Reliability Problem
The context argument puts pressure on business owners as well as technology teams. If an assistant misunderstands an approved policy, changing the model might help. If departments disagree about the policy itself, the organization must resolve that disagreement before software can consistently apply it.
Enterprise AI makes neglected knowledge ownership an operational issue.
An AI developer can connect a document repository without having authority to decide which policy supersedes another. A security team can enforce access restrictions without deciding how finance defines a customer. These responsibilities intersect, but they do not belong to the same person.
This creates a different implementation burden from installing a conversational interface. Someone must identify authoritative sources, assign owners, document exceptions, and maintain those decisions. The work can expose disagreements that employees previously handled through informal conversations. Automation makes those disagreements harder to leave unresolved.
For finance leaders, the pressure concerns consistency. An assistant answering a revenue question needs the appropriate accounting definition, reporting period, and organizational scope. A fluent explanation does not compensate for choosing the wrong measure. The business owner must make the intended interpretation available and reviewable.
For service leaders, the pressure concerns applicability. An agent, meaning an AI system that selects steps or uses tools to complete work, needs relevant customer circumstances. A valid refund policy might vary by contract or region. Retrieving the general policy is only part of the decision.
These examples are illustrative, rather than reported customer outcomes. They show why context ownership becomes consequential when software moves from drafting language toward recommending actions. A mistaken summary creates correction work. A mistaken action can also create an obligation that another team must unwind.
Procurement teams face a related challenge. A context platform can promise common definitions, but the contract cannot guarantee that departments will agree on them. Buyers need to distinguish supplier responsibilities from organizational responsibilities. Otherwise, an infrastructure purchase can conceal an unfinished operating decision.
Knowledge workers experience the same issue at a smaller scale. A searchable archive helps people locate material, while an authoritative knowledge base establishes which material should guide work. The distinction between personal and team knowledge becomes relevant when individual recollection feeds shared decisions.
The short-term response should follow the failure being addressed. Missing source material calls for better coverage. Conflicting definitions call for ownership and resolution. Incorrect reasoning calls for changes to the model or application. Combining these categories into a single accuracy score can hide where intervention is needed.
Over time, the pressure shifts toward maintenance. Business context changes when products, contracts, teams, and policies change. A deployment that performs well at launch can become unreliable without any model update. The context argument is therefore also a claim about ongoing operating responsibility.
Microsoft Shows Why Context Is Becoming a Platform Question
Microsoft provides a concrete comparison because it also describes enterprise context as shared infrastructure. In its June 11 account of internal Work IQ use, the company explains how organizational information supports more relevant AI responses. It presents context as part of the environment surrounding assistants.
Microsoft says Work IQ draws on workplace signals and respects existing permissions. Its internal examples include connecting meeting information with participants and applying employee circumstances to guidance. These are company-reported examples, rather than independent measurements of business returns. They nevertheless show a supplier pursuing the same general problem.
The competitive question is where business understanding should live and how widely it can be reused.
Microsoft’s workplace intelligence approach describes context developing within its workplace environment. Atlan’s argument centers on providing business understanding across systems. These positions create different questions for buyers, even when both suppliers use similar language.
For an organization concentrated in a particular software environment, context embedded there can offer a natural starting point. Existing documents, identities, and collaboration records already sit nearby. The buyer still needs to establish which sources are covered and whether the resulting interpretation applies beyond that environment.
For an organization using several business systems, reuse becomes more important. A definition maintained for a finance assistant should not silently diverge from the definition used by an operations assistant. Shared context promises to reduce that duplication. Whether it succeeds depends on integration and governance details.
This is not a simple contest between centralized and distributed architecture. An architecture is the arrangement of components and their responsibilities. A central service can distribute outdated definitions, while application-specific context can remain accurate within a limited scope. Location alone does not determine quality.
The more useful comparison concerns change. When a definition changes, which applications receive the update? When access is revoked, which stored representations stop exposing the information? When an answer is disputed, can reviewers reconstruct the source and rule used? These questions connect platform design with operating consequences.
Portability also deserves attention. Buyers should ask whether approved definitions can move between tools without losing ownership, version history, or access restrictions. Exporting text is easier than preserving its authority. A migration that retains words but loses applicability can recreate the original problem.
The vendor comparison therefore supports a broader judgment without proving either supplier’s approach superior. Context is becoming a platform responsibility because multiple applications need the same business understanding. That creates an opportunity for shared infrastructure, alongside the risk of making many applications depend on a common mistake.
For buyers, the useful response is to examine a workflow crossing an actual organizational boundary. A demonstration confined to a tidy document collection leaves the central question unanswered. The relevant evidence is whether context remains consistent when information moves between departments, applications, and decision owners.
Retrieval Evidence Supports a Narrower Claim
Retrieval-augmented generation, or RAG, retrieves relevant information and supplies it to a model before the model answers. It is an established way to connect generated responses with external knowledge. Its limitations help explain why the enterprise context argument attracts attention.
Anthropic’s September 2024 research provides a technical example. Its Contextual Retrieval method adds explanatory information to document fragments before indexing them. The aim is to preserve meaning that can disappear when a passage becomes separated from its original document.
Anthropic reported a 49% reduction in retrieval failures when combining its contextual techniques, and a 67% reduction when adding reranking. Reranking is a second selection step that reorders retrieved material by relevance. These were results from the company’s evaluations, rather than measurements of enterprise financial returns.
Better retrieval supports the context argument, but it does not establish that a complete enterprise context platform is necessary.
The contextual retrieval research addresses a specific failure: a system misses relevant information because a fragment lacks surrounding meaning. That is narrower than resolving conflicting corporate policies. It is also narrower than determining whether a user has authority to carry out an action.
The distinction matters for purchasing decisions. If a support assistant misses answers because document fragments lack identifying details, retrieval changes deserve investigation. If it finds the correct passage but applies it incorrectly, the failure occurs elsewhere. A broad infrastructure proposal should explain which failure it addresses.
An illustrative contract example makes the separation clearer. A passage says that a customer qualifies for an exception, but the customer name appears on an earlier page. Preserving that relationship can improve retrieval. Establishing whether the exception remains active requires additional information about dates, amendments, and authority.
A system can therefore retrieve accurately and still produce the wrong business recommendation. Conversely, a workflow with narrow, maintained sources might perform adequately without an extensive shared context service. The appropriate intervention depends on the actual task, its information requirements, and its failure consequences.
Creating AI value with enterprise context should be evaluated through this chain of dependencies. Source coverage affects what the system can find. Source interpretation affects what it understands. Decision rules affect what it recommends. Action controls affect what it can execute. Improvement in one part does not automatically establish improvement throughout.
That reasoning also changes how demonstrations should be read. A successful answer proves that a particular configuration handled a particular question under particular conditions. It does not establish general reliability across departments. Buyers need evidence that includes ambiguous inputs, changed policies, and conflicting sources.
The strongest technical case will identify the original failure, the context intervention, and the resulting difference. Keeping the model and task comparable helps isolate what changed. Reporting retrieval success separately from decision accuracy makes the result easier to interpret and prevents a narrow gain from becoming a broader claim.
More Context Can Spread the Wrong Answer Further
The skeptical case begins with a straightforward problem: business context can be wrong. A shared definition might be outdated, incomplete, or disputed. Supplying it consistently can make outputs agree while leaving them incorrect. Agreement is useful evidence of consistency, but it is insufficient evidence of truth.
A context layer can distribute authority without establishing that the authority is justified.
This matters when organizations convert informal knowledge into maintained rules. Experienced employees sometimes know when a documented process does not fit a situation. Encoding that judgment requires deciding which exceptions are legitimate. Automatically extracting a statement from a conversation does not settle whether it should become policy.
A meeting participant might describe a temporary workaround. Another employee might repeat an outdated practice. A project document might record an abandoned proposal. Each source contributes information, but each carries a different degree of authority. Treating them as equivalent creates a governance problem before generation starts.
There is also a model-level limitation. NIST’s generative AI risk profile describes confabulation, meaning confidently generated false or erroneous content, as a characteristic risk. It also notes that generated explanations and citations can mislead users. Relevant source material does not remove the need to evaluate outputs.
NIST’s analysis supports a cautious interpretation of the context thesis. Better information can address missing knowledge without guaranteeing correct reasoning. A system might misapply a valid rule or overstate an uncertain inference. Context quality and output reliability require related but distinct scrutiny.
Permissions create another pressure point. An employee’s ability to read a document does not necessarily authorize an automated system to act on its contents. A context service needs a clear relationship with the controls governing downstream actions. Otherwise, accurate information can support an unauthorized decision.
The financial case remains uncertain as well. Maintaining definitions, resolving disputes, checking permissions, and reviewing failures all consume staff time. Some of that work may improve existing processes beyond AI. Buyers should still account for it when judging the economics of the deployment.
An organization might achieve better answers while increasing the total work required to produce them. Another might reduce review effort enough to justify substantial maintenance. The meaningful comparison includes the whole workflow, rather than the visible speed of generation. This is an analytical requirement, not a reported outcome from the source article.
Creating AI value with enterprise context also requires accepting limits. Where a policy conflict remains unresolved, a useful assistant should expose the conflict. Where authority is unclear, it should route the decision appropriately. A system that always produces a confident answer can conceal the very organizational uncertainty context infrastructure should reveal.
The skeptical position therefore does not require rejecting context investment. It requires a more specific claim about what the investment changes. A supplier should identify which errors become less frequent, which responsibilities remain with the customer, and which failure modes persist. That makes the proposal testable.
The Next Evidence Should Connect Context With Completed Work
Over the coming months, the most useful signals will concern deployment evidence rather than new vocabulary. The October discussion establishes a clear proposition: business understanding deserves more attention alongside model capability. The next step is determining where that proposition produces measurable benefits.
The context thesis becomes stronger when maintained business knowledge improves completed work under changing conditions.
The first signal is a documented comparison within a real workflow. Buyers should look for results showing what happened before and after a defined context intervention. The comparison should include source mistakes, decision errors, human corrections, and completed tasks. A result that isolates improvement would strengthen the argument.
A demonstration offering only selected successful answers would leave the central uncertainty intact. So would a comparison that changes the model, interface, source collection, and review process simultaneously. Such changes might improve the product, but they would make the contribution of enterprise context difficult to separate.
The next signal is reliable behavior after a business change. A revised policy, revoked permission, or renamed customer creates a useful observation point. Does the system adopt the change across affected applications? Does it retain enough history to explain earlier answers? Consistent behavior would support the case for shared infrastructure.
Persistent contradictions would weaken that case. If every application still needs manual repair, the proposed common layer has not eliminated duplicated maintenance. If outdated information survives in derived stores, the organization needs to understand how corrections propagate. Initial setup quality cannot answer those questions.
The final signal is the total operating burden. Organizations should examine whether reviewers spend less time correcting output after accounting for context maintenance. They should also track whether unresolved cases reach the right people. A reduction in visible review work means little if hidden preparation work grows faster.
These signals do not depend on a particular supplier winning. Microsoft, Atlan, and application developers can contribute evidence through different approaches. The useful distinction is between claims about available capabilities and observations about sustained use. Buyers need both, but they should not confuse them.
For knowledge workers, the immediate relevance is practical. An assistant that knows where information lives can save searching. An assistant that understands which information applies can support a decision. The value of that additional understanding depends on whether users can inspect, challenge, and maintain it.
Start with a workflow where an incorrect answer creates identifiable rework. Review failures with the people who own the underlying policy, rather than treating every correction as a prompting problem. Separate missing information from conflicting definitions, reasoning errors, and inappropriate actions. Then examine whether the proposed context investment addresses those specific failures. For individual work, a maintained personal knowledge system can help organize relevant material, while shared decisions still require shared authority. Creating AI value with enterprise context becomes a credible proposition when that distinction survives deployment. Ask the next supplier to show how its system handles a changed rule, a disputed source, and a decision it should leave unresolved.
