When AI Makes the Wrong Call: Governance Frameworks for Agentic Systems in Production.

An AI agent authorized to manage customer escalations routes a high-value account to a churn queue rather than to a specialist. A financial reconciliation agent cancels a batch of pending transactions because it misclassifies them as duplicates. A code review agent approves a pull request containing a critical injection flaw. In none of these cases does the system throw an error. The agent completed its assigned task. It just made the wrong call.

This failure mode is becoming structural rather than rare. Gartner predicts that by 2028, at least 15% of day-to-day work decisions will be made autonomously by agentic AI, up from less than 1% in 2024, and that 33% of enterprise software applications will embed agentic AI by then. Autonomy is arriving faster than governance. In the same research, Gartner forecasts that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls as the primary causes.

The challenge is not that AI agents fail. At a sufficient scale, all systems fail. The challenge is that agentic AI fails in ways that are non-obvious, often invisible, and frequently consequential before they become detectable.

The question for engineering leaders and CTOs in 2026 is not whether to deploy agentic AI. The competitive pressure is decided. The question is whether the governance infrastructure surrounding those systems can detect a wrong call before it becomes an incident, contain its blast radius when it does, and produce the accountability trail needed to prevent recurrence. This guide provides the practical framework, grounded in production realities and current regulations.

Key Takeaways:

• Agentic governance must govern actions, not just outputs: which systems an agent can touch, what it can modify, and when it proceeds without human review.
• Wrong calls fall into five distinct failure types, each requiring a different control. A single broad restriction does not address them.
• A production-grade framework has five layers: permission architecture, tool scope enforcement, human review gates, policy-as-code, and audit trails.
• Enforce constraints at the execution layer, not the instruction layer. A system prompt is an instruction; it is not a constraint.
• Governance and autonomy scale together. The Agent Autonomy Ladder defines five levels, each with a minimum governance requirement that must be met before promotion.
• Regulation is shifting: under the EU’s 2026 Digital Omnibus, high-risk obligations now apply from December 2027, but transparency rules still apply from August 2026.

What Is an Agentic AI Governance Framework?

An agentic AI governance framework is the combination of technical controls, organizational policies, and operational processes that define what autonomous AI agents are authorized to do, enforce those authorizations at runtime, monitor agent behavior for compliance and quality, and provide the accountability structures needed to investigate and remediate failures.

It differs from conventional AI governance in one decisive way. Conventional AI governance is built around the model output: classify the recommendation, evaluate the prediction, and review the generated text. Agentic governance is built around the action, because agentic systems do not just generate output. They execute.

Agentic Governance vs. Traditional AI Governance

The distinction matters because teams applying a traditional AI governance playbook to agentic systems will have controls in the wrong places.

Dimension	Traditional AI Governance	Agentic AI Governance
Primary concern	Output quality: accuracy, fairness, bias, hallucination	Action safety: which systems the agent can touch and what it can change
Control point	Model output layer (review the prediction before a human acts on it)	Execution layer (constrain what the agent can do before it does it)
Human role	Decision-maker who acts on the AI recommendation	Reviewer who approves, overrides, or audits autonomous actions
Failure mode	Bad recommendation presented to a human who can reject it	Irreversible action taken in a production system before anyone reviews it
Audit requirement	Log the prediction and the ground truth for evaluation	Log the full action chain: input, reasoning, tool calls, parameters, and downstream state changes
Regulatory anchor	Fairness, transparency, non-discrimination	Human oversight, traceability, conformity assessment (EU AI Act high-risk)
Rollback model	Retrain or fine-tune the model; redeploy	Identify every state change, reverse in correct order, halt the agent, then fix the governance layer that failed

Organizations moving from advisory AI (chatbots, recommendation engines, content generation) to agentic AI (autonomous workflows, multi-agent coordination, self-directed tool use) need to treat this as a governance migration, not just a capability upgrade. Context engineering disciplines increasingly frame this as a first-class design concern.

Why Agentic AI Is Categorically Different to Govern

Most AI systems deployed before 2024 were advisory. They generated recommendations that a human acted on, keeping a person in the decision loop. Agentic AI breaks that pattern, and three structural properties of agentic systems compound the governance challenge:

