Opal tools return a preview of the planned change, including field types and relation mapping, plus a confirmation step. The user confirms. The schema is live.

What this changes, team by team

The productivity story varies by role, but the shift in each case is the same: people who understand what they need now get it without routing through someone else.

Marketing and campaign teams stop filing tickets for data model changes. Need to add a mobile app identifier before a campaign goes live? Ask for it, confirm the preview, and it’s done before the meeting ends.

Data analysts and scientists onboard faster. Instead of reverse-engineering an undocumented schema or interrupting an engineer to ask what the events object contains, a new analyst asks: "What objects do we have?" Then: "Show me the customers object with all its fields." The analyst gets a complete picture of the data model, all from a conversation.

Engineers and developers get their time back. The team that needed it now handles the work that required API access. Developers move from fielding low-complexity requests to building what requires their expertise.

The safety model is designed for production. Every create operation returns a preview of the planned change and a single-use, time-limited confirmation token before anything executes. Cryptography binds that token to the original request. If anything changes after it's issued, the system rejects the request. Think of it as the natural language equivalent of a pull request review.

Why this architecture works in practice

We applied our Opal ODP Tools to cover 11 operations across all four core ODP entity types (objects, fields, relations, and identifiers) with list, inspect, and create capabilities across each. That covers the full lifecycle of schema management, from exploration and onboarding through active extension.

The integration layer handles resilience, per-request credential scoping, and a consistent error pattern. These aren't afterthoughts; they're what separates a compelling demo from something you'd trust with production data.

One deliberate investment deserves attention: each of the 11 tools ships with rich descriptions, use cases, and examples, the kind of semantic depth that makes a conversational interface reliable. When a user says "tables" or "dimensions" instead of "objects," Opal tools map the request correctly. That behavior is built into how the tools are described.

The bigger shift

Our Opal ODP Tools are a specific solution for a specific platform, and it's also evidence of something worth watching at the strategic level.

AI investment in this space has gone toward conversational BI, letting business users ask questions of data that already exists. That's useful, and it's also the easy half of the problem. It leaves the underlying platform (the schema, the structure, the data model itself) locked behind the same API wall it always was. What's missing across the industry is conversational operations: AI that doesn't just answer questions about the platform, but acts on it, safely, on behalf of the people who depend on it.

From our experience, the real value comes from AI that operates the platform, not one that only queries it. Query layers give teams read access. Operations layers give them the ability to shape the system.

This solution exists for Optimizely Data Platform today. But the pattern isn't unique to ODP. Any platform with a complex API, such as a CDP, a CMS, a marketing cloud, an analytics tool, creates the same problem for the business teams who depend on it. And the same solution applies.

Enterprise software is opening up to a new class of operator: whoever builds the layer that makes the API disappear.

See where your platform's API bottleneck is costing you velocity. Talk to our Optimizely practice about an assessment to get a high-level analysis of where you stand.