Enterprise AI needs to know which version of the organisation to believe

Enterprise AI context is the information and relationships a system uses to understand how a business operates. An organisation contains many descriptions of itself. Its strategy documents explain what it intends to do. Project records show what is underway. Policies describe accepted constraints, while messages and meeting notes reveal exceptions, disagreements and decisions that have not yet reached a formal document. An AI system connected to all of them can know more and still misunderstand what governs the next action.

OpenAI’s expanded partnership with Atlassian brings that question into view. Its announcement describes combining OpenAI models with Atlassian’s Teamwork Graph, which connects people, projects, documents and decisions. The proposition is that enterprise knowledge becomes more useful when its relationships are available alongside its content. It is a product announcement, rather than independent evidence of improved organisational outcomes.

Separately, Infor reports that 68% of respondents to its YouGov research said off-the-shelf AI did not adequately address challenges specific to their business or industry. The finding concerns perceived fit. It does not establish that a particular context architecture would close the gap, but it gives a reason to examine what “knowing the business” should mean.

More context can make a conflict more visible

Infor’s survey covered 2,111 business decision-makers across seven countries, with fieldwork from 5 to 19 August 2026. It is vendor-commissioned research spanning industries and organisation sizes, rather than a direct test of models. Its scope supports an account of respondents’ experience, not a universal claim about enterprise AI failure.

The partnership announcement and the survey also describe different things. One presents a route towards connected knowledge; the other reports a problem of fit. Reading them together suggests an operational question, rather than a demonstrated causal link: which relationships must a system understand to turn relevant information into appropriate action?

Consider an illustrative marketing assistant that can search a product policy, an old campaign and a recent discussion. The old campaign uses a claim that the current policy restricts. The discussion suggests a possible exception, but the decision has not been made. A system that summarises all three into a balanced paragraph may be less helpful than one that exposes their different status.

The business does not need an average of its positions. It needs the position that applies, together with a clear account of anything unresolved. Context should therefore include whether a document is current, whether a decision is authorised and which owner can resolve a conflict. A larger retrieval index cannot supply those distinctions if the source records do not contain them.

Enterprise context includes the conditions of a decision

A document describes information. A decision explains what an organisation accepted, rejected or made conditional in a particular situation. Connecting the two can help an assistant understand why a familiar piece of evidence leads to a different action in another case.

An approved claim might depend on a defined audience and a particular qualification. A product exception might apply to a narrow group and expire when a feature changes. A strategy recommendation might remain a proposal until a responsible leader accepts it. These relationships determine what the next user can safely infer from the record.

This is the argument behind the useful memory of expert work. Retaining a decision without its conditions invites overgeneralisation. Retaining the reasoning and its limits can help a person or agent assess whether the next case is materially similar.

There is also value in preserving disagreement. An organisation may deliberately leave a question unresolved pending new evidence. If a context layer compresses that record into a single answer, it has removed an important fact about the current state. The system should be able to represent “not yet decided” without treating it as missing data to fill in.

Ownership makes context actionable

Knowing that a policy exists is useful. Knowing who owns its interpretation creates a route when the policy does not settle the case. For enterprise AI, ownership is therefore more than directory information. It can determine where a task goes when the system reaches the boundary of what the organisation has already decided.

The owner also needs appropriate authority. A person named in a project record may be responsible for delivery without being able to approve a new claim or authorise a change to customer communications. The context should distinguish those roles where they affect action, rather than infer permission from proximity to the work.

That is a further reason to preserve current state. Projects finish, people move roles and product information changes. A historical decision can remain valuable while its owner or assumptions become obsolete. The organisation needs a way to identify that change and decide whether the knowledge still applies.

In practice, this can begin with a narrow workflow. For one campaign type, identify the authoritative product source, the governing interpretation and the person able to resolve an exception. Connect the records the team already uses. This creates a more testable basis for AI assistance than attempting to make the whole enterprise equally available in one step.

The work is organisational before it is technical

A graph can represent relationships only as well as the organisation defines and maintains them. If nobody can identify the authoritative source, technology can expose the ambiguity but cannot make the underlying business decision. If an approval lives in a private message, an integration may not have the evidence required to interpret it. If exceptions are routinely informal, the system can inherit that informality at scale.

The marketing test of organisational AI asks whether adoption changes the work around the tool. Context infrastructure is part of that change because it requires the business to make its own knowledge more usable. Naming owners and preserving decision conditions benefits human teams as well as their assistants.

Access remains a separate constraint. A useful account of the organisation does not require every agent to receive every underlying record. The system can identify that evidence exists, or retain an appropriately scoped procedure, without copying all the source information into every task. Context should support the work’s purpose rather than expand automatically with the available connections.

Neither announcement settles how well a particular deployment will perform. Better models and richer context may both help, and results need to be tested against real tasks. The more durable standard is whether the system can distinguish the organisation’s current authority from its accumulated conversation. Enterprise intelligence becomes useful when it understands what the business can act on today, not merely what it has said before.