Skip to main content
Plexara
Field notes / architecture

The data clouds converged on one bill of materials

Between May 2025 and October 2026 the large data and application platforms each assembled the same five parts for AI agents: an operational store, ingestion, managed MCP, agent governance, and a context layer. The buyer’s question is where those parts should sit.

10-minute readArchitecture

Five companies, the same parts

Read the acquisition and launch announcements from the large data and application platforms between May 2025 and October 2026 side by side and the same shopping list repeats. Snowflake bought a Postgres company, shipped managed ingestion and a managed MCP server, and agreed to buy a company that governs agent access over MCP and another that maps lineage and discovery into its catalog. Databricks bought a Postgres company, shipped managed MCP servers under its catalog permissions, and previewed an ontology. Salesforce completed its Informatica acquisition. ServiceNow bought an enterprise assistant and a data catalog. Fivetran bought a reverse-ETL company and merged with dbt Labs.

Each move made sense on its own. Together they describe one design. It helps to derive it from first principles before looking at who bought what, because the parts follow from what an agent needs in order to do real work against company data.

What an agent needs to do real work

An agent that only answers questions needs read access and some idea of what the data means. An agent that does work needs more. It needs somewhere to write what it builds and collects: a submitted form, a reconciled table, the state an automation carries from one run to the next. It needs data and events arriving from other systems. It needs a standard way to call tools, so the same work runs whichever model is driving. It needs an identity with permissions and a record of every call, so somebody can answer for what it did. And it needs the business meaning of the data, or it will compute the wrong number with confidence.

Those five requirements map onto the five parts the platforms bought: an operational store, ingestion, managed MCP, agent governance, and a context layer.

Five parts, from what an agent needs

  1. 01

    Operational store

    Somewhere to write what it builds and collects

  2. 02

    Ingestion

    Data and events arriving from other systems

  3. 03

    Managed MCP

    A standard way for any agent to call tools

  4. 04

    Agent governance

    An identity, permissions, and a record of each call

  5. 05

    Context layer

    What the data means, in terms the business uses

Each part answers one requirement of an agent doing real work against company data. Take any one away and the work stops or becomes ungoverned.

The ledger

The ledger below lists the moves by company and by part. It is a record of acquisitions and launches in an eighteen-month window, not an inventory of every capability each company has; several already had parts of the design before May 2025. The pattern is in the dates. The operational store and the ingestion pieces landed first, in mid-2025. Managed MCP followed through late 2025. Governance of agent access and the context layer came in 2026.

Two vendors outside the ledger point the same way. Microsoft introduced Fabric IQ with an ontology at its core, a shared vocabulary for agents over Fabric data. Google moved Vertex AI into its Gemini Enterprise Agent Platform, a single place to build, govern, and run agents.

The moves, part by part

PartSnowflakeDatabricksSalesforceServiceNowFivetran
Operational store

Jun 2025Agreement to acquire Crunchy Data (Postgres)

Feb 2026Snowflake Postgres generally available

May 2025Agreement to acquire Neon (serverless Postgres)

Jun 2025Lakebase, Postgres on Neon, in public preview

Ingestion

May 2025Openflow generally available (managed ingestion)

Oct 2026Openflow Endpoints generally available (HTTP into flows)

Nov 2025Informatica acquisition completed (integration, catalog, MDM)

May 2025Agreement to acquire Census (reverse ETL)

Managed MCP

Nov 2025Snowflake-managed MCP server generally available

Jun 2025Managed MCP servers in beta, under Unity Catalog permissions

Agent governance

May 2026Intent to acquire Natoma (governance of agent access over MCP)

Context layer

Nov 2025Agreement to acquire Select Star for Horizon Catalog

Jun 2026Genie Ontology in public preview

May 2025Agreement to acquire data.world (catalog and governance)

Dec 2025Moveworks acquisition completed (enterprise assistant and search)

Jun 2026Merger with dbt Labs completed (transformation and metrics)

