How to Keep Claude, Slack, and BI Tools Using the Same Metric Definitions

Keep Claude, Slack, and BI tools consistent by routing their calculations to the same governed metric source and giving each consumer an explicit path to approved business context. Record the metric, context revision, reporting period, identity, and data cutoff behind each answer. A shared glossary helps, but it cannot make a tool use a definition that its execution path bypasses.

The data team's job is to maintain those paths. Business experts supply the meaning and exceptions; integration owners make sure each assistant, bot, and dashboard actually consumes them. Start with one recurring question and trace it through every surface before expanding the system.

Product documentation reviewed October 5, 2026. The contract and examples below are recommended operating practices. Examples are hypothetical, not customer deployments or Orion configuration formats.

What does consistent context across AI agents mean?

Consistent context means that consumers use the same approved interpretation for the same question, audience, and reporting conditions. It does not require identical wording, and it does not mean every user should see the same data.

A finance dashboard and a Slack assistant should agree on net revenue when they use the same governed metric, period, filters, permissions, and data cutoff. A sales dashboard can legitimately report bookings instead. The problem is a tool silently calling bookings “revenue,” rather than a business having multiple useful measures.

An AI context layer is the maintained information an agent uses around its data: terminology, metric references, operating events, exceptions, source authority, and rules for resolving ambiguity. Context portability means another consumer can retrieve and interpret that information. Consistent answers additionally require a compatible calculation path and a verified refresh process.

The useful question is therefore specific: “Which source did this consumer use, under which conditions?” A document being available somewhere in the company does not answer it.

Which definitions should stay in dbt?

Keep governed calculations in the system your data team already maintains. The dbt Semantic Layer defines metrics on existing models and uses MetricFlow to handle joins. Its APIs and integrations let downstream applications consume those definitions. dbt also documents access from compatible AI clients through its MCP server.

Additional business context should reference that metric and explain how to use it. For example, a revenue review note can identify the approved measure, fiscal period, owner, and a one-time pricing event. It should not become an independently maintained version of the revenue formula.

If your authoritative logic lives in another governed system, apply the same principle there. Choose one owner and source for each calculation; document any migration deliberately. Adding an agent is a poor reason to create another metric implementation.

For the broader distinction, see Semantic Layer vs. Business Context. This guide focuses on how consuming tools use that foundation.

Why do tools disagree even when they share a glossary?

Inspect four possible breaks before editing a prompt.

1. The metric path differs. One consumer calls the approved metric; another generates SQL against raw tables; a third maintains a local calculated field.
2. The interpretation differs. All three can calculate valid measures, but “revenue” maps to a different one for each consumer.
3. The reporting conditions differ. Time zones, cutoffs, filters, data refreshes, or permissions produce different populations.
4. The update path differs. A knowledge page changed, but a copied prompt, imported document, cached answer, or saved analysis still contains the old information.

These failures require different repairs. A glossary correction cannot fix a dashboard calculation. Refreshing data cannot resolve an ambiguous metric name. Allowing broader access to make numbers agree can create an unauthorized disclosure.

Record disagreement as a specific difference in sources or conditions. Comparing the final sentences alone makes diagnosis harder.

Anthropic's first-hand account of its internal analytics system describes curating canonical datasets and routing agents to governed definitions. It also assigns humans responsibility for curation and ownership. That is useful implementation evidence for the architecture; it does not establish that another product or deployment has the same controls.

What should every consuming tool promise to use?

Create a consumer contract for each important question. A consumer contract is a short agreement about the sources, scope, refresh behavior, and evidence a tool must use. It is an operating record your team can maintain in a document or repository, not a new product you need to buy.

The following contract is hypothetical. Replace its names and policies with approved ones from your environment.

Do not claim a contract is enforced merely because it is written down. The integration owner should demonstrate each row with an actual request. If a tool exposes no revision identifier, record that limitation and preserve the source content or timestamp available to you.

Inspect observable evidence: retrieved documents, tool calls, queries, and results. A model's private reasoning is unnecessary for this check.

How do you connect Claude, a Slack bot, and a BI dashboard?

Use a small inventory before changing any integration. The same business contract can have different implementations.

For Claude, inspect the tools configured in the actual client and identity being used. dbt's remote MCP setup documentation describes authentication and controls for disabling tools or toolsets. Make the permitted paths explicit. A prompt instruction to use approved metrics is weaker than removing an unintended alternative execution path where your application and access policy allow it.

For a custom Slack bot, treat the bot as an application consuming your metric and context services. Handle authentication, request completion, and evidence links in that application. The word “Slack” describes where the question arrives; it says nothing about which definition the bot uses.

For a BI tool without a native Semantic Layer connection, dbt exports can write saved-query results into tables or views for downstream tools. This provides a governed input, but consumers can still make mistakes when filtering or aggregating it. Record its grain and refresh time, and verify the dashboard's calculations against the contract.

How do corrections reach every consumer without creating competing copies?

Separate the place where a rule is edited from the places that read it. Prefer one authoritative page for an operating rule, linked to the metric it explains. If a consumer requires a copy, treat the copy as a managed distribution step with a named owner and a refresh policy.