1. Actions chain. A single decision can trigger a sequence of downstream effects across tools, APIs, and other agents. By the time the final effect is observable, the causal chain is often hard to reconstruct.
2. Actions change external state. Unlike a model generating text, an agent that writes to a database or sends an API call changes the world outside the system. Those changes may not be reversible.
3. Agents operate continuously. The feedback loop a human would provide in an advisory model is absent by default. Failure accumulates silently until a threshold is crossed.

This is not a refinement of previous AI governance thinking. It is a different category of problem. The security community has already formalized the core risk: the OWASP Top 10 for LLM Applications (2025) lists LLM06: Excessive Agency as a distinct vulnerability, defined as the occurrence of damaging actions in response to unexpected, ambiguous, or manipulated model outputs when a system is granted too much autonomy or functionality. OWASP now maintains a dedicated Top 10 for Agentic Applications for exactly this reason. Understanding this category is the prerequisite for everything that follows. Agentic AI in software development has fundamentally changed what operational-layer governance requires.

A Taxonomy of Wrong Calls

Treating all agentic failures as a single category leads to governance that is either too broad to be enforceable or too narrow to catch what actually matters. In production, wrong calls fall into five distinct types, each with a different detection profile, blast radius, and remediation requirement.

Failure Type	What Happens	Primary Control
Misclassification with action	Agent misinterprets context and executes the wrong action from a correct permission set	Evaluation pipelines + human review thresholds
Permission boundary violation	Agent accesses or modifies systems outside its defined role (OWASP: Excessive Agency)	Least-privilege permission architecture
Cascading tool error	A correct initial action triggers unexpected downstream tool calls that compound the error	Tool scope enforcement + blast radius containment
Silent degradation	Agent operates within bounds but with declining decision quality over time	Observability + regression monitoring
Multi-agent coordination failure	Sub-agents produce conflicting outputs, resulting in incoherent composite actions	Inter-agent contract design + output validation

Each failure type maps to a specific governance control. A framework that addresses only one (most commonly, broad permission restrictions) leaves the other four failure modes live in production. The right answer is not less autonomous AI. It is governed by autonomous AI, with controls matched to specific failure modes.

The Agent Autonomy Ladder: When to Increase Autonomy

Governance is not a binary switch between “human does everything” and “agent does everything.” It is a graduated scale. The question engineering teams repeatedly face is not whether an agent should have autonomy, but how much, and what governance infrastructure must be in place before that level of autonomy is safe to grant. The following ladder defines five levels, each with a minimum governance requirement that should be met before an agent is promoted to that level.

Level	Autonomy Mode	What the Agent Does	Minimum Governance Requirement
Level 1	Recommend	Generates suggestions or analysis for a human to act on; takes no action itself	Logging and basic observability
Level 2	Execute low-risk actions	Performs bounded, reversible actions within a narrow tool scope (e.g., tagging records, sending notifications)	Tool scope controls + audit trails
Level 3	Execute business workflows	Runs multi-step business processes that modify external state (e.g., processing refunds, updating CRM records)	Human review gates for irreversible or high-value actions
Level 4	Multi-agent coordination	Delegates subtasks to other agents, aggregates results, and acts on composite outputs	Policy engine + inter-agent contract validation + orchestration-level governance
Level 5	Autonomous decision systems	Makes and executes consequential business decisions with minimal human involvement	Full five-layer governance stack, mandatory evaluation pipelines, incident response protocols, and regulatory compliance

Most production teams should start at Level 1 or 2 and promote agents incrementally as governance infrastructure and evaluation evidence justify it. The promotion criteria should be explicit: which evaluation scores, audit-trail coverage, and incident-response capabilities must be in place before an agent moves up? Without documented criteria, autonomy expands informally based on demo performance or stakeholder pressure rather than measured production reliability.

Governance and autonomy are not opposing forces. Governance is what makes granting greater autonomy safe. The strongest agent deployments treat each promotion on the autonomy ladder as a milestone requiring both evidence of capability and governance readiness.

The Five Layers of an Agentic Governance Framework

A governance framework for agentic systems is not a single mechanism. It is a stack of five complementary layers, each addressing a different dimension of the wrong-call problem. Agent guardrails covering permissions, tool scopes, audit trails, and policy-as-code form the operational core. The supporting layers make them a coherent system rather than a collection of point controls.

Layer 1: Permission Architecture

