Agentforce, Genie One and the Merger Problem: Why Meaning, Not Data, Is the Hard Part

Two stacks, layer by layer

Every layer of the Salesforce stack has a Databricks counterpart, though not always at the same maturity. Reading across a row compares like with like; the highlighted rows, coworkers and customer data, are the pairs that matter most in a merger.

The most important difference is structural. In Salesforce, Data 360 (formerly Data Cloud) does two jobs for Agentforce at once: it holds the customer data and supplies its business meaning. In Databricks, those jobs are split across three pieces. The lakehouse and Unity Catalog hold the data, Genie Ontology supplies the meaning, and Lakebase holds operational state.

You can see this in how each coworker answers a question. Agentforce’s Atlas Reasoning Engine plans the task, grounds itself in Data 360, passes through the Einstein Trust Layer for permissions and masking, then acts on CRM records through flows, Apex or APIs. Genie One works out what the question means using Genie Ontology, which learns definitions such as “ARR” from your tables, dashboards and documents. It then writes SQL against governed tables and metric views in Unity Catalog, and returns a cited answer, report or scheduled task.

Where does Lakebase fit? It is Databricks’ serverless Postgres, the transactional store for data apps and for agent memory and sessions. It is not where Genie One finds its answers; those come from the lakehouse. Databricks has announced an architecture (LTAP) to put Lakebase and the lakehouse on one copy of data, but it is still listed as coming soon.

Comparing like with like

The short version: Salesforce is stronger wherever work ends in a customer action, and Databricks is stronger wherever it depends on data from across the whole business.

The data layer: Data 360 vs the Databricks data stack

Databricks has no single product that matches Data 360. Its answer is a combination, including the new CustomerLake for CDP functions.

Data 360 wins on customer activation today: it is mature, native to the CRM and operable by admins without a data engineering team. The Databricks stack wins on breadth. Finance, supply chain and product data sit beside customer data, models are trained where the data lives, and one semantic layer can serve the whole enterprise.

The agent layer: Agentforce vs the Genie family

Agentforce acts where customer work happens, and its tooling for running agents in production is the more complete of the two. Its view of the business, though, stops at what lives in Salesforce, and its metering is easy to underestimate. Genie answers from governed data across the whole enterprise and reaches people in the tools they already use. But it does not natively change a customer record, and its accuracy depends heavily on how ready the data is.

How the two stacks connect

For companies running both, this is not either-or. The stacks already connect at two levels: data at the base, where the link is production-ready, and agents at the top, where it is still early.

The data bridge is ready today. Data 360 File Sharing into Unity Catalog has been generally available since October 2025: a Data 360 share appears in Databricks as a catalog, queried in place with no pipelines. In the other direction, zero-copy federation lets Data 360 read lakehouse tables in place, so Agentforce can be grounded in usage, financials and model scores that never leave Databricks.

The agent bridge is forming. Databricks exposes each Genie Agent as a managed MCP server that other agents can call, and Agentforce can now orchestrate third-party agents over A2A. In June 2026 the two companies also expanded their partnership, adding federated authentication, federated search and MCP integrations, and said they are exploring surfacing Agentforce agents through Databricks’ AI gateway. The direction is clear, but much of it is new, so prototype before you commit.

Who should own which layer

In a stable enterprise running both platforms, a sensible default is to let Databricks own the data and its meaning, let Salesforce own customer actions, and let each coworker serve the people who already work in its platform.

That split works when there is one company, one set of definitions and one owner for each layer. A merger or a separation removes all three at once.

What changes when companies merge or split

In a merger, two sets of definitions, orgs, workspaces and agents must converge without disrupting the business. In a carve-out or demerger, one set must be cleanly divided, often while a transition services agreement (TSA) keeps both sides running on shared systems.

Agentic AI raises the stakes. A dashboard with the wrong number gets questioned. An agent with the wrong number acts on it: it emails the wrong customer, prices a renewal off the wrong contract, or shows one entity’s pipeline to the other.

Zero-copy sharing is the most underused tool in all of this. Before anything is migrated, the acquirer can read the target’s Data 360 data in place through Unity Catalog, so leaders can ask Genie One questions across both companies early on. In a separation, sharing gives the departing entity read access during the TSA without leaving behind copies that later must be found and deleted.

