Enterprise Context: Why AI Needs It Before It Needs Smarter Models

Ali Ghodsi says enterprise context is the next unlock for AI. Here is what it means, why agents need it, and how data teams can build it safely.

A chatbot waits for a question.

An agent is expected to notice a problem, decide what matters, use the right tools, and move work forward.

That difference sounds like a model upgrade. It is not. It is a context upgrade.

Databricks co-founder and CEO Ali Ghodsi made that point in a recent conversation with Brian Halligan on Long Strange Trip. The discussion ranged from Ghodsi's unexpected path to the CEO role to hiring, company bottlenecks, and the next stage of enterprise AI.

His most important observation was not about a bigger model.

“You need to capture the enterprise context that's in people's heads. Decisions that are being made every day. What's happening inside every meeting that's being recorded, every email that's being sent. Everything has to be captured and be made part of the context and then fed to the AI.”

Ghodsi then connected that context to an ontology and to Databricks Genie. You can read the statement in the original Sequoia transcript.

The quote points to a real constraint. Most organizations do not lack AI access. They lack a reliable way to explain themselves to AI.

The missing layer is enterprise context.

What enterprise context really means

Enterprise context is everything a capable colleague needs before making a sound decision.

Some of it is written down:

Some of it is structural:

Some of it is temporal:

And some of it remains in people's heads:

An AI system that sees only documents has information.

An AI system that understands definitions, relationships, authority, time, and permission has context.

Enterprise context turns raw signals into meaning, then combines meaning with controls for safe action.

Why chatbots can survive without it

A chatbot can be useful even when its view of the company is incomplete.

Ask it to summarize a meeting and it can summarize the transcript. Ask it to draft an email and it can draft from the details you provide. Ask it to explain a table and it can describe the columns.

The person remains in charge of the difficult parts. They choose the source. They notice missing information. They decide whether the answer makes sense. They carry the business meaning in their own head.

This creates a hidden safety layer: the human user.

Agents change the risk.

Suppose an agent is asked to protect renewals. It notices falling product usage, reads support history, identifies an unhappy customer, selects an offer, and sends a message.

Each step can be reasonable by itself. The whole action can still be wrong.

The account may be migrating to a new product, so lower usage is expected. The open ticket may belong to a test workspace. The contract may prohibit that discount. The customer may have asked not to receive automated messages. A sales leader may have agreed on a different response in yesterday's meeting.

The agent does not merely need more text. It needs the right context for this customer, at this moment, under these rules.

Capturing everything is not the same as understanding everything

Ghodsi's phrase “every meeting” and “every email” is useful because it reveals how much business knowledge escapes formal systems.

But literal capture is not a complete architecture.

A company can collect every conversation and still produce a confused agent. More material creates more possible evidence, more disagreement, more stale instructions, and more sensitive information.

Four questions come first.

Is it relevant?

A pricing decision from three years ago may not help with today's contract. A private discussion about one employee should not become context for an unrelated customer workflow.

Context must be selected for a purpose.

Is it authoritative?

An email can contain an idea. A signed policy can contain the rule. A dashboard can show an estimate. A finance table can hold the official number.

Retrieval finds material. Governance tells the agent what should win when sources disagree.

Is it current?

Agents act in a changing world. A customer balance, access permission, inventory count, or pipeline status can change between reasoning and execution.

That is why agent memory is not the same as business state. Memory can guide the next step. The system of record must decide what is actually true.

Is it permitted?

Context is not useful if the agent should never have received it.

Permissions must travel with the information. The identity of the user, the agent, the tool, and the requested action all matter. A good answer produced from unauthorized data is still a failure.

The stack moves from signals to meaning to safe action

It helps to think about enterprise context as three layers.

1. Signals

This is the material the organization creates: meetings, email, documents, tables, events, tickets, and transactions.

Signals answer: What happened?

2. Meaning

This layer connects the signals to business language. It contains definitions, relationships, owners, rules, exceptions, and history.

Meaning answers: What does it mean here?

This is the same problem explored in our guide to semantic understanding for enterprise AI. A technically valid query can still be wrong when the model uses the wrong definition of revenue, customer, risk, or active.

3. Safe action

This layer checks current state, permission, policy, approval, cost, and audit requirements before work changes a real system.

Safe action answers: What may happen next?

The jump from the second layer to the third is where many agent demos become production problems. A recommendation can tolerate uncertainty. A refund, account suspension, contract change, or production update cannot.

One shared context, many agents

Now imagine several agents working together.

A support agent sees a rise in unresolved cases. A product agent finds the affected feature. A data agent confirms that the pattern is real. A finance agent estimates refund exposure. A customer agent prepares outreach.

If each agent builds its own private interpretation, the system becomes a fast-moving version of the dashboard problem. Five agents can produce five definitions of the same customer, incident, or metric.

Coordinated agents need a shared context layer.

That does not mean every agent receives every piece of information. It means they use common definitions, known relationships, consistent identity, governed access, and a current view of business state.

