Why point-solution catalogs and semantic layers are not enough

Multi-hop workflows are fragile. If the catalog MCP server returns a dataset name that does not exactly match the query engine table name, the agent must reconcile the mismatch. If the catalog uses one naming convention and the query engine uses another, the agent must translate. Each translation step is an opportunity for error.

Timeout and rate-limiting failures are amplified in multi-hop workflows. If the catalog call succeeds but the query engine call is rate-limited, the agent has partial context. If the query engine call succeeds but a subsequent catalog call for business context times out, the agent returns results without context. The user sees numbers without meaning.

Session coherence is another failure mode. If the catalog metadata changes between the discovery call and the query call, the agent may query a dataset that has been deprecated, renamed, or moved. Multi-hop workflows have no transactional consistency across the hops.

Semantic layer vendors face the same structural limitation from the opposite direction. They define metrics, dimensions, and business rules. They know that "revenue" means a specific calculation applied to specific columns with specific filters. What they cannot do is execute the query.

When an agent asks a semantic layer MCP server for revenue, the semantic layer translates the request into SQL and passes it to the underlying warehouse for execution. The semantic layer is a translation layer, not an execution layer. It depends on the warehouse connection being available, correctly configured, and authorized for the requesting user.

This delegation means the semantic layer cannot enforce governance at execution time. It can define that certain metrics require certain permissions, but enforcement depends on the warehouse honoring those permissions. If the warehouse connection uses a service account with broad access, the semantic layer permissions are effectively bypassed.

When context lives in the catalog and execution happens in the query engine, governance policies defined in one system may not be enforced in the other. The catalog says a dataset is PII-classified. The query engine does not check the catalog before executing a query against that dataset.

This gap is the normal operating condition in most enterprises. Catalog governance policies are aspirational: they describe what should happen. Query engine access controls are operational: they determine what actually happens. The two are maintained by different teams using different tools with different update cycles.

AI agents amplify this gap because they interact with both systems programmatically at high speed. A human analyst might check the catalog before querying sensitive data. An AI agent will take the most efficient path to results, which may bypass the catalog entirely if the query engine is directly accessible.

The architectural solution is to unify context and execution in a single platform. When the same system that executes queries also manages metadata, governance enforcement is inherent. A PII classification in the catalog directly affects what the query engine returns. An ownership change immediately updates access controls. A deprecation warning appears in every query response.

This unification eliminates multi-hop workflows. One tool call returns results with full business context. No reconciliation between catalog names and query engine names. No partial context from timed-out secondary calls. No governance gaps between systems maintained by different teams.

It also removes the integration tax of stitching together five vendors. In Plexara, the catalog, query engine, governance layer, semantic enrichment, and agent framework are layers of one platform. There is no glue code to maintain and no second system for a governance policy to fall between.