OSI Arrives: A Common Language for Enterprise AI Agents

Breaking: a common language for agentic AI

On September 23, 2025 a coalition led by Snowflake, Salesforce, dbt Labs, BlackRock, and RelationalAI announced Open Semantic Interchange, a vendor neutral specification for exchanging business meaning across tools and platforms. Think of it as a Rosetta Stone for metrics, dimensions, relationships, and governance rules. The stated goal is simple and bold: define business meaning once and have every system and agent understand it the same way. The coalition positioned the launch as a turning point for interoperability and trust. See the core details in the Snowflake press release on OSI.

The timing matters. Enterprises are shifting from dashboards to agents that plan, call tools, retrieve knowledge, and act, as the enterprise agent stack goes mainstream. These agents fail if they cannot agree on what a customer is, which orders count as revenue, or which policy blocks access to personal data. OSI targets that failure mode directly by standardizing the semantic layer that sits between raw data and intelligent behavior.

Why agents stalled on semantics

Agents are only as reliable as their grounding. Without a shared semantic layer, the same question can yield three different answers depending on which tool is asked. A revenue number in your business intelligence tool excludes refunds, your warehouse view includes them, and your finance system applies a settlement lag. An agent that tries to reconcile those without guidance does not look intelligent. It looks confused.

OSI proposes to carry the shared guidance that agents need. It introduces a portable way to describe the things a business cares about and how to compute them: entities like Customer and Product, attributes like region and lifecycle status, metrics like net revenue, hierarchies like country to region to market, relationships like Customer has many Orders, and constraints like privacy policies. The point is not new math. It is the promise that every tool and every agent can read the same description and apply it consistently.

A useful metaphor is Unicode for business meaning. Unicode did not invent words. It gave every system the same code points so a character typed on one device renders the same on another. OSI aims to do the same for business semantics. A metric called active_customer_count should resolve to the same logic and the same filters whether it is calculated in an analyst notebook, a customer service console, or an agent workflow.

What OSI standardizes and why that unlocks tool use

From the launch materials and early partner statements, OSI focuses on a few practical objects that agents need to do real work:

• Metrics and their definitions. A metric specifies its calculation, grain, default filters, and time logic. This allows agents to compute or fetch the correct number without reinventing the query every time.
• Dimensions and hierarchies. Agents need to know which dimensions slice a metric, how those dimensions roll up, and what the valid values are. This is crucial for tool selection and parameter filling.
• Entities and relationships. Agents need a map of the business domain to traverse join paths confidently. Without this, even a simple cross system query becomes guesswork.
• Policies and classifications. Agents must respect rules such as masking personal data for certain roles or blocking exports to external tools. Governance cannot be an afterthought.
• Provenance and lineage hints. If an agent explains where a number came from, humans trust it more. Equally important, if a number is deprecated, the agent should know to avoid it.

These objects are not theoretical. They feed directly into how an agent grounds a request, chooses tools, and forms function calls. Consider the user prompt: “Email our active customers in North America who downgraded last quarter and offer 10 percent retention credit.” With OSI, the agent can resolve active customer to the approved definition, identify the correct dimension for geography, pick the downgrade event, compute the cohort with the right time window, and call the messaging tool with a policy check on PII. Without OSI, the agent guesses and improvises.

Here is how an OSI flavored snippet might look in practice. The exact syntax will evolve, but the point is the shape and the references that tools and agents can share:

entity: Customer
attributes:
  - customer_id: string
  - region: string
  - lifecycle_status: enum[active, churned, prospect]
relationships:
  - orders: Order[] by customer_id

metric:
  name: active_customer_count
  definition: count_distinct(Customer where lifecycle_status = 'active' and last_purchase_date >= today - 180d)
  dimensions: [region]
  grain: monthly

policy:
  name: pii_masking
  applies_to: [Customer.email]
  rule: mask_hash

function_binding:
  name: crm_lookup
  input: { customer_id: string }
  output: { Customer }
  source_system: CRM_API

With artifacts like these, an agent can resolve meaning, discover valid tools, and enforce policies before it acts.

