Mactores has been building data platforms on AWS since 2008, and until recently nearly every platform decision we helped with was about where data is stored and how it gets processed. AI agents changed that this year. They read business meaning directly, so CIOs and CDOs now have to decide where it lives, and nearly every vendor they already pay has started offering a place to keep it.
Our running example is a fleet-telematics company, made up but typical. It sells tracking hardware and software to about 2,400 trucking firms, keeps its data lake on Amazon S3 with the AWS Glue Data Catalog, runs product analytics in Databricks and closes its books in Power BI. This spring it gave its leadership team two assistants, a Databricks Genie space over the product data and a Copilot agent over finance's Power BI model. Asked in the same week how many active customers the company had, one said 1,960 and the other 2,180, and the CRM dashboard on the chief revenue officer's screen said 2,410.
None of the three was wrong. Sales had been counting any account with a live contract since the CRM went in. Finance only counted accounts it had invoiced in the last 90 days, and product wanted at least one truck reporting in the last 30. In the sections below we take that one term through the five context layers the company looked at, with platform statuses as they stood on November 10, 2026.
Agents made an old gap visible, and that's most of the reason. When the CRO looked at 2,410 on her dashboard, she knew it included accounts that hadn't paid since spring. The Genie space that told the CEO 1,960 had no way of knowing anyone would read its number differently, and it gave no hint that two other numbers existed.
Retrieval-augmented generation would have helped if the answer were sitting in a document, since the agent could pull the right paragraph before answering. The telematics company's three counts weren't buried in a PDF, though. They were three SQL filters over the same tables, each correct for the team that wrote it, and no retrieval step would have told the agent which one the CFO meant.
By the time the CEO asked his question, three of the company's own vendors had an answer on the way. Microsoft had introduced Fabric IQ at Ignite the previous November, while the data team was still rebuilding finance's Power BI model, and in June Databricks and AWS announced Genie Ontology and AWS Context within a day of each other.
Whichever one the company picked would have had to hold things it had never written down in one place. Nobody had recorded what active customer meant, how a customer tied to its contracts and trucks, or who was allowed to see the revenue behind each account. The five layers in this guide go about that in different ways, since some infer the meaning while others wait for a person to write it, and each serves a different set of agents. At the telematics company, that settled the choice faster than any feature comparison did.
What none of them can do is decide who owns a definition. An AI-ready data foundation needs a named owner for every contested term, and at the telematics company nobody owned active customer, because each team had written the version that answered its own questions.
On AWS the context layer comes in two pieces, and only one of them can be deployed today. The telematics company's data team stood up the open-source Context Ontology Accelerator in a sandbox account in August, a few weeks after AWS released it under the Apache 2.0 license on July 31, 2026.
When the team pointed it at the S3 lake and the CRM extracts, the accelerator used foundation models on Amazon Bedrock to draft an ontology and then held every element back until someone with domain knowledge had reviewed, edited and approved it. Approved elements landed in a graph the company owns. In this first release that graph runs on Amazon Neptune, with Amazon OpenSearch Serverless holding the vectors, and the ontology is written in open W3C standards that an MCP server exposes to any agent.
For active customer, the draft came back with a Customer linked to Contract, Invoice and Device, which matched the company's data well. The definition it proposed came from the CRM view, though, because that was the most complete source it scanned. Finance's 90-day rule had to be written in by hand, and the CFO had to approve it before the element went live.
It's a self-managed project. The team runs the Neptune, OpenSearch and Bedrock pieces itself or brings in AWS Professional Services, issues go through GitHub, and the ontology starts from the company's own data rather than from a prebuilt industry model.
The second piece, AWS Context, is the one the company couldn't deploy. AWS announced it at its New York Summit on June 17, 2026 as a managed service that maps how a company's existing data relates, working with the AWS Glue Data Catalog, Amazon SageMaker Unified Studio and AWS Lake Formation.
Data stewards would review what it infers and promote the relationships they trust, adding definitions and usage rules along the way, and at the telematics company that steward would have come from the finance data team. AWS says each call is designed to inherit the caller's IAM and Lake Formation permissions, and agents reach the graph through agentic search APIs and MCP tools.
The service also publishes its key metadata as Apache Iceberg tables in Amazon S3 Tables, so Athena, Redshift or Spark can query the context like any other dataset. As of November 10, 2026, AWS still listed AWS Context as coming soon, with no date or Regions.
AWS has also said the accelerator's ontology capability will become a managed feature of AWS Context and that ontologies built with the accelerator will carry over. That's why the telematics company kept its sandbox running. The definition its CFO approved there wouldn't have to be written a second time once the managed service arrives.
It's the context layer under Databricks' Genie assistants, and of the five it does the most inferring on its own. Databricks announced it at Data + AI Summit on June 16, 2026, and its documentation still lists Genie Ontology as a public preview. Most of what's written about a Databricks ontology refers to it.
Genie Ontology draws on two kinds of context. One is modeled: metric views, domains and the other semantics a team defines and governs in Unity Catalog. The other is inferred, as small snippets of knowledge Genie pulls out of what people already use, from dashboards and SQL queries to Genie Agents and queries run through dbt.
At the telematics company, all three active-customer counts turned up as snippets within a few days. Product's came from a popular dashboard and finance's from a nightly query, while sales' arrived through a CRM sync that landed in the lakehouse. Databricks' launch post says Genie Ontology "weighs where a definition came from, the relative authority of that source's author," along with how heavily people rely on it and how fresh it is.
Product's dashboard was opened every day and refreshed every hour, so Genie answered 1,960, which was a reasonable guess and the wrong figure for a board pack.
The fix took an afternoon once the definition was agreed. The data team published one metric view in Unity Catalog with the CFO's rule and certified it, which gave the ranking an authoritative asset to tie to, and Genie's answer moved to 1,874 within a day.
Permissions follow Unity Catalog, so a snippet only reaches people who can see the asset behind it. The exception worth knowing about is knowledge pulled from connected outside sources, which Databricks' documentation says is visible to every user in the account. That matters for anything sales keeps in shared documents.
The strongest case for Genie Ontology is that the context and the data sit under the same catalog and the same grants, which is most of the argument for a data lakehouse for agentic AI in the first place. If your analysts already work in Genie and your tables are governed in Unity Catalog, it's the shortest path to agents that use your definitions.
Palantir's Ontology is older and broader than the others, because it models what a business does as well as what its data means. Palantir describes it as a digital twin of the organization. It's made of object types for real-world things and events, properties that describe them, link types between them and action types that define the changes people or agents are allowed to make, with functions holding the code-based logic that works on those objects.
The telematics company's operations team looked at it for install scheduling. In Foundry, active customer would have been a property on a Customer object type, computed by a function from linked Invoice and Device objects.
The part operations cared about was an action type along the lines of reassign install, which an agent could call only within the rules that action enforces. Agents built in AIP use those actions directly, and outside agents can reach the same objects and actions through Ontology MCP, with writes limited to the predefined actions.
Security comes from roles, mandatory markings for sensitive data such as PII, and row and column-level controls. Foundry can also read tables in Databricks or Snowflake through virtual tables without copying them, so the Ontology doesn't have to own the data underneath it.
The team passed for now. The company's pressing decisions that year were analytical rather than operational, and Foundry would have been one more platform to run. Firms that schedule crews, route freight or plan maintenance windows often reach the opposite conclusion, since the actions are what they're buying. Palantir also built its delivery model around forward-deployed engineers, and the Ontology's value in each account comes as much from that modeling work as from the software.
For the context half, the other four platforms in this guide are the Palantir alternatives most enterprises compare, and the deciding factor is where your data and agents already live. The action half is harder to replace. Outside Foundry, it usually turns into agent tools with narrowly scoped permissions, such as tools running in Amazon Bedrock AgentCore under an IAM role that can reassign an install and do nothing else, with the business rules enforced inside each tool.
Both build on semantic models a BI team has usually maintained for years, which is their main advantage. Microsoft introduced Fabric IQ at Ignite in November 2025 as the business-context layer over OneLake. Finance's customers, contracts and invoices became entity types there, linked to one another, and the 90-day rule went in next to them as a sentence anyone in finance could read. The data itself stayed in the tables finance already used.
Fabric IQ can also generate an ontology from an existing Power BI semantic model, and an update Microsoft announced in September 2026 lets Power BI measures come across with it. On Microsoft Learn the ontology item is still labeled preview, although Fabric IQ inside Copilot Chat became generally available on September 28, 2026.
For the telematics company's finance team, this was the shortest path of all. Its Power BI model already held an Active Customers measure built on the 90-day rule, so generating the ontology from that model carried finance's definition straight into the Copilot agent. The catch mirrored the Databricks trial. The Fabric ontology now encoded finance's count, and product's rule about trucks reporting in the last 30 days wasn't in it until the agreed definition replaced the old measure.
Snowflake's answer comes in two parts. Horizon Context is a capability inside Horizon Catalog that stores definitions as semantic views and collects metadata from tools such as Tableau, Power BI and dbt, and Snowflake's announcement describes semantic views being generated from existing SQL and dashboard files. Cortex Sense reads that store at query time and passes it to Snowflake's own agents, CoWork and CoCo.
Snowflake announced both at its Summit on June 2, 2026, with Cortex Sense in private preview, and semantic views can also be exposed to outside agents over MCP. The telematics company doesn't run Snowflake, so it never trialed either one. Had finance and product both kept their data in one Snowflake account, active customer would have been settled in one semantic view rather than argued over in three tools.
Where the agents would run turned out to be the deciding question for the telematics company, and it had two answers. Product analysts lived in Genie and finance lived in Copilot, so it ended up using both Genie Ontology and Fabric IQ, with the AWS accelerator holding the signed definitions in a portable form. The questions it worked through are below, along with what each answer pointed to.
|
The question the company asked |
Where it points |
What the telematics company found |
|---|---|---|
|
"Where do our governed tables and our analysts' agents already live?" |
Databricks Genie Ontology, if Unity Catalog governs them |
Product's Genie space, so the certified metric view went there first |
|
"Where does finance get the numbers it trusts?" |
Microsoft Fabric IQ, if they're Power BI semantic models |
Power BI, where the 90-day measure already lived |
|
"Do agents need to change operational records, or only read them?" |
Palantir Ontology, if Foundry runs the operation |
Only read them that year. Install scheduling stayed in the field-service app |
|
"Is Snowflake our warehouse of record?" |
Snowflake Horizon Context, with Cortex Sense for Snowflake's agents |
No, so it wasn't trialed |
|
"Is the raw lake AWS-native and governed by Lake Formation?" |
The Context Ontology Accelerator now, and AWS Context once it's available |
Yes. The sandbox kept the signed definitions in open W3C format |
Side by side, the five differ most in how meaning gets in and who approves it. The table shows where the telematics company's active customer would sit on each, with statuses as of November 10, 2026.
|
Context layer |
Where active customer would sit |
How meaning gets in |
How agents read it |
Status, Nov 10, 2026 |
|---|---|---|---|---|
|
AWS Context Ontology Accelerator |
An approved element in a graph the company owns, on Amazon Neptune |
Drafted by models on Amazon Bedrock, approved element by element |
MCP server |
Open source since July 31, 2026; self-managed |
|
AWS Context |
A business definition a steward promoted |
Inferred from Glue Data Catalog, SageMaker Unified Studio and Lake Formation |
Agentic search APIs and MCP tools, with IAM and Lake Formation permissions |
Announced June 17, 2026; coming soon |
|
Databricks Genie Ontology |
A certified metric view in Unity Catalog, plus inferred snippets |
Modeled in Unity Catalog and inferred, then ranked |
Genie One, Genie Agents and Genie Code |
Public preview |
|
Palantir Ontology |
A property on a Customer object type, computed by a function |
Modeled by engineers and domain experts in Foundry |
AIP and Ontology MCP; writes only through action types |
Generally available in Foundry and AIP |
|
Microsoft Fabric IQ |
A Power BI measure carried into the ontology, with a plain-language rule |
Generated from semantic models or OneLake data, then edited |
Fabric data agents and Microsoft Copilot |
Ontology in preview; Copilot Chat GA since Sept. 28, 2026 |
|
Snowflake Horizon Context |
A metric in a semantic view |
Semantic views, some generated from existing SQL and dashboards |
Cortex Sense for CoWork and CoCo; MCP for outside agents |
Announced June 2, 2026; Cortex Sense in private preview |
Most enterprises with mixed estates will end up running two of these, much as the telematics company did, and that's workable as long as one signed definition feeds both. Where the context lives belongs in the enterprise AI strategy rather than in each team's tool selection, because two teams choosing separately is how the company got three counts of its customers in the first place.
The work that comes before any of them. Comparing the platforms side by side took the telematics company's architects about a week. Agreeing the definition took six weeks, and most of that time went into one meeting that kept getting rescheduled between the CFO and the VP of customer success.
They settled on a paying account with an invoice paid in the last 90 days and at least one truck reporting in the last 30, excluding trials and internal test accounts. The CFO signed it, and the count came to 1,874. The data team then wrote down which system was the source of truth for each part of it: the ERP for invoices, the telemetry stream for devices and the CRM only for contract dates.
Next came the questions. The CEO's and CFO's staff collected 25 questions they actually ask in a quarter, from how many active customers churned last month to which region added the most, and wrote down the expected answer for each. Every platform the company trialed was run against those 25, and that test set is what caught the Databricks and Fabric IQ trials each learning a different team's count.
Permissions travel with the context on every platform, too. The definition of active customer is safe for anyone to read, but revenue per customer isn't, and the AWS, Databricks and Snowflake designs all check access when the query runs. That's the same rule that decides whether AI agents in production can be trusted with customer data, since an agent should see what its user is allowed to see and nothing more.
Once the meaning was settled, the agent work moved quickly, which matches what we see in agent builds generally. In Hibu's conversational analytics project, a purpose-built MCP connector gave Claude search across 1.82 million inbound lead calls a month, and answers that had waited 2 to 3 days in an analyst queue started arriving in under 5 minutes.
Mactores is the agent-native AWS modernization firm, and context work starts where the platforms' documentation stops, with the definitions. A forward-deployed engineer sits with the owners of your most contested terms, maps each one to its source systems and builds the test questions with your team.
On AWS we implement the result end to end. On Databricks, Fabric or Snowflake, we deliver the signed definitions, source map and test set in a form the platform your agents run on can load.
Agents handle the repeatable parts, such as profiling sources, drafting candidate definitions and generating test cases, while engineers own the decisions and the sign-offs. The engagement runs on a fixed date and a fixed fee, the same model behind our AI agent development services. The first step is a 30-minute working session with the engineer who'd own the work, and you only need to bring one contested definition.