Permissions define the foundational authority granted to each agent. The governing principle is least-privilege: agents receive only the access required for their designated role, nothing more. Effective permission architecture requires three structural decisions:

1. Role-based permission grouping: which permissions belong together for a given agent function
2. Environment-level segmentation: narrower permissions in production than in development or testing
3. Temporal scoping: time-bounded access for scheduled agents rather than always-on permissions

The most common failure at this layer is not a security misconfiguration. It is a prototyping habit that persists into production: agents granted broad permissions during development, never narrowed before deployment. Permission scope review must be a mandatory pre-deployment gate, reviewed again before any significant change to the agent’s task scope. This is foundational to any serious AI security risk management program.

Layer 2: Tool Scope Enforcement

Tool scopes translate abstract permissions into concrete execution constraints. They specify which tools, APIs, or functions an agent may invoke and under what conditions, not just whether the agent has access but how that access can be exercised.

The critical design principle: enforce constraints at the execution layer, not the instruction layer. A system prompt that tells an agent what not to do is an instruction. It can be overridden by complex reasoning, adversarial inputs, or context that the agent misinterprets. An execution-layer constraint cannot.

The implementation pattern that supports this is a tool gateway: an intermediate layer between the agent and its tools that validates every tool call against a defined scope before execution. Rate limits, parameter validation, and pre-execution approval checks for high-risk operations sit here. This is a core requirement of the production AI governance stack, where guardrails are first-class system components, not prompt-level patches.

Layer 3: Human-in-the-Loop Decision Gates

Human review gates are structured intervention points where an agent’s planned action is paused for human approval before execution. They are not a sign of insufficient capability. They are a governance pattern for actions in which the consequences of a wrong call exceed the acceptable threshold for autonomous execution. Calibration depends on three dimensions:

1. Reversibility: irreversible actions require higher review thresholds
2. Business impact: high-value or high-risk actions require gates regardless of reversibility
3. Demonstrated reliability: gates can be removed incrementally as evaluation evidence accumulates

Regulation increasingly formalizes this logic. The EU AI Act requires that high-risk AI systems enable meaningful human oversight, including the ability to intervene in or override AI-driven decisions in domains such as employment, credit, and essential services. The Act’s requirements align with what AI-assisted development guidance has recommended on purely operational grounds. (See the regulatory section below for the revised 2026 timeline.)

Layer 4: Policy-as-Code Enforcement

Policy-as-code encodes governance rules in machine-readable formats that are automatically evaluated and enforced at runtime. The difference between policy-in-documentation and policy-as-code lies in enforceability: the first requires human compliance; the second does not. A policy document stating that agents should not access customer PII without justification is useful for auditing. A runtime rule that blocks any agent from querying PII tables without a valid business context token is useful for governance.

Policy-as-code frameworks for agentic systems typically cover four rule categories:

1. Action permissions: what actions are permitted under what conditions
2. Data handling rules: what data agents may access, retain, or transmit
3. Escalation conditions: when an action must route to human review before execution
4. Prohibited patterns: specific action combinations blocked regardless of individual permissions

For digital transformation programs that rapidly scale agent deployment, policy-as-code enables governance to scale with deployment rather than lag behind. Tools such as Open Policy Agent (OPA) and AWS Cedar make policies versionable, testable, and enforceable across all agents at once.

Layer 5: Audit Trails and Accountability Infrastructure

Audit trails provide a structured record of agent activity that enables incident reconstruction, regulatory compliance, and operational learning. Agentic systems must capture more than just API call logs. They must capture the full decision context:

1. The input that triggered the agent’s action
2. The reasoning chain produced, where available
3. The tools considered and invoked, including parameters
4. The outcome produced and the downstream state changes in external systems

Comprehensive audit trails are also the feedback mechanism through which governance frameworks improve. Aggregated audit data reveal permission-scope creep, tool-invocation anomalies, and decision-quality drift that are invisible at the level of individual actions. This connects directly to LLMOps practices that treat observability as a first-class operational concern rather than a retrospective investigation tool.

Building the Governance Stack: Tools and Reference Architecture

The following reference architecture covers the current production-viable approach for organizations building agentic governance from scratch or strengthening a partial implementation. Layers 1 to 3 are Priority 1: they address the most consequential failure modes and provide the minimum viable governance foundation for any production deployment.

