The evaluation questions
The questions that separate architecture from marketing.
Every governance platform claims the same things: unified oversight, policy enforcement, audit trails, sovereignty. The differences show up when you ask specific architectural questions. These are the ones that matter most. Ask them of every vendor you evaluate, including us. Our answers are below each question.
What happens to in-flight work when your kill switch fires?
Why it matters. In regulated workflows, terminating an agent mid-transaction creates worse outcomes than letting the undesired behavior finish. An agent killed mid-write leaves a record in an ambiguous state, an operational hazard and an audit-integrity violation at the same time. A financial agent killed mid-transaction leaves compensating actions orphaned and regulatory reporting broken. Regulated operations require predictable transactional boundaries, not abrupt termination. A literal kill switch in an "AI governance platform" is an anti-feature in any environment where transactional integrity matters.
Scoped emergency pause. Halt dispatch of new agent actions at configurable scope: tenant, business unit, platform-wide, specific agent, specific fleet, specific skill. Let in-flight actions complete to their next transactional boundary with full EDT logging. Place all subsequent workflow steps behind explicit human approval. Dual-control authorization required to resume above a severity threshold. Stop the problem, not the platform.
Can you show me deployment independence, vendor independence, and format independence, separately?
Why it matters. "Own your control plane" means three architectural properties most buyers collapse into one. All three matter. A platform that delivers only deployment independence is deployable-but-locked-in. Only vendor independence is neutral-but-hosted-elsewhere. Only format independence is portable-but-still-in-the-vendor's-cloud. Vendors that can't separate the three in a conversation are usually hiding behind the strongest one.
Deployment: architected to run as a Snowflake Native App, a Databricks App, in your VPC, or fully air-gapped. Row data never leaves your perimeter; only governance metadata does, and only in the SaaS posture. Vendor: no competitive exposure to any model provider or platform we govern, we compete with none of the platforms in our target estate. Format: EDT is open-schema, OpenTelemetry-compatible, queryable SQL, regulator-friendly evidence packs. You own your history even if you leave us.
Does your governance run at the data layer or around the agent's execution, and can it govern agents running outside the platform it lives in?
Why it matters. Two different things get called "AI governance." Data-layer governance, catalogs, lineage, classification, masking, guardrails on what reaches a model, is necessary, but it does not govern the agent's behavior: the decisions, the tool calls, the multi-step execution. And governance that lives inside one platform tends to govern best inside that platform. The enterprise question is whether the same envelope reaches an agent running in another cloud, another warehouse, a SaaS app, or on-premises, or whether each estate needs its own.
Operon governs the execution layer: author-able quality gates (QDL), gate-scoped pause and auto-pause, benchmarking, simulation, and promotion gates around the reasoning itself. It runs in your trust boundary rather than a platform's, so the same envelope applies whether the agent runs in your VPC, a warehouse, a SaaS system, or air-gapped. It composes with data-layer governance rather than replacing it: a warehouse's catalog and guardrails secure what the agent reads; Operon governs what the agent does.
If a model provider's API key were compromised, would your telemetry of their traffic also be compromised?
Why it matters. Blast-radius analysis. A governance layer that shares infrastructure with the thing it's governing shares the vulnerabilities. Microsoft governing Copilot, Salesforce governing Agentforce, OpenAI governing its own models, all sit inside the same trust boundary as the risk they're supposed to monitor. Independent governance means the governance layer runs somewhere the model and platform layers cannot reach. Different infrastructure, different blast radius, different compromise surface.
The governance plane runs in your perimeter: your Snowflake account, your Databricks workspace, your VPC, or your air-gapped facility. The model provider cannot reach it. Their compromise does not compromise our telemetry of them. This is what sovereignty actually requires architecturally.
What code do I change to switch reasoning providers for production agents?
Why it matters. Model-provider market share shifts month to month. The reasoning model that wins Q2 isn't necessarily the one that wins Q4. Swapping the model itself is a dropdown on most of these platforms; that is not where the lock-in lives. The lock-in is that the agent definition, the memory, and the audit trail sit in the provider's cloud, so when you want to leave, you are migrating schemas and reconstructing history, not changing a setting. That is the "platform creep" trap: managed agents where the provider owns the orchestration, the memory, and the audit, and portability is theoretical.
One registry entry per agent. Agent definitions, conversational memory, tool invocation history, and audit trails live in your environment, not the provider's. Switching from Claude to GPT to Gemini to a custom model is a configuration change. The agent definition stays. The memory stays. The audit trail stays. The governance envelope stays. Only the reasoning call destination changes.
To govern one more agent running outside your primary platform, what does it cost, net-new vendor consumption, or nothing?
Why it matters. Bundled governance is "free" only inside the platform you already pay for. The moment your governance scope crosses into another estate, platform-metered models charge you to extend coverage, or simply cannot reach it. A control plane priced to the platform grows its bill with every agent and every seat; a control plane that runs on infrastructure you already own does not.
Operon's governance kernel runs on infrastructure you already operate, and it is licensed by agents in production rather than by seat or by platform consumption. Governing an additional agent, in any estate, adds no net-new vendor consumption and no per-seat platform tax; you expand coverage without expanding anyone's bill but your own compute. The ROI calculator quantifies it against your current platform mix.
Full treatment of each question, the architectural reasoning, the regulatory context, and the worked examples, is in our essay Beyond the Governance Mirage. We publish the questions because we want to be chosen on architecture, not by default.