Acquisitions and launches between May 2025 and October 2026, from each company’s own announcements and documentation. An empty cell means no move in this window, not a missing capability. Fivetran includes Fivetran + dbt Labs after June 2026.

The order the parts arrived

Plotted over time, the convergence is fast. In eighteen months five companies with different starting points, a warehouse, a lakehouse, a CRM, a service desk, and a pipeline business, each added the parts they lacked. None of them added the same parts in the same order, because each started from a different center.

Eighteen months, five companies

Snowflake
Databricks
Salesforce
ServiceNow
Fivetran
May 2025Sep 2025Jan 2026May 2026Sep 2026
Operational storeIngestionManaged MCPAgent governanceContext layer
Each mark is one move from the ledger above, on the row of the company that made it and in the color of the part it added.

The protocol became neutral

One part changed character during the same window. In December 2025 Anthropic donated the Model Context Protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI and supported by Google, Microsoft, AWS, Cloudflare, and Bloomberg. The July 2026 specification made the core stateless and added MCP Apps and Tasks as extensions, and the main SDKs were downloaded close to half a billion times a month.

That matters for the buyer more than for the vendors. When every model speaks the same protocol, the choice of model and the choice of data platform come apart. A company can pick the model that suits each task and keep its access, its permissions, and its knowledge in one place. Every platform in the ledger now ships an MCP server, so the useful comparison is what each server stands in front of.

The question is where the center sits

Every platform in the ledger assembled the five parts around its own center of gravity. The warehouse vendors built them around data that has been moved into the warehouse. The application vendors built them around the records their applications hold. The pipeline vendor built them around data in motion. Each design works best for the work that already happens at its center, and that is a sound design for a company whose work does.

Most mid-market companies are not organized around one center. Their customer record is in one vendor’s CRM, their orders in another vendor’s ERP, their history in a warehouse, their events arriving from a storefront and a dozen SaaS tools, and their people using whichever assistant they prefer. For them the useful question about the bill of materials is not which vendor has the most complete set of parts. It is whether the parts sit across the systems the work actually touches, and whether they work with every model the company will use.

The same five parts as a managed layer

Plexara delivers the same five parts as one managed deployment that sits across the systems a company already runs. Data stays in the systems that hold it, and queries reach it where it lives. What agents build and collect, from form submissions and webhook events to registered tables and automation state, is kept in the deployment beside those systems. Claude, ChatGPT, Gemini, and the models that replace them reach everything through one MCP endpoint under the same roles and the same audit trail. The catalog and the knowledge graph give every agent the same reviewed meaning across every system.

Deasil runs, upgrades, and monitors the deployment, so the company gets the parts without assembling them. Systems of record stay covers what moves onto those parts one workload at a time, and the capability matrix covers each category in detail.

The same five parts, across your systems

PartWhat Plexara deliversWhere it reaches
Operational storeForm submissions, webhook events, filed email, registered tables, automation state, and saved reports, kept in the deployment, with every table queryable in SQLBeside the systems of record, which keep their own data
IngestionWebhook sources with named sender presets, a read-only mailbox source, forms, spreadsheets registered as tables, and automations that load from APIsFrom any system that can send an event, an email, or answer an API call
Managed MCPOne remote MCP endpoint for Claude, ChatGPT, Gemini, and the models that replace them, plus an MCP gateway to other vendors’ serversIn front of every connected system at once
Agent governanceSign-in through your identity provider, roles that decide which tools and connections each person reaches, automations that run under their author’s saved roles, and an audit row for every call with its stated purposeThe same rules for every agent and every model
Context layerA catalog of every connection with glossary, tags, domains, and lineage, and a knowledge graph that turns reviewed corrections into shared knowledgeAcross every system the company connects
Each part is part of one managed deployment that Deasil runs, upgrades, and monitors. Data stays in the systems that hold it; queries reach it where it lives.

Further Reading