What this means for dbt Semantic Layer and LookML

For years, teams have expressed business logic in platform specific languages. The dbt Semantic Layer lets you model metrics near the data transformation code. LookML encodes dimensions, measures, and explores inside Looker. These investments do not disappear with OSI. They become upstream sources for a common contract.

Expect two practical patterns to emerge:

• Exporters that translate existing definitions to OSI. dbt can export metrics, dimensions, tests, tags, and exposures into an OSI package. LookML can map views and measures to entities, attributes, and metrics. This preserves the single source workflows teams already use while making the results portable.
• Importers that hydrate tools from OSI. A new agent, a notebook, or a catalog can ingest the same package and expose the same meanings without reimplementation. If a definition changes, every consumer updates together.

There will be gaps to bridge. LookML explores imply join paths that need to become explicit relationships. dbt tests and tags need a mapping to OSI constraints and classifications. Naming conflicts must be resolved. The good news is that the friction pays off. Once a team has an OSI package, it can point any tool at the same business truth.

Retrieval pipelines get cleaner and smarter

RAG pipelines often stumble on two problems. They retrieve the wrong context, or they retrieve the right text but the agent does not know how to use it. OSI helps on both fronts.

• Better chunk metadata. When you chunk documents, attach OSI identifiers. A policy document section can reference the same policy id that the metric does. A product glossary page can reference the Product entity and its attributes. Now retrievers can filter and rank based on structured meaning, not just vector similarity.
• Structured reasoning. When the agent sees a query about net revenue, it can ask for the OSI metric definition first, then retrieve only facts that mention the same metric id, then call the correct function with parameters that match dimension names and types. This breaks the brittle pattern of guessing from text alone.
• Cross system joins with confidence. If the agent needs to join support tickets to revenue by account_id, an OSI relationship tells it that the join is valid and how to do it. That reduces both hallucinations and security mistakes.

The result is less glue code and more predictable behavior.

Governance becomes a first class feature

Governance is not only about saying no. It is about making the right behavior easy. OSI puts policy and classification next to the metrics and entities they govern. That means:

• Role aware tool use. If a policy masks Customer.email for a contractor role, the agent knows to apply masking when a contractor runs a workflow. The rule travels with the data meaning, not with a single dashboard.
• Auditable decisions. When an agent publishes a number, it can include the metric id, the version, the dimension values, and the policy checks applied. Auditors can trace the decision without reverse engineering a transient prompt.
• Safer sharing. An OSI package can be shared with a vendor or partner in a limited form. The definitions travel, while sensitive attributes remain masked or omitted.

Salesforce has framed the initiative as essential to an agentic future where business meaning is preserved across every platform. Their view aligns with how Tableau already moves metadata across its ecosystem. For more detail on that perspective, read Salesforce’s agentic future and open semantic layer. This also aligns with how identity is the control plane thinking pushes policy into the execution path.

A pragmatic 30 day OSI ready checklist

You do not need a standards body or a year long program to get value. Here is a focused plan to pilot one agent using unified business semantics in 30 days.

Week 1. Pick a needle mover and define success

• Choose one decision loop with measurable impact. Examples: reduce invoice disputes, speed onboarding approvals, or recover churn risk. Write the before and after in one paragraph with the exact metric and target.
• Form a squad. Data modeler, analytics engineer, product owner from the business, one agent developer, and one security partner.
• Inventory current definitions. Pull the dbt metrics, LookML measures, and any spreadsheet logic that touch your target outcome. List overlaps and contradictions.
• Decide the canonical names. Before any tooling, agree on the vocabulary. Five to twenty entities and ten to thirty metrics is ideal for a first package.
• Define a success guardrail. For example, the pilot agent must never expose raw email addresses to a contractor role.

Deliverables by day 7: a one page goal, a named glossary, a draft of three core metrics with tests, and one explicit guardrail policy.

Week 2. Create an OSI seed and connect the plumbing