Two cautions apply. Before legal close, competition rules often limit what each side may see of the other’s data, so early visibility should run through clean-team rules or a data clean room. And every day one shortcut needs an owner and an end date, or it quietly becomes permanent architecture.

The real bottleneck: agreeing what the data means

The table above makes integration look like a technical exercise. In our experience, it rarely is. A pattern we have seen repeatedly in Salesforce and Databricks integrations (described here as a composite, without client detail) shows why.

Two companies came together, each running Salesforce for sales and service, and Databricks for analytics. On paper it was simple, with only a handful of data sources: two Salesforce orgs, a billing system, and the lakehouse. The difficulty sat elsewhere:

• Same names, different maths. Both companies reported “ARR”, “active customer” and “renewal rate”, but calculated them differently: whether one-time fees counted, how multi-year contracts were annualised, how long a customer stayed “active” after their last purchase.
• Different data models. One company tracked subscriptions on custom objects linked to accounts; the other tracked them through opportunity products. The same business fact lived in different shapes.
• Logic buried in the platforms. The real definitions were spread across formula fields, Apex, flows, report filters and notebooks, rarely written down anywhere.

The traditional approach was to reverse-engineer each calculation by hand, then run workshops to bring finance, sales operations and IT from both companies to the same table. Every workshop surfaced another edge case. Getting everyone aligned took weeks, often months, and nothing could be built until it was done. Multiply that across every metric and every domain, and the programme runs for years.

How AI turns years into weeks

AI doesn’t remove the need for people to decide what “revenue” means. It removes most of the work of finding out what each side currently means by it, and that is where the years went. With an AI model such as Claude working alongside the team, the sequence changes:

• Extract. AI reads both orgs’ metadata (formula fields, Apex, flows, validation rules, report definitions) and the Databricks SQL and notebooks, then writes out in plain English how each metric is actually calculated today, with its lineage.
• Compare. It lays every definition side by side, showing where the two companies agree, where they differ, and what each difference is worth when both versions run on the same data.
• Decide. Stakeholders review a short list of real decisions, each with its impact in numbers, instead of reverse-engineering logic in workshops. Agreement comes in days, because the disagreement is visible and quantified.
• Build. AI drafts the data model mapping, the transformation code, the Unity Catalog metric views and Data 360 mappings, and the tests that reconcile new numbers against legacy reports.
• Verify. People own every decision and every sign-off. Reconciliation tests prove the new numbers before any agent or dashboard is pointed at them.

Programmes that once ran for years can now finish in weeks. But AI compresses the discovery and the build; it doesn’t fix everything. The issues that still sink large migrations are mostly about sequence and ownership:

• Migrating technical debt. Inventory what is actually used and archive the rest rather than moving it.
• Translating the security model. Salesforce role hierarchies and sharing rules don’t map cleanly to Unity Catalog grants, and agents inherit any gaps. Design the target access model explicitly and test it with real user personas.
• Dual running costs. Consumption meters run on both estates during the parallel run. Cap them and set a decommission date.
• Building agents too early. Agents grounded on data that is still moving must be rebuilt. Build them last, then re-ground and re-test after every migration wave.
• Knowledge walking out. The people who understood the legacy estate often leave after the deal, and integrators roll off at go-live.

The team that owns the bridge

That last point is the one we would underline. The vendors have built the plumbing, and AI has collapsed the time it takes to agree on meaning. What no product provides is the team that owns the result: people who know both platforms, keep the definitions canonical, and are still there after go-live. Integrations that skip this tend to get redone a few years later.

How that team comes together varies. Some companies need a short advisory engagement to settle the target architecture and the order of work. Some need specialists embedded alongside their own people for the migration itself. Companies building or scaling a Global Capability Centre in India often prefer a build-operate-transfer arrangement, where a partner builds and runs the team until it is stable and then hands it over, people and know-how intact.

At Abilytics, our leadership has spent more than 25 years on programmes like these, across Salesforce, data platforms and large integrations, and we have worked in all three of those ways. If you are facing a merger, a separation or a platform move of your own, we are always happy to compare notes.