Layer	Function	Production-Viable Tools (2026)	Priority
Permission Architecture	Role-based access, environment segmentation, temporal scoping	AWS IAM, Azure RBAC, OPA, Casbin	1 (Foundation)
Tool Scope Enforcement	Tool gateway, parameter validation, rate limiting, pre-execution approval	LangChain tool wrappers, custom middleware, API gateways	1 (Foundation)
Audit Trails	Full-chain action logging, cross-system correlation, retention	Langfuse, LangSmith, Arize, OpenTelemetry + SIEM	1 (Foundation)
Human Review Gates	Action queue, reviewer assignment, SLA tracking, approval workflow	Humanloop, custom workflow engines, Jira/ServiceNow integration	2 (Grow with scope)
Policy-as-Code	Runtime policy evaluation, versioning, compliance reporting	OPA (Rego), AWS Cedar, custom policy engines	2 (Grow with scale)
Evaluation Pipelines	Action correctness, boundary evaluation, regression detection	PromptFoo, LangSmith evals, Braintrust	2 (Grow with scale)
Observability	Full-chain tracing, anomaly detection, performance monitoring	Langfuse, Arize AI, Helicone, OpenTelemetry	2 (Grow with scale)

Teams that have already built LLMOps infrastructure for generative AI systems have a head start. Prompt versioning, evaluation pipelines, and observability infrastructure built for language generation provide the foundation for the action-layer governance that agentic systems add. The investment is incremental, not additive from zero. Gartner expects this category to grow into a market in its own right, forecasting that guardian agent technologies will capture 10 to 15% of the agentic AI market by 2030 as oversight becomes a built-in layer rather than an afterthought.

Three Architecture Patterns for Governance Enforcement

The five layers can be implemented through several architectural patterns, each suited to different deployment scales and regulatory environments. The pattern you choose determines whether governance stays manageable as the agent scope grows.

1. Centralized Policy Engine

A single governance service evaluates every planned agent action against the current policy ruleset before execution. Policy updates apply immediately to all agents, and compliance reporting is centralized. The trade-off is latency: every action incurs a round trip. This pattern fits regulated industries with strict compliance requirements and moderate action volumes.

2. Distributed Sidecar Enforcement

A governance module is deployed alongside each agent instance, receiving the policy ruleset from a central authority but evaluating actions locally. This cuts latency for high-throughput deployments at the cost of consistency: there is a window between a policy update and full synchronization. The sidecar pattern integrates naturally with service mesh infrastructure (Istio, Envoy) and suits teams investing in cloud-native application development.

3. Orchestration-Level Governance

In multi-agent systems with a supervisor orchestrator, governance is embedded at the orchestration layer. The orchestrator validates planned action sequences before delegating to sub-agents, monitors inter-agent outputs for coordination failures, and routes actions that exceed autonomous thresholds for human review. This consolidates enforcement at a single control point, but the orchestrator then becomes a single point of failure for governance. Robust designs subject the orchestrator to the same policy constraints and audit requirements as the agents it manages.

The Regulatory Picture in 2026: A Moving Target

The regulatory environment for agentic AI shifted materially in 2026. Getting the current state right matters because compliance timelines drive engineering priorities.

The EU AI Act remains the most consequential regime for enterprise agentic deployments. Its penalty structure under Article 99 is tiered: up to EUR 35 million or 7% of global annual turnover for prohibited AI practices, and up to EUR 15 million or 3% of global annual turnover for non-compliance with other obligations, including the requirements that apply to high-risk systems.

The timeline, however, changed. On 7 May 2026, EU institutions agreed the Digital Omnibus (AI Omnibus), which postponed the high-risk obligations under Annex III from 2 August 2026 to 2 December 2027. Transparency obligations still take effect on 2 August 2026. The practical implication: the hardest high-risk compliance work has more runway, but transparency, human oversight, and traceability expectations are arriving on the near-term schedule. The requirement is delayed, not removed.

In the United States, the NIST AI Risk Management Framework (AI RMF 1.0) provides voluntary guidance through four functions: Govern, Map, Measure, and Manage. These map onto the five-layer stack: Govern covers permission architecture and policy-as-code; Map covers the failure taxonomy; Measure covers evaluation and observability; and Manage covers incident response. Increasingly referenced in federal procurement, it is a practical organizing structure even where not strictly mandatory.

