Why AI agents need decision-making power
▼ Summary
– 90.3% of companies report using AI agents, but only 23.3% have them in production, revealing a gap between experimentation and governance.
– Customer data platforms (CDPs) govern data access, but not decision authority—AI agents may have permission to see data but not to act on it in specific ways.
– Tool-level guardrails fail because they address single symptoms, and governed decisions lose authority when crossing system boundaries.
– The NIST AI Risk Management Framework prioritizes Govern and Map before Manage, requiring clear ownership, authorization, and boundaries for AI systems.
– Decision architecture treats governance as a shared service, allowing all agents to query the same rules for unified, portable authority across systems.
A single statistic demands the full attention of every martech leader right now. According to Frans Riemersma’s April analysis, 90.3% of companies report using AI agents, yet only 23.3% have them in production. Even more stark, just 6.3% have fully integrated AI into their marketing stack. This reveals an 84-point chasm between experimentation and governance, and the platform most teams rely on to bridge this divide was never designed for the task.
So, why is your AI agent making promises your organization cannot keep? Your customer data platform (CDP) functions correctly, building one unified customer profile from every touchpoint. It fulfills a decade of martech investment. Yet your AI agent might still offer a custom service tier requiring legal approval, something never authorized for external communication. The CDP saw all the data, and the agent had permission to access it. What it lacked was permission to act in that specific way. Data access and decision authority are fundamentally different, and the martech stack has solved only one.
Tool-level guardrails often fail for two reasons. First, the typical response is to patch individual systems: add guardrails to the marketing automation platform, insert a review step in the CRM, or configure the chat agent to escalate certain topics. Each patch addresses a single symptom in a single system. Three months later, a different agent in a different system makes a different unauthorized commitment. The patchwork grows, but coherence does not. Second, even when a single system correctly governs a decision, the output loses its authority when it crosses a system boundary. The receiving system must re-check, re-interpret, or re-authorize the decision before acting. A governed output from your marketing platform does not arrive in your CRM as something the CRM can directly trust. The hidden cost is not just producing the governed decision; it is rebuilding confidence before the next system can act.
What gap was the CDP never built to close? A CDP governs data access, answering one question: who can see this record? Decision governance answers a different question: given this record, what is the AI authorized to do with it? This distinction grows more critical over time. The newest federal direction on trustworthy AI moves beyond access and visibility into operational questions: explainability, deterministic behavior where required, fail-safe operation, and measurable governance across the lifecycle. The emerging standard is not just clean data; it is governable action.
Most of the AI governance market focuses on the Manage layer: monitoring drift, flagging anomalies, and generating reports after deployment. But the NIST AI Risk Management Framework starts with Govern and Map. Before you can manage AI risk, you must define who owns the system, what it is authorized to do, and where the boundaries are. Most organizations have invested heavily in managing the first problem and almost nothing in designing the second. The practical pattern is straightforward. Permissions define what the agent can autonomously commit to. Obligations define what it must do in all cases when specific signals appear. Prohibitions define the hard stops no agent can cross, regardless of optimization pressure. The difference between vague and sovereign is the difference between “help customers with refunds” and “approve refunds up to $250 for customers with tenure over 90 days and no prior fraud flags.” The first relies on AI judgment. The second is binary. It fires or it does not. It can be audited. It can be enforced. Data access permissioning is not action permissioning.
Why is decision architecture the next infrastructure priority? The shift from apps to infrastructure points to decisioning as a potential standalone service: a consumer of context rather than a provider of it. When decision governance is a shared service rather than embedded in each tool separately, every agent in the stack queries the same rules. One update propagates across every system. Legal approves the boundary once, and every agent inherits the approval. This also solves the cross-system trust problem. When every agent queries a shared authority layer, the decision retains its legitimacy at the boundary. The next system does not need to re-adjudicate. The authority is centralized, and the record is portable.
CDPs won the data unification war. That problem is largely solved. The next architecture problem is decision unification through a sovereign operating layer, which I call the Brand Experience AI Operating System (BXAIOS). Until every agent queries the same rules about what it is permitted to do, you have unified data feeding ungoverned decisions. The second half of the problem has a name: Decision Architecture. It is the blueprint that tells the enforcement layer what to apply and how to translate leadership’s risk appetite into machine-speed behavior. Without it, every new AI deployment risks becoming another silent cost center instead of a source of durable leverage. And those silent costs have been accumulating longer than most teams realize.
(Source: MarTech)
