Who Owns the AI Context Layer? A Control Tower for Data Teams

The data team should own the operating controls for an AI context layer, while business experts own the meaning of the information inside it. A useful context layer connects approved metrics, business knowledge, access rules, and answer evidence. It gives the technical team a control tower: a place to inspect what an agent used, review changes, and decide what business users can do next.

The practical test is simple: when a business user gets the wrong answer, can your team find the cause, correct it at its source, and check whether the correction worked?

Orion by Gravity provides documented building blocks for this approach, including editable knowledge pages, change requests on locked pages, reusable analysis notebooks, and MCP access from other assistants. The control-tower workflow below is a recommended operating model; its complete implementation depends on the tools and integrations you choose.

Product and source documentation reviewed October 1, 2026. Examples below are hypothetical.

What is an AI context layer, and why does it need a control tower?

An AI context layer is the maintained information and rules an agent uses to interpret a question and work with your business data. It can include metric references, business terminology, operating events, procedures, approved analyses, and rules about which context applies to which audience.

The term is still developing. Define its responsibilities before buying a product or creating another service in your stack.

A knowledge repository gives the agent something to read. A control tower gives people a way to manage the consequences: who can change that information, which agents consume it, what answers it affects, and how a mistake gets resolved. A glass-box experience exposes inspectable evidence such as queries, source documents, and selected definitions. It does not require access to a model's private reasoning.

For example, imagine that a sales user asks why revenue fell. The agent returns a valid query and a persuasive explanation. The query might use the wrong revenue definition, or the explanation might rely on an outdated note about a product launch. Those failures need different owners and different fixes.

This is why context ownership should be an operating responsibility. An upload screen alone cannot tell you whether the business answer changed for the right reason.

Does a context layer replace the dbt semantic layer?

Keep governed metric calculations in their authoritative system. The dbt Semantic Layer centralizes metric definitions on existing models and uses MetricFlow to handle joins. A context layer can add the business explanations, scope, and operating knowledge needed around those definitions.

That boundary is practical, rather than a fixed divide between structured and unstructured data. In its September 16, 2026 context-engineering article, dbt describes bringing versioning, provenance, and tests to the text agents read. Some context work may therefore belong in your dbt project too.

Choose one source of truth for each rule. If Finance changes net revenue, review the calculation through your metric-governance process. If Sales adds an explanation of a one-time promotion, review the business note with its owner. Link the note to the metric; avoid maintaining a competing revenue formula in prose.

For a fuller explanation of this boundary, see Semantic Layer vs. Business Context.

What should a data team's context-layer cockpit let it control?

Use these six controls as an acceptance checklist. They are design requirements to verify in a pilot, rather than a claim that every context product includes them.

Start with one important business question and exercise all six controls. A system that can show SQL but cannot explain which definition applied leaves the team with an incomplete investigation. A system that stores approved context but has no adoption path into the consuming agent leaves the correction unused.

The cockpit should connect an incident to a decision: keep the answer available, request clarification, route it for review, or temporarily limit the affected experience. Decide which actions you can support before promising them to business users.

Who should own definitions, approvals, and the business-user experience?

Assign ownership by the kind of decision involved.

• Business experts own meaning. Finance owns revenue policy; Customer Success owns the interpretation of a customer-health playbook. Each entry should identify a responsible owner and when it applies.
• Data teams own the path to an answer. They maintain metric references, context selection, test questions, and the evidence needed to investigate a result.
• Administrators own permissions. They decide who can read, propose, approve, and change configuration. Editing business meaning and granting data access should be separate decisions.
• The product or experience owner owns the user journey. They decide when users can explore freely, when a request needs clarification, and when a reviewed answer is appropriate.

These responsibilities can belong to a small team. They still need explicit boundaries. Giving someone permission to correct a business note should not silently grant permission to redefine a governed metric or expand warehouse access.

Can business experts update agent knowledge without changing code?

Yes, for knowledge maintained as editable business content. That does not make every change a no-code change: altering a metric calculation, warehouse policy, or integration can still require engineering work.

In Orion by Gravity, the knowledge-page documentation describes a Markdown editor, revision history, and locking a page to enable change requests. For a locked page, a non-admin who is not its creator submits an edit for review; the page content stays unchanged until approval. Page creators and admins review the proposed changes. Their own edits can bypass that review flow, so locking is not universal separation of duties.

The same documentation describes project-selected pages and optional tenant or group defaults. Review scope carefully before changing a default, because it can affect multiple conversations.

These controls let business experts contribute corrections without asking an engineer to rewrite the agent for every note. The operating process still needs a named owner and a check of the resulting answer.

What should happen when a business user reports a wrong answer?

Use a correction loop that begins with the observed answer and ends with a checked result.