Five Governance Mistakes That Cause the Most Incidents

Across documented agentic AI failures, a consistent pattern emerges. These five mistakes account for the majority of preventable production incidents, and none of them are exotic.

1. Shipping prototype permission sets to production

Agents are granted broad permissions during development to reduce friction, and those permissions are never narrowed before deployment. When the agent eventually makes a wrong call, the blast radius is larger than it needed to be. The fix is structural: make permission scope review a mandatory pre-deployment gate, not an optional cleanup task.

2. Treating instructions as constraints

System prompts that tell agents what not to do are instructions, subject to override by complex reasoning, adversarial inputs, or misinterpreted context. Execution-layer constraints cannot be overridden by agent reasoning. Privacy by design in generative AI requires the same principle: controls belong in the architecture, not the instruction layer.

3. Designing governance for the happy path

Frameworks built for expected inputs fail under the conditions that actually produce incidents: edge cases, adversarial contexts, and the compound effects of multiple interacting agents. Robust governance requires adversarial testing of the framework itself, not just functional testing of the agent’s task performance.

4. Building governance after the first incident

Emergency governance is the most expensive version. Architectural decisions that need careful design become time-pressured patches applied while the system is already causing damage. The AI-native engineering practices that high-performing teams apply in 2026 treat governance as a first-phase deliverable, not an incident-triggered remediation.

5. Siloing governance ownership

When governance is distributed across functional teams without cross-functional accountability, gaps accumulate at organizational boundaries. The AI team owns model behavior, security owns permissions, platform owns infrastructure, and no one is accountable for agent behavior at the system level. The fix is a designated governance owner per deployed agent, a cross-functional review process for governance changes, and an escalation path that velocity pressure cannot bypass.

When It Goes Wrong: Incident Response for Agentic Systems

Agentic incidents differ from both traditional software incidents and standard model incidents. By the time a wrong call is detected, the agent may already have produced a sequence of actions across multiple systems. Containment is not a matter of rolling back a deployment. It requires identifying the full scope of actions taken since the failure began, determining which are reversible, executing reversals in the correct order, and preventing the agent from taking further action while the investigation runs. Three capabilities should exist before an incident, not be improvised during one:

1. An agent kill switch: the ability to halt all actions from a specific agent or agent class without taking down unrelated system components
2. State reconstruction: the ability to identify every external state change an agent produced within a given time window, which depends directly on Layer 5 audit trails
3. A failure-type triage protocol: a fast classification of which governance layer failed, so the fix targets the right control instead of adding blanket restrictions that reduce utility without addressing the cause

The triage protocol should map incidents to a defined severity matrix so that the response scales to the impact. The following matrix provides a starting template that teams should calibrate to their own business context.

Severity	Example	Required Response	Target Response Time
SEV-1: Critical	Unauthorized financial transaction, PII exposure to external system, regulatory-reportable action	Kill switch + executive escalation + state reconstruction + regulatory notification	Minutes
SEV-2: High	Customer workflow corruption, incorrect bulk data modification, cross-system cascading error	Immediate agent containment + manual state correction + root cause investigation	< 1 hour
SEV-3: Moderate	Incorrect recommendation acted on by downstream process, wrong routing of non-critical workflow	Agent flagged for review + retraining or evaluation update + monitoring increase	< 24 hours
SEV-4: Low	Minor quality drift detected in monitoring, non-consequential classification error	Log for trending + include in next evaluation cycle + adjust monitoring thresholds	Next review cycle

The teams that handle agentic incidents well have written and rehearsed these protocols in advance, using severity-specific runbooks rather than generic playbooks. This is the same discipline that application security testing applies by integrating security review into the development process rather than treating it as post-incident cleanup, and that penetration testing practices apply through scheduled adversarial exercises rather than reactive ones.

Governance Readiness: Seven Diagnostic Questions

These questions help engineering leaders assess the current governance state and identify the highest-priority gaps. Each maps to a specific layer and the failure mode it is designed to prevent.

