The moment you let an agent do work instead of answering questions, your data stack stops being a reporting system and becomes an execution system.

Why it matters

Agents read, decide, and act. That makes permissions, lineage, and policy non-negotiable. You are not trying to prevent "bad answers." You are trying to prevent bad actions.

If your architecture depends on one closed platform for data access, your agent architecture inherits that dependency. It also inherits the blind spots that come with it.

The ODI angle

ODI makes agentic AI viable because it separates data ownership from tool ownership. An agent can use different tools and models, but it still needs a stable interface to governed data.

That interface is open catalogs, open formats, and a context layer that preserves meaning, permissions, and auditability.

When you build that layer as vendor-neutral infrastructure, you keep the freedom to change everything else.

Core idea: agent safety is a data contract problem before it is a model problem.

The architecture test

For AI leaders, the test is whether you can audit and constrain what the agent does.

  • Implement policy at query time, not only in apps.
  • Capture tool calls and data access as auditable events.
  • Design a context layer that includes lineage and freshness.
  • Treat data products as APIs with contracts.
  • Build guardrails operators can understand and override.

What breaks first

This breaks when teams deploy agents on top of stacks that cannot enforce boundaries.

  • The agent works only because it has broad access in a sandbox.
  • Actions cannot be reproduced because the data path is not logged.
  • The system leaks data because policy is enforced inconsistently across tools.
  • Teams focus on prompting while ignoring the infrastructure that makes prompts safe.

Questions to ask

Use these questions when you evaluate agentic AI open data infrastructure for real production systems.

  • Can you trace an action back to the exact data and context that caused it?
  • Which systems enforce policy when the agent uses tools?
  • How do you prevent context from including data the user is not allowed to see?
  • How do you handle incidents and rollbacks when an agent makes a bad move?
  • What stays portable if you swap vendors?

If your answers are "it depends on the vendor," you are building an agent that is locked into a platform's governance model.

Sources to start with

Start with governance and risk frameworks, then map them to enforceable infrastructure behavior.