Sales, finance, support, and data agents can share governed context while every proposed action passes through control.

The shared layer lets one agent understand what another agent means. The control layer decides which proposed action can proceed.

This is the deeper importance of ontology. It is not simply a smarter search index. It is a model of the business that helps systems agree on entities, relationships, definitions, and permitted actions.

Our earlier article on Genie Ontology and trusted action explains how that idea can connect a business signal to an operational response. The important principle is broader than one product: agents need a common model of the organization before they can coordinate reliably.

The BricksNotes view: the 4Cs become operating requirements

At BricksNotes, we use the 4Cs from The Context Advantage to examine AI systems: Context, Control, Cost, and Choice.

Ghodsi's observation begins with Context, but enterprise agents need all four.

Context: does the agent understand the situation?

The agent needs the right facts, business definitions, relationships, history, and current state for the task.

Without Context, it produces plausible work that may not fit the company.

Control: is the action safe and accountable?

The system needs identity, permissions, approvals, policy checks, audit history, and a clear boundary between recommendation and execution.

Without Control, context can make an unsafe agent more capable.

Cost: is the result worth the work?

Capturing and retrieving every possible conversation for every request is expensive. Good context engineering narrows the material before the model sees it. It uses smaller context when smaller context is enough. It measures the cost of repeated reasoning, tool calls, and failed actions.

Without Cost discipline, a useful pilot can become an unsustainable service.

Choice: can the organization change models and tools?

Enterprise meaning should not live only inside one prompt, one assistant, or one model provider. Definitions, permissions, business state, and evaluation cases should remain portable where possible.

Without Choice, the context layer becomes another form of lock-in.

Together, the 4Cs turn “give the AI more context” into an engineering discipline.

What this means for data engineers

The agent era does not make data engineering less important. It moves data engineering closer to the decision.

A data engineer already works on many parts of the context layer:

The difference is the consumer.

A dashboard waits for a person to interpret it. An agent may use the same data to propose or execute an action. That raises the standard for freshness, semantics, and control.

The BricksNotes lesson on Unity Catalog is a useful starting point for ownership, permissions, lineage, and discovery. The data quality lesson shows why valid rows are not automatically trustworthy decisions. The incremental processing lesson explains how to keep context current without rebuilding everything. The AI Gateway and Serving lesson introduces the control point between models and production use.

These are not separate from AI engineering. They are part of the foundation that makes enterprise agents useful.

A practical context map you can build now

You do not need to capture the whole company first.

Choose one decision.

For example: Should this customer receive a proactive renewal offer?

Then build a context map around it.

Step 1: name the entities

List the things involved: customer, account, contract, product, support case, invoice, offer, and account owner.

Step 2: define the important terms

Write down what active customer, renewal risk, open case, eligible offer, and account value mean.

Include the owner of each definition and the source that implements it.

Step 3: identify authoritative state

Decide which system owns the current contract, payment status, consent setting, and customer contact details.

Do not let a meeting summary silently replace a system of record.

Step 4: record relationships and exceptions

Map which contacts belong to which account, which contracts cover which products, and which exceptions can block the offer.

Step 5: add permission and approval rules

Specify who may read customer details, who may approve a discount, and whether the agent may send or only draft.

Step 6: make change visible

Record when a definition, policy, or source changes. Context without history is difficult to debug.

Step 7: test disagreement

Give the system two conflicting sources. Check whether it selects the authoritative one, asks for help, or confidently chooses the wrong answer.

This exercise is small enough to practice. It also reveals where the real work is. The hardest part is rarely the prompt. It is agreement about meaning and authority.

What you can practice in Databricks Free Edition

You can explore much of the foundation in Databricks Free Edition.

Create a small group of Delta tables for customers, contracts, support cases, and offers. Define one business metric in SQL. Add quality checks. Process a small update incrementally. Document which table owns each field. Query the data using clear, explicit definitions.

You can also practice the reasoning boundary. Ask an AI assistant to recommend an action, but keep execution manual. Compare the answer with and without a glossary, current-state table, and exception rules.

Some organization-wide capabilities, advanced governance setups, and production agent controls require a paid Databricks workspace. The concept remains worth learning in Free Edition because the design problem exists at every scale.

The next unlock is organizational understanding

Models will continue to improve.

That does not remove the need for enterprise context. A more capable model can reason better with the information it receives. It cannot automatically know which private conversation became policy, which metric finance accepts, which record is current, or which action this user may authorize.

Organizations moving from chatbots to agents will need to turn scattered experience into governed, usable context.

Meetings and email matter because they contain decisions. Tables matter because they contain state. Semantic models matter because they contain meaning. Permissions matter because they contain boundaries. Audit history matters because autonomous work must remain explainable.

The goal is not an AI that has read everything.

The goal is an AI system that knows what matters, understands what it means, respects what it may do, and can show why it acted.

That is how thousands of agents become more than thousands of chat windows.

It is also why the next chapter of enterprise AI may be built as much by data engineers, governance teams, and domain experts as by model builders.