Layer	Diagnostic Question	A Weak Answer Reveals
Permission Architecture	Can the team document the minimum permission set for each deployed agent and confirm current permissions do not exceed it?	Prototype permissions persist in production
Tool Scope Enforcement	Is there an execution-layer control preventing unauthorized tool invocations regardless of agent reasoning?	Scope is enforced by prompt instruction only
Human Review Gates	Are review thresholds defined by documented risk analysis, with mandatory gates for specific action types?	Thresholds set by convenience, not risk
Policy-as-Code	Are governance rules encoded in a runtime-evaluable, versioned format tested before deployment?	Governance exists in documents, not enforcement
Audit Trails	Can the team reconstruct the full action sequence for any agent in the past 30 days, including tool parameters and state changes?	Logs capture API calls but not action context
Evaluation Pipelines	Is there action-correctness data on a representative production input distribution, updated in the past 30 days?	Quality assessed by demo or spot-check only
Incident Response	Is there a written protocol including an agent kill switch and state-reconstruction capability?	No formal incident design for agent failures

Organizations scoring weakly on three or more of these questions are operating agentic AI under governance conditions likely to produce an uncontained incident, even if the product appears to be moving quickly.

Frequently Asked Questions

1. What is an agentic AI governance framework?

It is the combination of technical controls, organizational policies, and operational processes that define what autonomous AI agents are authorized to do, enforce those authorizations at runtime, monitor behavior for compliance and quality, and provide accountability structures for investigating and remediating failures. Unlike advisory AI governance, it governs the consequences of execution for autonomous actions in production systems.

2. How is agentic governance different from standard AI governance?

Standard AI governance addresses output quality, fairness, and transparency. Agentic governance adds execution consequences: which systems an agent can modify, how irreversible actions are controlled, and how full action sequences can be reconstructed. See the comparison table earlier in this post for a detailed breakdown by dimension.

3. What does least-privilege mean for AI agents?

It means granting each agent only the permissions, tool access, and data access required for its designated function. In practice: document the minimum permission set per agent role, review against that minimum before production deployment, segment by environment, and enforce at runtime so agents cannot exceed scope regardless of reasoning output.

4. What are the EU AI Act’s requirements and current deadlines for agentic systems?

The EU AI Act requires high-risk AI systems to provide human oversight, logging and traceability sufficient to reconstruct decisions, conformity assessment, and documented risk management. Penalties under Article 99 reach EUR 35 million or 7% of global turnover for prohibited practices, and EUR 15 million or 3% for other violations. Following the May 2026 Digital Omnibus agreement, high-risk Annex III obligations now apply as of 2 December 2027, while transparency obligations continue to apply as of 2 August 2026.

5. What is OWASP Excessive Agency?

Excessive Agency (LLM06 in the OWASP Top 10 for LLM Applications, 2025) is a vulnerability that arises when an LLM-based system is granted too much autonomy or functionality, enabling harmful actions in response to unexpected or manipulated inputs. It is mitigated through least-privilege permissions, tool scope limits, and human review gates.

6. How do you test whether a governance framework actually works?

Through adversarial testing alongside functional testing: confirm that tool scope enforcement holds under parameter manipulation, that human review gates cannot be bypassed through specific reasoning structures, that audit trails are complete under high-concurrency conditions, and that the agent kill switch halts all actions in the expected window. This should run on a defined schedule, not only after an incident.

Conclusion

Agentic AI systems are already making consequential calls in production across customer operations, finance, and software delivery, and at sufficient scale they will make wrong ones. As agentic AI moves into core business functions, the variable engineering leaders can influence is whether the surrounding governance infrastructure detects the wrong call before it becomes an incident, contains its blast radius when it does, and produces the accountability trail to prevent recurrence.

The five-layer governance stack, from permission architecture through audit trails, provides the architecture. The Agent Autonomy Ladder defines when to increase agent authority. The Incident Severity Matrix defines how to respond when a wrong call lands. None of these elements is sufficient alone. Together, they constitute a governance system that scales with deployment rather than lagging behind it.

The organizations positioned to sustain agentic AI investment are not those with the most agents deployed. They are those with the governance infrastructure to make those agents trustworthy, not just capable.

At Coderio, our engineering teams help mid-market organizations design and implement production-grade agentic governance: minimum-privilege permission architecture, execution-layer tool scope enforcement, evaluation pipelines for action-consequence assessment, and observability that makes governance auditable and continuously improvable. If your team is deploying agentic AI and wants to build governance before the first incident, schedule a discovery call, and we will assess which governance layers are most at risk.