• Export existing semantics. Generate an initial OSI package by translating dbt and LookML definitions. Where translations are lossy, add explicit relationships and constraints.
• Add policy and classification. Tag sensitive attributes and attach the guardrail policy to the relevant objects. Include lineage notes for any derived metrics.
• Stand up a semantic registry. This can be a simple repository with versioned OSI packages and a changelog. Adopt semantic versioning and require a reviewer for changes.
• Bind at least two tools. Connect a warehouse function or SQL runner and a messaging or ticketing system to the OSI functions. The bindings should be discoverable by name and type.
• Prepare retrieval. Enrich your document chunks with OSI ids for the entities and policies they reference. Rebuild the index with these tags in metadata.

Deliverables by day 14: a versioned OSI package, two tool bindings, a retriever that can filter on OSI ids, and a smoke test that validates policy masking.

Week 3. Build and harden the agent

• Ground in OSI first. Teach the agent to resolve any user request to OSI objects before taking action. If it cannot resolve a term, escalate to a human glossary check.
• Generate plans with typed steps. Plans should reference metric ids, dimension names, and function bindings explicitly. Prohibit ad hoc SQL in the pilot.
• Add unit tests and red teams. For each function, write tests that validate correct parameterization from OSI objects. Run adversarial prompts that try to bypass policy or rename sensitive fields.
• Instrument everything. Log which OSI ids were used, which policies were applied, and the final decision. Make this trace available for review.

Deliverables by day 21: an agent that completes the end to end task, a test suite, and an instrumentation dashboard that shows the OSI trail.

Week 4. Prove value and plan the rollout

• Run a controlled trial. Compare agent outcomes to a human baseline for one or two weeks of historical or live workflows. Track precision, recall, and cycle time. For test design ideas, see our look at a bank-grade AI agents pilot.
• Write the operating guide. How to request new metrics, how to change definitions, how to add a tool binding, and how to request policy exceptions.
• Decide on the next two domains. Pick areas with shared entities to maximize reuse, such as turning Customer and Order into the core of a revenue and support expansion.

Deliverables by day 30: a quantified improvement, a short operating guide, and a roadmap with two follow on pilots.

Concrete examples of value

• End the revenue debate. Define net_revenue once, with refunds excluded and a three day settlement lag. Every tool and the agent agree. Close monthly reporting one day earlier and stop reconciling conflicting numbers.
• Better service triage. Attach churn_risk to the Customer entity with a five point scale and a lookback window. The agent prioritizes cases with high risk and proposes a retention credit defined in the same package.
• Safer data sharing. Mark invoice_line.description as non sensitive and Customer.email as sensitive. The agent can export invoices for vendor review without exposing personal data.

Risks and how to reduce them

• Specification maturity. Early standards evolve. Protect yourself with a registry, versioning, and automated translation tests so changes do not break agents.
• Translation gaps. Not every LookML or dbt nuance will map one to one. Track exceptions in code, not in a wiki, and propose extensions back to the community.
• Vendor alignment. Even with a shared spec, different tools may emphasize different features. Pilot with a thin slice, prove value, then bring more tools to the table.
• Glossary drift. Business terms change fast. Make the glossary a living artifact with owners and a change process.

How vendors will likely implement OSI

Expect a two way street. Tools will export their internal semantics to OSI so others can read them, and they will import OSI so they can act on shared meaning. Warehouses and lakehouses will expose function bindings that reference OSI entities and metrics. Business intelligence tools will render metrics and filters based on OSI directly. Catalogs will index OSI packages and show lineage and policy in one place. Agent platforms will plan with OSI ids rather than raw text and will validate actions against OSI policies before execution.

One detail worth watching is how the ecosystem treats policies and testing. If policy and test artifacts travel with metrics, teams can move faster with less risk. If they do not, agents will be brittle again. Put policy and tests in the same package as the metrics from day one.

The takeaway

Open Semantic Interchange is not about new math or new dashboards. It is about agreeing on meaning so humans and agents can work from the same playbook. With a shared semantic contract, tools stop arguing and start cooperating. If you pick one workflow, one glossary, and one agent, you can prove the value in a month. That is how a standard becomes real: not by promises, but by teams shipping outcomes that everyone can trust.