Use this sequence for a correction:

1. Identify the source that owns the error: calculation, business explanation, access rule, or integration configuration.
2. Propose the change there, with its intended audience and effective date. Ask the business owner whether historical questions should retain the earlier rule.
3. Review the scope. A team-specific interpretation should not silently become a company-wide default.
4. Apply the approved update and refresh each consumer through its documented path.
5. Confirm adoption using the original question. Keep the incident open for any consumer that still uses the previous source.

This sequence is a recommended operating process. It does not assume automatic write-back, a universal approval gate, or centralized control over every external assistant.

In Orion by Gravity, external wiki integrations have distinct import modes. Sync Only retains the external source as authority, locks manual editing, and updates daily. Read & Write creates an editable Knowledge Base page with manual source syncing. Syncing overwrites the page content, so the documented mode should not be treated as automatic bidirectional write-back. Choose the source of authority before editing.

How do you prove that the same definition is being used?

Run one question through the intended paths with equivalent authorized scope and a fixed reporting period. Compare the source metric, context, filters, cutoff, and result. If a source cannot be held stable, record when it changed and recompute the approved reference for that condition.

Consider a hypothetical request: “What was September net revenue?” The BI dashboard calls the approved measure, Claude queries a gross-revenue column, and the Slack bot reads yesterday's approved export. There are two separate issues: Claude used the wrong calculation, and Slack used a different cutoff. Copying the finance glossary into both agents would not repair either path by itself.

Repair Claude's metric routing. Refresh or clearly date the Slack export. Then ask again and check the returned evidence. If both use the contract and the results still differ, inspect the filters, identity, and data before changing business meaning.

Include an ambiguous request such as “September revenue” to check that the intended interpretation is used or clarified. Also check a user with restricted access. Equal answers are only desirable when the users are allowed to see the same population.

For broader purchase criteria, use How to Evaluate an AI Analytics Agent. This consumer check establishes adoption of shared definitions; it is not a complete release regression suite.

Where does Orion by Gravity fit in this architecture?

Orion by Gravity provides documented ways to maintain business context and consume Orion work from another assistant. Its MCP server connects compatible clients, including Claude, to Orion projects, metrics, workflows, and Knowledge Base pages. That is a specific integration path to demonstrate in your environment, rather than control over every tool those clients can use.

The MCP tools reference includes project-scoped analysis through ask_orion, metric reads, and knowledge search and retrieval. Full analysis completes asynchronously; clients retrieve the result through conversation history. An integration needs to handle completion and present the available evidence.

Orion's page-management documentation describes editable pages, revision history, project-selected context, and optional defaults. Locked pages support change requests, with privileged direct-edit exceptions. Verify the roles and editing path in your deployment before treating locking as mandatory separation of duties.

Orion also documents dbt enrichment of a warehouse connection with model descriptions and lineage. Enrichment should not be read as proof that every Orion answer executes an approved MetricFlow metric. Require a demonstration of the calculation path that matters to your contract.

For Slack, plan the consumer integration explicitly. Current workflow delivery documentation describes email delivery and says workflows do not post to Slack. A custom Slack bot using a verified service path is a proposed application integration, not a native Orion workflow-delivery claim.

Choose Orion when maintained business context and an Orion analysis path address a real gap in the tools you already use. A governed metric service and its existing integrations may be enough when your only problem is duplicated calculations. A team needing unusual routing, distribution guarantees, or universal enforcement across independent agents should verify or implement those controls before committing to a product.

Frequently asked questions

Is a shared knowledge base enough to keep agents consistent?

It is a useful context source. Consistency also requires verified retrieval, approved calculations, matching reporting conditions, and a refresh path. An assistant can have access to a page and still answer through another tool.

Can business experts fix a definition without changing code?

They can correct business terminology and operating notes in an editable context system. Changing a governed calculation still follows the metric owner's engineering and review process. Distinguish those changes before granting editing rights.

Should every department use one revenue metric?

Use distinct, approved names for distinct measures such as bookings and net revenue. Map each question to its intended measure. Consistency preserves legitimate differences and prevents silent substitution.

Does connecting MCP force Claude to use approved metrics?

Connecting a server makes its tools available. Verify tool selection, identity, and alternative execution paths in the actual client. Configure application and access controls for the policy you intend to enforce.

How fresh must shared context be?

Set a freshness requirement according to the decision. Record the rule's effective date separately from the document's sync time and the data cutoff. A daily sync may suit a stable glossary and be too slow for a time-sensitive policy change.

Can two correct tools return different numbers?

Yes, when authorized populations, cutoffs, filters, or reporting periods differ. Make those differences visible. Reconcile the contract conditions before treating disagreement as an AI failure.

What should a data team do first?

Choose one question that already has an approved answer. Fill in the consumer contract for its dashboard, assistant, and bot. Trace each path and repair the first mismatch in authority, scope, or refresh behavior. Expand to another question once the owners can show how a correction reaches the consumers that depend on it.

See Orion by Gravity for the product and AI business intelligence tools for broader options. Use the contract above during a pilot so the review centers on observable behavior in your stack.