1. Capture the incident. Save the user's question, answer, project, audience, time, and available query or source evidence. Record what the user expected and why.
2. Classify the cause. Separate a data problem, metric-definition problem, stale business note, missing scope, and unsupported explanation. A knowledge edit will not repair a broken warehouse model.
3. Fix the authoritative source. Send a calculation change through the governed metric process. Send a business-context correction to its content owner. Keep the original incident linked to the proposed change.
4. Review the difference and its scope. Ask what should change, what should stay the same, and which audiences should receive the update. Check access separately from meaning.
5. Run focused answer checks. Repeat the reported question, a paraphrase, a neighboring question, and a question from an unaffected audience. Inspect source selection and logic as well as the final wording.
6. Release and verify. Apply the approved change through your normal process, check each consuming tool, and keep a recovery plan. Until verification passes, describe the incident as pending.

Orion's analysis documentation describes notebooks that retain the instructions, logic, and code of an analysis and can be rerun. That provides a concrete artifact to inspect during this loop. It does not establish that every answer automatically has a complete versioned snapshot of all context it used.

How can we catch wrong answers after a dbt model or business rule changes?

Maintain two kinds of checks: checks of the underlying data and checks of the business answer. dbt data tests assert conditions on data resources. Your agent evaluation should additionally check the intended metric, scope, source evidence, and behavior when information is missing.

A changed result can be correct. When the approved definition changes, update the expected answer deliberately and record the reason. Comparing against an old number without inspecting its definition can flag a valid change as a failure.

The following change-review card is a reusable starting point. It illustrates a business-context correction around an existing governed revenue metric. It is not an Orion configuration format or a report of a customer deployment.

For repeatable checks, hold the evaluation data and relevant versions stable where possible. Otherwise, record changing inputs so a new data refresh is not mistaken for a context regression. Connect these checks to deployment events if your tooling supports it; start with a manual review if it does not. This is a recommended workflow, not a claim of a native Orion CI gate or automatic rollback.

Use How to Evaluate an AI Analytics Agent Before You Buy for broader purchase criteria. This review card focuses on operating the agent after a change.

How do we keep Claude, Slack, and BI tools using the same context?

Consistency requires a verified consumption path. A shared page cannot govern an assistant that never reads it, and a connected assistant may still have access to other tools that bypass your intended path.

Inventory the entry points. For each one, document how it retrieves the authoritative metric, which business pages it can read, whose permissions apply, and how an update becomes effective. Test the same question in each surface. If a tool cannot consume the shared context, make that limitation visible and assign an owner to its separate configuration.

Orion's MCP server gives compatible assistants, including Claude, access to Orion projects, metrics, workflows, and knowledge pages. This is one documented path for using Orion from another assistant. It does not, by itself, make every Claude session, Slack bot, or BI tool use the same definitions, or give Orion control over their independent execution.

Treat cross-agent oversight as an integration requirement to demonstrate in your environment. Ask to see an actual request, its effective identity, the selected context, the answer artifact, and the effect of a correction.

Should we build a context-layer control tower or buy one?

Build when your team needs custom execution paths and can maintain context selection, access enforcement, change review, integrations, and evaluations over time. Buying can provide existing editing and analysis surfaces, but you still need to verify that the product supports your owners, metric systems, and consuming agents.

Consider the adjacent options fairly. A semantic layer addresses governed calculations. A knowledge platform addresses shared information: for example, Relevance AI documents editable knowledge that can be reused across agents. An agent observability tool can help investigate execution, but ask separately how a business correction becomes approved context. These functions may overlap in a product, and you may already own some of them.

Use a pilot to follow one correction from report to verified answer. Include a scope boundary and a change that should leave another audience unaffected. Measure the work your team must do to complete the loop; evaluate capabilities through demonstrated behavior.

Frequently asked questions

Is a control tower the same as an AI agent observability dashboard?

It can include observability, but the operating model also needs ownership, change review, context scope, and a correction path. An answer trace helps explain an incident. The control tower connects that evidence to a reviewed action.

Does a context layer prevent hallucinations?

No layer guarantees correct answers. Approved sources and governed definitions make some errors easier to prevent and investigate. You still need checks of source selection, calculations, access, and unsupported explanations, plus a clear response when evidence is insufficient.

Do locked Orion knowledge pages require approval for every edit?

No. The documented change-request flow applies to other non-admin editors. Page creators and admins can edit directly, including on locked pages. Account for those exceptions in your operating process.

Does Orion's dbt connection guarantee that every answer runs through MetricFlow?

Do not assume that. The connection guide documents dbt context such as model descriptions and lineage. Confirm the metric execution path separately in your deployment; importing dbt metadata is different from enforcing Semantic Layer API usage.

Where should we start if we have several data agents already?

Choose one important question used in two surfaces. Map its metric source, business context, owners, permissions, and correction process. Demonstrate a reviewed change in both surfaces before extending the pattern to additional agents.

What should we ask Orion by Gravity to demonstrate?

Ask for a walkthrough using your own question: inspect the analysis, propose a business-context correction, review its scope, apply it, and check the next answer. Use the six-control checklist to establish what is available today and which parts require integration or additional work. Talk to Gravity about the workflow you need to operate.