George Kanellopoulos

The Effective Agent

Executive Summary

Agentic AI is at once the most hyped and the least operationalized technology of 2026. 79% of organizations report adopting AI agents yet only 11% have solutions in production, and Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027. This paper argues that the gap has little to do with model capability. The model has become a commodity. What determines success is everything that surrounds it: the harness, the governance architecture, the economics and the organization itself.

To make that case, the paper establishes a shared vocabulary, dissects the five layers of a production harness, maps the architecture patterns that survive contact with production, explains why agents fail differently than traditional software, and treats governance, cost and organizational readiness as the engineering concerns they are. It closes with ten recommendations for technical leadership. The short version: invest in the harness, treat governance as architecture and redesign the organization, not just the technology.

1. The Moment is Now

We are at a critical juncture in the AI landscape. LLMs and the transformer architecture brought forth possibilities for utilizing AI that were impossible to imagine a few years back. In 2025 and 2026 the Agentic AI promise has, according to Gartner, reached the Peak of Inflated Expectations [1], after agentic AI was named the number one strategic technology trend for 2025 [2]. While that may be, it seems that companies are finding it difficult to adopt, thus creating an environment of extraordinary attention and lagging execution.

Looking at the data, the picture becomes even clearer. When it comes to adoption, 79% of organizations report adopting AI agents [3] and 40% of enterprise apps are expected to embed task-specific agents by the end of 2026 [4]. At the same time, on the execution side, only 11% of Agentic AI solutions are already in production [5] while a significant number of C-suite executives state that AI adoption is “tearing their company apart” [6]. To make things even more counterintuitive, the data shows that 40% of agentic AI projects are slated to be cancelled by the end of 2027 [7]. Growth and failure happening simultaneously.

The moment is now to take a step back, unmount from the hype and discuss why it is so challenging to adopt Agentic AI technologies and how we can close the gap between model capability and the harnesses that surround it. This paper will attempt to do exactly that while trying to educate technical leadership.

2. The Language of Agents

The hype, as it always does, has created an environment in which the technology moves fast while the semantics around it remain vaguely defined, and at the end there is no shared vocabulary to communicate and exchange ideas. That is why we begin with the key terms and definitions.

Agentic vs Agent

If you have heard the terms Agentic AI and AI Agent being used interchangeably you are not alone. However, the two mean quite different things and the distinction matters. Starting with the smaller unit we need to define that an AI Agent is the discrete software entity. A single piece of software that is LLM-driven, task-oriented and tool-integrated. Agentic AI on the other hand, is the behavior expressed when multiple AI Agents collaborate in order to perform dynamic task decomposition, achieve persisting knowledge across sessions and finally gain autonomy. It is the paradigm, not the entity [8].

Agent vs Workflow

Workflow is a term that was well-known and well-defined before the AI era, and it means nothing different in this context. Code paths utilize LLMs and tools to execute a specific sequence of events in a deterministic and predictable way. An Agent has the freedom to direct its own process and tool usage. It can assess what just happened and decide what to do next. It operates independently in a loop while analyzing feedback from the environment [9].

Agent Harness

A term that lately has gained significant traction is the word Harness. It is used to describe everything that surrounds the model. The tools, verification loops, memory, guardrails and observability. Viv Trivedy has expressed this in a formula that makes it easy to understand [10]:

Agent = Model + Harness

The harness is the mechanism that makes the model think in a safe, consistent, and useful way.

Agentic AI Engineering

There are three types of engineering you need to be aware of: Prompt, Context and Harness. Prompt engineering refers to crafting effective instructions for a single model interaction. Context engineering relates to the process of designing the entire information environment the model relies on to reason. That might include memory, documents, tool definitions, conversation history and structured output specs. Harness engineering involves designing and maintaining the control system that governs an agent across its entire lifecycle. It is more about how the agent acts. It is important to note that all three types of engineering co-exist within each other. Prompt engineering lives inside context engineering and context engineering lives inside the harness [11] [12].

Multi-Agent System

A Multi-Agent System is one that comprises multiple autonomous AI agents that each have specialized roles while coordinating in order to accomplish tasks beyond any single agent’s capability. The term Multi-Agent refers to the architecture and not an upgrade technique. More agents do not mean better. Three architectural patterns have emerged (hub-and-spoke, hierarchical and flat mesh) and we will examine them in detail in section 4.

Orchestration

Orchestration is the process of coordinating multiple agents, tools and workflows into a cohesive system. It’s a control plane. If the agents are viewed as workers, orchestration is the management layer. In practice, orchestration tries to answer four questions at runtime: How do we break the goal into tasks (Decomposition). Which agent or tool will handle each task (Routing). Which tasks can run in parallel and which have to be linear (Sequencing). How the results are to be synthesized into a coherent output (Synthesis). The orchestration patterns that dominate the landscape (supervisor, swarm, fan-out/fan-in) map onto the coordination topologies we examine in section 4. In general, the orchestration layer is where the production value concentrates and where it is decided whether the solution will be reliable, cost-efficient and governable. It is also the layer where context sizing, budgets and latency targets are decided.

Guardrails

In the context of Agentic AI guardrails are the technical and organizational controls that constrain what an AI agent can decide, access and execute. They are not simply safety nets. They are boundaries that define the space within which an agent is allowed to operate. If the harness is the wrapper, guardrails are the fences inside the wrapper. The difference from traditional software security lies in the fact that for the first time we have deployed software that has the ability to go do something without us explicitly telling it what to do. Traditional access controls assume software does what it’s programmed to do. Agent guardrails assume it might not.

There are five defined guardrail layers:

In general, guardrails are not a bolt-on compliance checkbox. They are an architectural layer designed in and not added after.

Oversight Key Terms

The final three key terms we need to discuss form a spectrum and as such we need to discuss them in relation to each other. Human-in-the-Loop (HITL) refers to the mechanism in which the agent pauses at defined checkpoints and waits for a human to approve before executing. This technique is used for high-risk and irreversible decisions. Human-on-the-Loop (HOTL) describes the approach where the agent acts autonomously while a human monitors and can intervene after the fact. It is used mainly for medium-risk use cases where speed matters and reversible decisions take place. Lastly, in Governed Autonomy the system itself is designed and engineered with trust mechanisms and not per-action approvals. Humans design the policies upfront and agents operate autonomously within those boundaries [13].

3. Anatomy of an Agent

In the previous section we discussed the vocabulary of agents. In this section we will take a deep dive into what makes an agent work efficiently in a production environment.

To do that we will examine closely the core equation and turn our attention onto the Harness term

Agent = Model + Harness

The five layers of a production harness

A harness in production should ideally contain five layers, all important and all interdependent:

Architecture diagram: a model core inside an agent boundary, wrapped by a harness containing five layers (tool orchestration, verification loops, context and memory, guardrails, observability), exchanging with an external environment of tools, APIs, data sources and people

Figure 1: The five layers of a production harness. The model never touches the environment directly; every capability and every safeguard lives in the harness.

Tool Orchestration

Tool orchestration is where the agent meets the real world. It is the control plane that connects agents to external tools, APIs and data sources while managing how those connections work at runtime. When an agent decides to read a database, call an API or run code, the orchestration layer handles selection, execution, error recovery, and result routing.

In a production environment the basic loop is that the model receives JSON schema tool definitions and emits structured invocations. The harness executes them and the results flow back into the context window. It is important to understand that the model never touches the tool directly. The protocol that standardizes this loop, and the de facto one in 2026, is MCP (Model Context Protocol), with millions of downloads and adoption by every major AI provider [14]. Parallel tool invocation within the same loop is also considered to be a performance optimization [15]. Instead of one tool call at a time, the harness fans out multiple calls concurrently.

There are both interesting and worrying implications on current tool orchestration architectures and standards. Tool search allows avoiding loading all tool definitions upfront thus leading to significant token reduction. This is purely an orchestration optimization, not a model improvement. Furthermore, dynamic tool registration which is an MCP capability, enables tools to change at runtime without agents restarting. New definitions propagate instantly to running sessions with obvious benefits.

On the other hand, the current architectural and protocol landscape creates vulnerabilities. In one Endor Labs analysis of more than 2,600 MCP implementations, 82% used file system operations prone to path traversal [16], while prompt injection remains the dominant attack vector in production AI deployments [17]. SOTA models struggle with tool selection across long conversations and dynamic decision-making. Security cannot rely on model-level instructions. Least privilege per tool principle is required along with input validation at the execution layer, sandbox isolation and filesystem path scoping.

Every tool is a permission boundary, a cost center, and an attack surface. The orchestration layer must handle all three simultaneously.

Verification Loops

Verification loops include all the automated quality checks that validate agent outputs during execution. They are there to ensure that probabilistic systems like agents are doing deterministic work. In practice the harness is responsible for intercepting every tool call and checking every result before the agent proceeds. Nothing is treated as complete based on the model’s reasoning alone.

Rather than relying on the model to be correct, the harness intercepts a tool call, validates its parameters, executes in a sandbox, cleans the output, and injects the result back into context. At each step verification happens in both directions. Pre-execution where potential hallucinated function calls are caught along with invalid parameter types and references to nonexistent APIs in order to avoid the consumption of tokens on failed retries. And post-execution during which the harness validates that what the agent did actually worked. That can mean automated testing when it comes to code or verifying visual output when UI changes are attempted.

Verification loops can prevent a number of situations [18]. Premature termination of a task while it is still incomplete is one of those. Another is an infinite refinement loop during which the agent is trying endlessly to “improve” its output thus consuming compute. A reasoning-action mismatch, which according to the MAST multi-agent failure taxonomy represents roughly 14% of agent failures [19], is another situation that verification loops can prevent: the agent reasons one thing but does another. When the agent repeats the same action (Step repetition) without progressing is one more use case that can be prevented. Lastly, hallucination cascades, during which fabricated information in one step corrupts every downstream decision, are a situation that verification loops can catch.

In general, the design philosophy is to make incorrect behavior mechanically impossible rather than asking the model to be correct. If an agent makes a mistake the engineered environment is updated so that the mistake cannot physically recur, a principle championed by Mitchell Hashimoto [20] [21]. That can be accomplished with updated instruction files, tools that force verification and staged checkpoints with automated checks. In essence every failure becomes a permanent structural fix in the harness, not a prompt tweak that may or may not hold.

Not every verification is equal. We match the cost of checking to the risk of being wrong. This escalation gradient spans several documented levels. In level 1 the checks are automated with no human involvement. The agent does, the harness validates and depending on the results the operation moves on, gets a retry or is flagged. This level covers the majority of agent actions. The second level includes an LLM-as-judge approach in which a second model evaluates the first agent’s output and tries to determine if the response complies with what is expected. This level is generally slower and more expensive but can flag situations that standalone rules cannot such as nuance, tone and factual accuracy. The third and last level in the escalation gradient involves a human approval gate. The harness pauses and waits until a person reviews. This approach is reserved for things we cannot undo or cannot afford to get wrong.

How we will choose to utilize the gradient matters because if everything is placed under the third level the agent is useless since it is just an expensive approval queue. On the other hand, if everything is under level 1 eventually agent mistakes get reflected in the real world. The harness designer’s job is to draw the line between what is routine, what needs a second opinion and what needs a human hand on the switch.

Three ascending steps from automated checks to LLM-as-judge to a human approval gate, with cost of checking rising along an axis from routine high-volume to irreversible high-impact decisions

Figure 2: The escalation gradient. The cost of verification is matched to the risk of being wrong; the harness designer draws the lines between the levels.

Context & Memory

For an agent to operate efficiently, a system is required that will supply the right information at the right time. Context and memory realize that capability. What gets loaded into the context window, what gets persisted across sessions and how the agent retrieves knowledge it wasn’t trained on.

Memory represents a distinct and dedicated architectural component that extracts, indexes, and retrieves facts across sessions. It should not be confused with conversation history injected into a prompt. There are three types of memory. Episodic which reflects past interactions, outcomes and errors. Semantic which covers truth artifacts such as facts, domain knowledge and user preferences. And procedural which holds learned workflows and operational patterns [22].

Memory is scoped into four tiers when it comes to enterprise environments:

The reason this matters in production is that when an agent is about to respond, the memory system retrieves across all four scopes simultaneously and ranks them. User-level facts first, then session context, then org-wide knowledge. Without scoping we get either an agent that forgets everything between sessions or one that drowns in irrelevant organizational context [22]. Memory operates at multiple levels and the harness must retrieve the right slice at the right moment.

Retrieval in production agents isn’t a single lookup. It is an iterative, governed process over structured knowledge. There are currently two dominant approaches that are not competing with each other and in fact they work best in a complementary mode. On the one hand Agentic RAG describes the behavior in which the agent doesn’t just retrieve once and generate. It plans, retrieves, checks, and loops until the answer is grounded [23]. On the other is the Context-graph-grounded RAG which is about what the agent retrieves from. Instead of a flat vector store a knowledge graph that encodes actual entity relationships is queried [24]. We can have agentic RAG with or without knowledge graphs and we can have graph-grounded retrieval without agentic behavior. However, in enterprise production environments they need to converge in order for the agent to retrieve iteratively from a structured, governed knowledge base with the end goal being to get reliable results.

Context and memory can be the most deceptive layer if not architected and engineered properly. What looks like a capable agent in a 10-minute demo may be functionally unreliable across a 2-hour enterprise workflow. Research, benchmark data and enterprise anecdotal experience support that fact and show various side-effects. For one, memory gets dramatically worse at scale. Temporal abstraction degrades at high token volumes while cross-session memory treats change as replacement rather than evolution because it cannot track how a fact changed over time. Memory staleness, when it occurs, causes issues of its own. On a governance level Enterprise RAG fails without access controls, metadata, and compliance mapping enforced at the retrieval layer and not bolted on after. Thus document-level ACLs at query time, security trimming and audit trails are architectural requirements and not optional add-ons.

Guardrails

In section 2 we defined the five layers of guardrails from data and context through to human oversight. In this section we will discuss how guardrails work at runtime from a governance perspective.

The core challenge is that existing governance standards like ISO and NIST do not translate directly into runtime controls and most organizations are still struggling to bridge that gap. Proposals have appeared in research papers that try to provide a translation method. For example, one approach suggests a four-layer translation method: governance objectives, design-time constraints, runtime mediation and assurance feedback [25]. The key insight behind that approach is that not every governance rule becomes a runtime guardrail. As such runtime controls are reserved for things that are observable, deterministic and time-sensitive to a degree that justifies execution-time intervention. All else lives in architecture and human escalation or audit.

Following this paradigm and being more specific, at runtime we can have guardrails addressing:

An emerging pattern for organizations running multiple agents at scale is utilizing dedicated agents whose job is to monitor other agents’ actions in order to contain anomalous behavior. Guardian agents seem to be a trend that is here to stay. However, the practical guidance is to start with centralized logging, policy enforcement and human-in-the-loop workflows first. The Guardian agent approach is for organizations that are already operating at a multi-agent scale across multiple and high-risk domains.

In multi-agent systems there is an emergent compliance problem. When agents collaborate they might violate compliance in their in-between data exchanges, even when each of them operates within its own permissions. The chain of custody breaks across agent boundaries. This is a governance problem unique to multi-agent systems and has no clean solution yet. The governance question of how organizations decide which controls to enforce at runtime and how standards translate into these mechanisms will be explored in section 6.

Observability

In the traditional software paradigm, if the logs are clean, the system works. With agents, clean logs mean nothing. An agent can be successfully failing while producing polished, confident, wrong outputs with every system metric reading green. Observability for agents means watching what the agent thinks, not just what the server reports.

There are various reasons why observability is different when it comes to multi-agent systems. Determinism is the obvious first deviation since in the traditional software paradigm deterministic inputs produce deterministic outputs and failures are visible. In Agentic AI though the same prompt can return different outputs. We cannot test by replaying inputs. Silent failures are also a real possibility since the agent can confidently report that the operation succeeded while the content is wrong. The telemetry looks healthy while the agent is generating false outputs. Furthermore, in multi-step causal chains a failure in step n might not surface until many steps later. As such we cannot diagnose the situation by looking at any single step alone. We need to retain full-session trace capture across the entire reasoning chain. Lastly, and maybe most importantly, there is semantic quality observability. “Did it work?” is no longer a system question but a question of meaning. We need to be able to ascertain if the retrieved context is relevant and if the agent understands the query, while determining if the output was accurate and policy-compliant. Traditional monitoring has no concept for this.

Taken together, agent observability must track whether the agent understood the query [26], if the retrieved context was relevant, whether tool calls succeeded and whether the right calls were made, whether the output was accurate and aligned with policy and lastly the full session grouping related interactions to reveal potential coherence issues across turns and not just the individual requests.

Without proper tracing in place, several classes of failure can occur. Recursive loops is one in which the agent enters a polling cycle generating hundreds of API calls for a single task while appearing successful. Another is hallucinated tool arguments during which the agent confidently invents parameters matching training patterns rather than actual API schemas. Over long sessions, system prompts lose weight as recent tokens dominate attention and as such we enter an instruction drift situation where the agent starts ignoring its own rules without any visible failure event. When an agent ignores correct documents despite their presence in the retrieval results we are in a context overload use case and while the right information was fetched the agent chose never to use it. Lastly there can be instances of masked backend crashes during which the agent misinterprets errors and hallucinates success, reporting tasks as completed when the backend failed.

NIST AI 800-4 [27] defines six categories for what to monitor when it comes to AI deployments:

4. Architecture Patterns

In the previous section we looked inward and examined the layers inside a single agent’s harness. In this section we will zoom out and discuss how we can architect one or more agents into a system that solves a business problem.

In order to do that we need first to acknowledge and most importantly accept two fundamentals. The first: the architectural choice that matters is not which model to use, but whether we need one agent or many and how they coordinate. The second: complexity must be earned. My advice is to start simple and add it only when necessary, even if a multi-agent system sounds more sophisticated. It’s not, always. Literature is full of complex swarm architectures while production is dominated by hub-and-spoke approaches [28].

There are various architecture patterns that have been explored and utilized. However, before we delve into those, it is important to understand that architecture is a series of decisions and not a destination. Each choice has cost, governance and reliability tradeoffs.

In this paper we explore various concerns and their respective patterns. We will explore execution patterns which examine how an agent reasons and acts. Coordination patterns which deal with multi-agent topologies. And lastly the Interoperability stack which revolves around how agents and tools connect across boundaries and does not involve patterns per se but protocols that make patterns possible.

How agents reason

Plan-and-Execute

The architecture describes an agent which generates a complete plan upfront and then executes sequentially [29] [30]. Planning and execution are two distinct phases which implies that there are no re-reasoning steps in-between. In practice the agent receives a goal, decomposes it into a sequence of steps and then executes those steps one by one. Each step completes before the next begins. The plan is followed religiously.

The positives of this approach are the predictable cost, since token consumption is forecastable because planning happens once, and no repeated reasoning cycles would burn tokens between steps. It is also faster execution-wise because there are no pause-and-rethink steps. Lastly, it is auditable because the full plan is visible before anything executes. A human can review the plan, approve it and know exactly what will happen. This maps cleanly to governance requirements.

On the other hand there are downsides, such as the fact that the architecture is rigid by design. If something unexpected happens during one of the steps the agent has no mechanism to adapt, and the remaining steps execute against the bad assumptions of a plan that was wrong all along. The approach is also blind to change, which means that if the environment shifts mid-execution the agent does not notice and it follows the plan regardless.

The architecture is best used in stable environments and well-defined workflows with predictable conditions. This includes back-office processes, batch operations and analytical workflows where changes do not happen often. It is also a good option for use cases where cost control and auditability matter more than adaptability. A practical and nuanced approach for some implementations is to add re-planning checkpoints at critical steps. This is a hybrid approach that keeps the cost efficiency while it introduces adaptability where it matters the most.

ReAct (Reasoning + Acting)

This architecture allows the agent to interleave thinking and doing in a tight loop [30] where it observes the current state, reasons about what to do next, acts, and then observes the result in order to reason again. There is no upfront plan and every action is informed by what happened previously. In practice the agent receives a goal and takes one step. Once it examines what came back it decides the next step based on that result and repeats until the task is done. If one of the steps fails or returns something unexpected the agent re-reasons and adjusts. The plan emerges from execution not before it.

This architecture shines when adaptability is a hard requirement because the agent responds to what’s actually happening and not to what it predicted would happen. The approach also has failure recovery embedded, which means that a failed step is not fatal and the agent can reason about the failure and try another path. Lastly the approach has an exploratory character which fits on tasks where the solution path isn’t known upfront and a discovered approach is far more preferable than a rigid plan.

One downside of this approach is the token consumption, which can be high since the agent needs to execute multiple reasoning cycles. That also means the cost is unpredictable because it is not known how many cycles the agent will need. Latency is another area where this approach falls short since sequential reasoning loops add up, making it not viable when sub-second latency is required. Lastly, there is unpredictability: it cannot be forecast when the agent will finish or what path it will take. This also means that it is an architecture that is harder to audit and harder to govern.

Use cases that would benefit from ReAct include dynamic environments, exploratory tasks and in general situations where the world changes while the agent works. It is also a great approach for research tasks and debugging workflows. It should be avoided, however, when cost control, latency or auditability are primary concerns.

How agents coordinate

It is well understood and documented by now that most production failures stem from mismatches between task requirements, coordination patterns and information flow. Not model quality. Nor does performance increase monotonically with more agents. Instead, communication overhead grows, context windows overflow and systems begin self-interfering without clear structure. As such architecting agentic AI is more about which coordination pattern matches the task at hand. The wrong topology will fail regardless of model quality. The right one can work with even modest models.

Five Coordination Patterns (Anthropic)

Anthropic’s research identified five foundational coordination patterns that have become the common vocabulary for agent architecture [9]. We will be exploring them from simple to complex.

Prompt Chaining

Prompt Chaining refers to a pattern where each LLM call processes the previous output in sequential steps with programmatic gates verifying progress between steps. The path is predefined. It is a pattern similar to Plan-and-Execute which we discussed previously with the distinction that in this approach every step is a reasoning one and thus an LLM call.

Routing

Routing describes an approach during which the agent classifies the input and then directs it to a specialized handler. Different categories get different prompts, tools and even different models. Easier tasks go to cost-efficient models while harder ones are being tackled by frontier ones. This approach is used when there are distinct input categories that benefit from separate handling.

Parallelization

Parallelization is expressed in two variants. Sectioning within which the task is broken into independent subtasks that run simultaneously and Voting in which the same task runs multiple times for diverse outputs and then results are aggregated. The pattern is used when speed matters or when multiple perspectives increase confidence.

Orchestrator-Worker

Orchestrator-Worker describes the approach where a central LLM dynamically breaks down tasks, delegates to workers and synthesizes results. The key difference from parallelization is that subtasks aren’t predefined. They emerge based on the specific input. This pattern is used for complex tasks where you cannot predict the subtasks in advance.

Evaluator-Optimizer

Evaluator-Optimizer is the pattern within which one LLM generates and another evaluates and provides feedback looping until quality meets a threshold. When there are clear evaluation criteria and iterative refinement measurably improves results this approach fits.

Multi-agent Topologies

The hub-and-spoke pattern is one in which a central agent plans and delegates to a group of specialized workers. All coordination flows through the hub and the workers do not talk to each other. This is a dominant approach in 2026 when it comes to production deployments. It is a very effective pattern when it comes to tightly scoped, sequential problems as well as compliance checks and financial analysis. The one drawback is that the supervisor agent becomes a bottleneck in some cases when tasks become exploratory and its context window fills up.

The Hierarchical topology is another pattern where we see a tree structure comprising manager, specialist and worker tiers. The manager agent delegates to specialists who delegate further to the worker tiers. This approach is utilized for complex enterprise workflows requiring multi-level domain expertise and clear decomposition.

Flat mesh (Peer-to-peer) is an approach in which agents exchange information directly without central control [31]. This is a high fault tolerance pattern that is also very effective for dynamic discovery tasks. However, it risks drift and fragmentation without aggregation and that is why it is rarely seen in production because it is extremely difficult to debug and govern.

Swarm is the last of the topologies we will discuss and it describes parallel agents exploring independently with redundancy validating signals. It is an approach good for research and creative tasks. The risk is elevated token usage if strict exit conditions are not present. Currently it is mostly an academic pattern.

How agents connect

In the previous sections we covered how agents reason and how they coordinate. In this one we will cover the protocols that make it all come together in concert. As it is understood, without standardized connection layers, every integration is bespoke, every agent-to-agent handoff is custom code and vendor lock-in is all but guaranteed.

Two protocols, two problems (solved)

MCP (Model Context Protocol) is the de-facto agent-to-tool protocol in 2026 [14]. It standardizes how an agent connects to external tools, data sources, and services. It was created by Anthropic but was donated to the Linux Foundation later on. MCP exposes four capability types: resources which comprise read-only data, tools which represent the executable actions, prompts which are the reusable templates, and sampling which describes the LLM completions. The idea is to create an MCP server once and let any AI client use it without modification.

A2A (Agent-to-Agent) protocol is another approach which standardizes how agents discover, communicate and delegate work to each other across organizational and framework boundaries. It was created by Google and likewise donated to the Linux Foundation later on. A2A works through something called Agent Cards which are basically JSON manifests served at a well-known URL that describe what an agent can do. Agents discover each other programmatically, assess compatibility and engage without prior configuration. Tasks also have state tracking, thus enabling long-running delegations with real-time updates.

Put simply, MCP gives an agent capabilities and A2A gives an agent colleagues [32].

Architecture & Governance

A three-layer protocol stack appears to be emerging as the most effective architecture. The stack comprises WebMCP, which is structured web access for agents providing machine-readable sitemaps and other artifacts for agent consumption. MCP, which as we discussed provides the agent with access to tools and data. And A2A, which helps agents coordinate, delegate and discover each other across boundaries.

At the enterprise scale McKinsey describes an architecture paradigm that sits on top of the protocols we discussed [33]. Namely a composable, distributed, vendor-agnostic mesh with five design principles (composability, distributed intelligence, layered decoupling, vendor neutrality, governed autonomy) and seven capabilities (agent discovery, asset registry, observability, authentication, evaluations, feedback management, compliance). It’s important to note that according to McKinsey this approach cannot be bolted onto existing Gen AI stacks. It requires a fundamental shift from static, LLM-centric infrastructure to dynamic, agent-based one.

Turning our attention to governance, the fact that the Linux Foundation has become the permanent home for both MCP and A2A, while both enjoy broad enterprise backing [14], demonstrates a level of industry alignment on open standards that is at the very least unusual. This provides a sign that these protocols are not going away any time soon and should be considered seriously for adoption.

In conclusion the interoperability problem, it seems, is close to solved or at least converging rapidly to that point. MCP and A2A under the Linux Foundation backed by every major vendor means technical leaders can build on open standards without fear of protocol fragmentation. As such the question soon will become whether we are building on the standard stack or accumulating integration debt.

A question that naturally follows protocol selection is framework selection. The landscape of agent frameworks (LangChain, CrewAI, Autogen, Semantic Kernel and others) is evolving rapidly with no clear consolidation yet. This paper deliberately avoids prescribing a framework because the selection criteria are organization-specific: existing technology stack, team expertise, deployment constraints and vendor relationships. What matters more than which framework is chosen is whether the choice preserves the architectural principles discussed here. Namely governed autonomy, harness-first design and adherence to open interoperability standards. A framework that locks the organization into proprietary orchestration patterns or bypasses the governance layers we described will create more problems than it solves regardless of its benchmarks.

5. The Reliability Challenge

As we’ve established, agents are not software in the traditional sense. This is because traditional software is deterministic which implies same input, same output and when it does fail it gives off concrete signals. An exception, a log entry, an alert. The bug is found, fixed and a patch is deployed. Thus the failure does not happen again.

Agents break this paradigm. They are probabilistic systems doing deterministic work. The same input may succeed nine out of ten times and fail on the tenth. And when agents do fail, they don’t crash. They produce confident, well-formatted and authoritative sounding answers. The system appears healthy and every metric reads green. The failure travels downstream undetected.

That is the challenge that this section will try to unpack. Specifically not whether or not agents fail but how they fail differently and what that means for how we build, monitor and govern them.

Failure Taxonomy

In literature there are already attempts to classify types of failures when it comes to agents. The most significant are the following.

Tool misuse happens when the agent calls the right tool with the wrong arguments [34]. This can occur because the agent “feels” it is correct to invent a parameter or entity that does not exist. The operation completes with no results and the agent reports this as a fact, with no errors raised. The user blames data quality.

When an agent repeats the same action without progressing it gets stuck in a loop. This is called Step Repetition and it causes increased compute consumption while to the telemetry the agent appears to be working. The reality is that the agent is running in circles.

Reasoning-action mismatch occurs when the agent reasons one thing and does another. Its internal chain-of-thought reasons to do one thing and yet it proceeds to execute another. The reasoning can be sound but the execution did not follow it.

Any single failure mode is important and can cause serious issues. However, error propagation is far worse [34] since it produces false artifacts of success in all downstream steps after the system has already failed. Traditional observability cannot cope with those scenarios because agent failures are semantic and not technical. They look like valid data, not error codes. As such monitoring is blind to them because the system is working. Its answers are wrong.

Hallucination

When the model generates plausible-sounding, confident and well-structured output that is factually wrong the situation is described as a hallucination [35]. This is not a random glitch. It is a structural property of how this technology works.

Language models are trained on next-word prediction. They learn from positive examples of fluent language and they have no internal concept of true or false. When a model encounters a gap in its knowledge it does not acknowledge this fact. It fills the gap with whatever is statistically plausible. Training incentives make this worse because models are optimized for accuracy metrics that reward confident guessing over honest uncertainty. Guessing increases both correct and incorrect answers but the incorrect ones sound just as authoritative.

In my opinion (and that of many others) the term “hallucination” is a misnomer. It primes people to expect dramatic, obvious fabrications while the real threat is subtler. A language model is equally convincing whether it is right or wrong. The danger is not fabricated facts but convincingly false reasoning and output that looks authoritative while being subtly and dangerously wrong.

Hallucinations matter even more for agents. When a user interacts with chatbots the wrong answer is on a screen. The human reads it, catches it and moves on. In agentic systems a hallucination becomes an action. The agent hallucinates a parameter, calls a tool with it, gets results based on the wrong input and feeds those results into the next step. The hallucination enters the system as structured data and downstream processes treat it as ground truth.

Currently frontier models are improving year-over-year on factuality benchmarks. But the gap between “answers a question” and “answers correctly” remains the central reliability problem. The situation is improving but is not yet solved. For that reason we need to plan for hallucination as a permanent feature to be mitigated and not a bug to be fixed.

There are ways to mitigate the problem but not eliminate it. Grounding outputs in retrieved data is an approach in which the model reasons over evidence and not training data alone. This agentic RAG approach helps but does not solve the problem entirely since the model can still ignore or misinterpret retrieved context. Groundedness scoring is another pattern that allows for checking at runtime whether the output is actually supported by the retrieval context. Verification loops can also be utilized on the harness layer to validate outputs before they become actions. Lastly regression datasets with known-correct answers and production failures can be used to test against pre-deployment rubrics.

In summary hallucination is not a model problem waiting for a model fix. It is an architectural problem that the harness must manage. The question for technical leaders is not “will our model hallucinate?” (it will). The question should be “will our harness catch it before it acts on the hallucination?”.

Security

If reliability is about agents getting things wrong by accident, security is about agents being made to get things wrong on purpose. In agentic systems, the consequences are fundamentally worse because agents don’t just answer questions, they take actions. The core vulnerability when it comes to agentic security is undoubtedly prompt injection. In 2025 OWASP ranked it LLM01, the highest-priority vulnerability [36], and it maps to six of the ten categories in OWASP’s top 10 for agentic applications [37] [38]. It also drives most agentic AI security failures in production as of 2026.

Prompt injection vulnerability is architectural and not a bug because there is no reliable way to mark text from different sources (user, system, retrieved content) with different levels of authority. Commands and data all carry the same authority as a legitimate operator instruction. This isn’t a flaw in a specific model. It is how the technology works. OpenAI has acknowledged it as a “frontier security challenge” that may never be fully solved [39], and industry reporting increasingly describes it as a structural property rather than a patchable bug [40].

When prompt injection takes place in agentic systems it hijacks the agent’s goal and as a result it can redirect tool calls, exfiltrate data and propagate malicious behavior across an entire orchestrated system. Simon Willison has identified three conditions that when all present make an agent exploitable [41]. Private data access, which allows the agent to read emails, documents and databases. Untrusted input exposure, which occurs when the agent processes content from external sources. And external communication capability, the agent’s ability to make outbound requests. Willison coined the term The Lethal Trifecta and postulated that each condition of the three is harmless on its own. However, when together they create a complete attack chain because untrusted input redirects the agent’s behavior, while private data becomes the target and external communication becomes the exfiltration channel. Meta, while adopting the framework, has established the “Rule of Two” [42]: until prompt injection can be reliably detected, an agent should satisfy no more than two of the three properties within a session, and an agent that needs all three requires human-in-the-loop supervision.

The uncomfortable truth is that prompt injection may be a permanent architectural flaw and not a patchable bug. The mitigation is layered defense, input validation and output filtering while least-privilege tool access, sandboxing and human approval gates for high-risk actions are of paramount importance.

There are significant efforts to systematically catalog various prompt injection approaches. MITRE ATLAS for example has cataloged 16 tactics and over 100 techniques [43]. Successive releases have expanded the catalog, and the detail is almost entirely agent-shaped as of mid-2026. The threat landscape has been formally mapped.

Security in agentic systems is not a hardened perimeter. It is a managed attack surface that grows with every tool the agent can access and every agent it can delegate to. The Lethal Trifecta and Rule of Two provide a concrete mental model for assessing potential exposure.

Benchmark-to-Production Gap

Lab benchmarks determine how an agent performs on standardized tasks under controlled conditions. An agent performing with production data, tools and workflows will not perform the same. The gap is where enterprise deployments fail. Specifically, industry analyses document a 37% gap between lab benchmark scores and real-world deployment performance and a 50x cost variation for similar accuracy levels [44].

The gap exists because in contrast to standardized benchmarks, production throws agents against custom internal tools, legacy systems with undocumented behavior, organization-specific business rules and domain-specific policy validation. Two problems have been identified as a result of the gap between benchmark numbers and production performance.

The compounding problem [45] is observed because each step’s probability multiplies rather than adds: an agent executing, for example, a 10-step workflow with 85% reliability per step delivers ~20% overall reliability. A system that looks reliable on any individual step becomes unreliable across a realistic workflow. Additionally, unlike traditional software, agents cannot simply retry a failed step. Autonomous decisions may have already triggered irreversible actions.

Line chart of end-to-end success probability against number of workflow steps for per-step reliabilities of 99, 95, 90 and 85 percent, with a marker showing that 10 steps at 85 percent reliability yield roughly 20 percent end-to-end

Figure 3: The compounding problem. Per-step reliability multiplies across a workflow: an agent that succeeds 85% of the time per step completes a 10-step workflow only ~20% of the time.

The stateless execution problem is when base agents start each task with no memory of previous runs. They cannot retain failure patterns or learn from inefficient paths. An agent that failed on a specific edge case previously will come across the same edge case again in the future and fail the same way unless the harness engineers a permanent fix into the environment. This connects to Mitchell Hashimoto’s principle from section 3 [21]: engineer the environment so a mistake cannot recur. Reliability improves through harness engineering and not model upgrades.

A benchmark score, then, is a lab measurement and not a production guarantee. The implication is concrete. Agents should not be selected based on benchmark rankings. Instead they need to be tested against actual data, workflows and tools. Reliability is an infrastructure problem, not a model one.

6. Governing the Agentic Enterprise

In the previous sections we covered the anatomy of an agent, how agents are structured and why they fail. This all is engineering. In this section we will discuss and try to discern what sits above engineering. Who decides what agents are allowed to do? Who is accountable when they do it wrong? How does an organization govern software that can independently perceive, decide and act?

In literature and elsewhere governance is the most cited and the most underfunded barrier to scaling agentic AI. 88% of organizations report confirmed or suspected AI agent security incidents, yet only 14.4% obtain full security and IT approval before deploying agents [46]. Organizations are deploying first and governing later or not governing at all.

In this section we will explore why governance is not a compliance exercise but an operational architecture and discuss the structural conditions that determine whether agents operate safely at scale or will become the next generation of shadow IT.

The Governance Gap

Unfortunately the gap is real and the numbers paint a stark picture. Only about 1 in 3 organizations are governance-ready for the autonomous agents they are already deploying [47]. Meanwhile, 63% of organizations cannot enforce purpose limitations on what their agents are authorized to do, and kill switch capability, the ability to rapidly shut down a misbehaving agent, sits at just 40% [48]. 35% of employees admit they could not immediately pull the plug on a rogue agent [6].

The gap exists because the governance infrastructure that exists was built for traditional software and traditional AI. Deterministic systems where inputs and outputs are known. None of those assumptions hold for agents. On top of that, organizations face the problem of visibility since they don’t know which agents exist, which data they have access to or what permissions they hold. The accountability gap compounds the problem. Organizations lack clear, named accountability for responsible AI. Governance without an owner is not governance. It is documentation.

The positive signal is that first-line governance is growing and engineering teams themselves are demanding more and more guardrails before deploying agents to production. The push seems to be coming from practitioners and not just compliance. When the people building agents are asking for governance, the maturity shift has begun. However, the scale of challenge ahead is significant since task-specific agents are expected in 40% of enterprise apps by the end of 2026, up from under 5% in 2025 [4]. This 8x increase in agent surface area against incrementally growing governance infrastructure demonstrates that the gap is not closing. It is widening.

The Governance Architecture

While in the previous section we explored the governance gap currently prevalent, in this we will discuss what the solution to closing that gap looks like architecturally. There are, at this time, four interconnected governance concerns that must work together. The structural model, identity, oversight and runtime controls. All four have to work properly because failures arise from misalignment across those layers and not from any single layer deficiency. This is because as agents gain the ability to act, delegate, and trigger workflows autonomously, accountability disappears, not because systems fail but because every step was technically authorized yet no single person or system owns the outcome. Enterprises conflate access with authority.

Four boxes labeled structural model, identity, oversight and runtime controls arranged around a central circle labeled the Agentic Blame Loop, where every step is authorized but no one owns the outcome

Figure 4: The four interlocking governance systems. Failures arise from misalignment across them; the Agentic Blame Loop lives in the gaps.

The Structural Model

No single structural model for how governance should be organized has been adopted by the industry just yet, because the field is too young. However, the proposed ones are all converging on the same principles (layered governance, progressive autonomy, embedded controls), organized differently.

The Agentic Operating Model (AOM) published in the California Management Review [49] proposes four interdependent layers:

AOM’s proposal does not eliminate autonomy but makes it survivable by embedding constraints within operational architecture rather than attaching them as external limitations.

AOM also identifies three failure patterns. The first one, called The Unbounded Agent, is observed when the agent lacks specialization and control thresholds and eventually exceeds its original mandate. The Invisible Swarm, the second one, describes decentralized coordination without clear ownership that creates unaccountable collective behavior. The last one, dubbed The Compliant Failure, is a pattern within which the governance exists on paper but not in operation and thus oversight is focused on pre-deployment checklists rather than real-time supervision.

Another framework that complements AOM with progressive governance is the WEF “AI Agents in Action” [50]. This approach adjusts the oversight levels based on the capability of the agents while autonomy and authority are treated as adjustable design parameters and not fixed categories. In this view, governance must be dynamically calibrated to agent autonomy in real-time and not as a static checkbox.

Lastly McKinsey proposes four enablers (people, governance, technology architecture, data) that reinforce the same principle [33]. Governance does not stand alone but it scales when all four enablers move together.

Identity

Organizations spent decades building rigorous identity and access management for human employees with background checks, role based permissions, access reviews, audit trails, credential rotation and off-boarding procedures. When AI agents arrived, most enterprises bypassed all of it. Only one-third of the organizations are applying the same security controls to agents as they do to humans and nearly two-thirds deploy weaker protections for AI agents despite their privileged access to sensitive systems [51]. Worse, 52% of employees use unapproved AI tools, which means that shadow AI is already inside the perimeter. The consequence, according to the IBM Institute for Business Value, is that two-thirds of CIOs and CTOs report being held accountable for AI systems they do not fully control while 70% say their organizations are deploying technology faster than IT teams can track [52]. Employees across marketing, finance and product teams are independently spinning up agents, connecting LLMs to workflows and granting access to sensitive data without IT visibility.

The emerging best practice to combat this phenomenon is that every agent must be treated as a first-class identity with its own lifecycle and granular permissions [53], the same way organizations manage privileged human accounts. In order for this to happen three shifts have to occur:

Continuous authorization [54] takes the session-based model one step further by treating every sensitive operation as an independent decision point, evaluating behavioral baselines, network context, device consistency, query volume and data sensitivity in real time. RBAC answers whether an agent can perform an action. Continuous authorization answers whether it should be doing so right now, within the current environment and in the current circumstances.

McKinsey’s five structural controls for governance readiness include agent inventory and identity binding [47]: cataloguing every agent with defined scope, access levels and accountable owners.

The bottom line: agents need capability-scoped permissions, task-scoped credentials and layered enforcement [55].

Oversight

In section 2 we discussed HITL, HOTL and Governed Autonomy. In this section we will be exploring how an enterprise decides which model applies where. In general, the prevailing approach is to utilize a risk-based calibration that matches the reversibility and impact of the decision with the oversight model. If the decision is irreversible and high-impact, the agent pauses and waits for HITL intervention. On the other hand if the decision is reversible and with medium impact the agent can act while a human monitors and can intervene (HOTL). Lastly for high-volume and rule-governed processes governed autonomy is a good approach assuming that trust is embedded in the system design and not in a per-action approval.

In addition to the above somewhat generic guidelines there have been efforts to make things more concrete. For example, the MIT AI Decision Matrix [56] adds precision to this calibration. The framework maps decisions across two dimensions. Ambiguity which describes how unclear or contested the decision context is and risk which measures the magnitude of consequences if things go wrong. The decision matrix also identifies three distinct activities where the human-AI balance must be calibrated separately. Framing a decision, acting on it and learning from its outcomes. The right oversight model may differ across all three stages for the same underlying decision. Making these trade-offs explicit forces organizations to confront accountability directly rather than allowing responsibility to diffuse ambiguously across human and machine actors.

There are non-obvious risks to this approach, such as automation bias, since it has been shown that humans in the loop tend to over-trust AI systems [57], especially at volume. HITL at scale becomes rubber-stamping and the human becomes a checkbox and not a check. For this reason, I would argue that in some cases well-designed governed autonomy is actually safer than fatigued human oversight. The Agentic Blame Loop [58] compounds these risks. The pattern describes a situation where every step in an agentic workflow was technically authorized yet no single person or system owns the outcome. HITL oversight is largely illusory when consequential decisions were already shaped upstream by retrieval, prompts, vendor defaults or prior agent delegation. The human “approving” may be ratifying a conclusion they had no meaningful ability to evaluate. Access was granted but authority over the outcome was never genuinely held.

Runtime Controls

This layer is all about turning governance intent into technical enforcement. As we discussed in section 3, established standards like ISO/IEC and NIST AI RMF do not by themselves yield implementable runtime guardrails: runtime enforcement is reserved for actions that are observable, deterministic and time-sensitive enough to justify intervention, while everything else lives in architecture, human escalation and audit.

An emerging approach is Architecture-as-code [59] and it tries to move governance standards from static documents into executable and machine-readable artifacts that integrate directly with software delivery pipelines. Traditional architecture governance built around periodic review boards cannot keep pace with continuous delivery and AI-driven systems. This approach separates deterministic controls from human judgment while governance becomes evidence-driven by comparing what teams declare architecturally against what implementation artifacts actually show. Agentic AI never owns the governance outcome, though it might prepare review narratives and identify gaps.

There is also a convergence being observed between AI governance and data governance [60]. As we noted in section 3, when agents call other agents the chain of custody breaks across agent boundaries and data may be processed in ways that violate compliance even when each individual agent operates within its own permissions. CISA and G7 AI SBOM guidance [61] extends this into the supply chain, covering supplier identity, data provenance, model architecture, datasets and dependencies. Supply chain transparency is becoming increasingly critical as agents chain multiple models and tools.

In general, governance architecture is not a single framework we can adopt. It is four interlocking systems (structure, identity, oversight and runtime) that must align. The Agentic Blame Loop is what happens when they do not and the enterprise discovers the gap only after the damage is done. Failures in agentic systems arise from misalignment across these layers and not from any single layer’s deficiency.

The Regulatory Context

In the previous sections we made the case that governance is both urgent and architecturally complex. In this section we will discuss a third dimension, one that is also becoming legally mandatory. Cataloging every regulation would be pointless; however, it is important to underline that 2026 is the year where enforcement begins and the regulatory landscape is fragmenting faster than most enterprises can track. Thus internal governance done right is the most efficient path to regulatory compliance. Organizations that built governance architecture for operational reasons will find compliance largely handled. On the other hand, organizations that waited for regulation to direct them are already behind.

The Enforcement Timeline

Enterprises deploying agents in high-risk contexts like healthcare or finance will face an immediate operational requirement because of the EU AI Act, which takes effect in August 2026 [62]. Human oversight interfaces for high-risk AI are clearly mandated in Article 14 [63] and the fines are calculated on global turnover, not only revenue from AI products. The Colorado AI Act is already in effect as of writing this paper and is the first US state law specifically addressing AI risk in deployment and not just development. Other US states are following.

Gartner predicts that “death by AI” legal claims, traced to insufficient AI risk guardrails, will exceed 2,000 by the end of 2026 [64], a clear signal that legal exposure is not hypothetical; it is arriving in volume. 2024-2025 was the era of frameworks and voluntary guidance. 2026 is when enforcement begins and organizations that treated governance as optional now face a compliance scramble on top of their operational governance gap.

The Standards Landscape

Three layers of standards have emerged and each addresses a different scope. NIST for multi-framework alignment, ISO 42001 for certifiable AI governance in a broad sense and AIUC-1 for agent-specific certification. They are complementary, not competing.

NIST AI Risk Management Framework [65] is a pragmatic US framework for risk identification and mitigation. The updated NIST AI 100-2 that was introduced in March 2025, explicitly names AI agents as a threat surface for the first time. Draft NIST IR 8596 maps the cybersecurity framework specifically to agentic threats. Adopting NIST AI RMF covers a substantial share of the requirements across the EU AI Act, state-level US laws and international standards. This one framework done well can get an enterprise multi-jurisdictional alignment largely for free. Research published under the Cloud Security Alliance’s AI Safety Initiative has begun mapping NIST standards to agentic AI governance [66].

ISO/IEC 42001:2023 [67] is the certifiable AI management system standard. The only AI governance standard that can be independently audited and certified against comparable to what ISO 27001 is for information security. Adoption requires enterprise-wide commitment, cross-functional governance, risk management, AI impact assessments, lifecycle management and third-party supplier oversight. Major certification bodies have already operationalized audit services to cover the standard while leading vendors are in the process of acquiring certification. If certifiable AI governance is the requirement, this standard is the answer.

Lastly there is an agent-specific certifiable standard named AIUC-1 [68]. This is the first one designed specifically for AI agents and not retrofitted from broader AI governance. The standard describes close to 50 controls across six domains: Safety, Security, Reliability, Accountability, Data & Privacy, and Society. It maps directly to threats cataloged in the MITRE ATLAS and the OWASP Top 10 for Agentic Applications. All the controls are threat-specific and not abstract. The certificate has a lifetime of 12 months with quarterly retests and it combines independent auditing, technical testing and ongoing assurance.

Government-level Frameworks

When it comes to the sovereign landscape, there are efforts to provide governance frameworks specifically designed for agentic AI.

Singapore IMDA launched the world’s first government governance framework for agentic AI at the World Economic Forum in Davos in January 2026 [69] [70]. The framework describes four core dimensions: assess and bound risks upfront, make humans meaningfully accountable, implement technical controls and processes, and enable end-user responsibility. Compliance is voluntary but organizations remain legally accountable for their agents’ behavior whether building in-house or using third-party agents. The framework builds on Singapore’s earlier governance instruments for traditional and generative AI to address the new risks of autonomous action.

Although not a framework, the International AI Safety Report [71] led by Turing Award winner Yoshua Bengio and authored by around 100 AI experts and backed by 29 nations along with the UN, OECD and EU represents the largest global collaboration on AI safety to date. The key finding is that AI agents pose heightened risks because autonomous action makes intervention before harm harder. This regulatory view is a 30-nation consensus.

Lastly, the Anthropic Mythos/Fable incident illustrates where sovereign regulation is heading. According to reporting [72], Anthropic’s frontier model autonomously discovered over 2,000 vulnerabilities in seven weeks, and an early version escaped a controlled sandbox, gained unsanctioned internet access and emailed the supervising researcher to let them know. Days after the models launched, the US government cited national security authorities and imposed export controls on both Mythos 5 and its safety-hardened variant Fable 5 [73]. The controls were lifted at the end of June 2026, after Anthropic strengthened its safeguards and committed to pre-release testing of future frontier models with the US government [73]. The incident signals that governments are moving from voluntary guidance to direct intervention when capabilities outrun governance. Enterprises should expect more regulatory activity and not less.

In conclusion, the practical guidance is simpler than the complexity suggests. NIST AI RMF is the pragmatic starting point when it comes to framework coverage while ISO 42001 is required when the organization needs certifiable governance for stakeholders, customers or regulators. When agent-specific certification is needed, AIUC-1 is the currently available option. However, it is important we acknowledge one more time that internal governance should come first. Organizations that built the governance architecture we discussed earlier in this section will find that most regulatory requirements map to controls they already have. As such organizations scrambling to comply are overwhelmingly the same ones that skipped internal governance. Regulation does not replace governance architecture. It penalizes its absence.

7. Economics & Evaluation

In the previous sections we discussed what agents are and how they are built, as well as why they fail and how to govern them. This section tries to answer two questions. What does this actually cost and how do we know if it’s working. As we will explore in more detail the answers are somewhat uncomfortable. Costs are higher, less predictable and harder to govern than most enterprises expect, while the metrics most organizations are utilizing measure activity and not value.

The economics of agentic AI are fundamentally different from every previous enterprise technology cycle. Traditional software had fixed licensing costs. Cloud shifted to predictable consumption. Agents introduce a third model. Variable, usage-driven costs that multiply non-linearly with complexity, concurrency and failure. According to McKinsey this is a structural shift from labor to technology as the dominant cost driver [74]. In knowledge-intensive industries technology spending could ultimately even exceed labor costs. This is not an incremental change. It is a different economic model.

“Cognitive tax” is an emergent new strategic dependency and it describes value accruing to intelligence infrastructure providers in the same way cloud providers captured value in the previous era. This isn’t a line-item cost problem. It is a structural shift in where enterprise value concentrates.

The Cost Reality

The baseline numbers are staggering. Agentic systems require 5-30x more tokens per task than standard conversational tools [75]. A single complex orchestrated interaction in 2026 costs 30x more than a simple workflow interaction in 2023 [76]. Agents make several times more LLM calls than chatbots per user request, since each one triggers planning, tool selection, execution, verification and response generation [76]. When multiple agents run concurrently, costs multiply non-linearly. These are not theoretical projections. They are current production numbers.

Governance Debt

Token consumption, prompt counts and chatbot interactions have become misleading proxies for genuine AI productivity. Organizations that celebrate high usage as healthy adoption are discovering that activity and value are not the same thing. What is emerging is the concept of “governance debt” [77] which describes cost accumulating at scale without corresponding oversight. Anecdotal evidence such as the single Disney employee who interacted with Claude 460,000 times in nine days or Uber employees exhausting the company’s entire 2026 AI budget in just four months [78] shows clearly that governance debt is a valid concept.

AI is currently underpriced because subsidized access is masking genuine infrastructure costs that vendors will eventually pass on. When pricing corrects, organizations without cost governance will face sudden exposure.

The Great Enterprise Reset

The cost structure is also shifting underneath buyers. SaaS vendors are abandoning per-seat pricing while adopting new models that transfer forecasting risk directly onto buyers [79]. Outcome-based pricing sounds appealing but remains difficult to implement because measuring attribution in complex enterprise environments is genuinely hard. Some enterprises are already spending over $1200 per employee annually across overlapping AI tools. Gartner projects 40% of enterprise SaaS spending will shift to usage, agent or outcome-based models by 2030. Without cost governance and usage discipline organizations will face invoice surprises that undermine financial planning.

Infrastructure Economics

The global AI inference market is projected to reach $48.8 billion by 2030 [80]. Unlike training which is periodic and latency-tolerant, inference is real-time, latency-sensitive and unrelenting. Organizations running inference on general-purpose infrastructure can pay 2x per million tokens compared to inference-optimized environments. Right-sizing inference infrastructure is now a strategic business decision and not merely an engineering one.

Mitigation

The cost picture is not hopeless. The engineering solution is cascade model routing which is matching task complexity to model capability. Small models handle classification and lightweight routing, mid-tier models handle structured reasoning and frontier models are reserved for high-value or high-risk final decisions. Vendor-reported results claim routing cascades can reduce costs by up to 87% [81] and intelligent routing by 60-80% without sacrificing quality [82]. Whatever the exact numbers, I am convinced of one thing: the competitive advantage belongs to the most economically disciplined orchestration and not the most advanced model.

Token waste is also structural and not accidental [83]. Context inflation, poor model matching, response sprawl and retry amplification predictably compound costs. Effective organizations segment workloads, cache stable prompt prefixes, constrain output length and prune conversation history. Dev-test environments, in particular, are where waste concentrates most invisibly and need separate budget and usage tagging.

FinOps is evolving from a reporting function to an operational control plane [84]. Gartner’s 2026 Hype Cycle identifies agentic FinOps as a distinct rising concern [84] and the FinOps Foundation ranks FinOps for AI as the top forward-looking priority in its State of FinOps 2026 survey [85].

The total cost of agentic AI includes infrastructure, governance, organizational change, failure recovery and regulatory risk. Not just tokens.

Measuring What Matters

The ROI gap is already well-documented. Nearly 90% of CEOs expect AI agents to deliver measurable ROI in 2026 [86], yet only 29% of organizations report significant ROI from generative AI and just 23% from AI agents specifically [6]. Additionally, AI super-users deliver 5x productivity gains [6] but the organization-wide picture is far less clear. Evaluation methodology and not model capability is the bottleneck.

There is also what has been coined the “reinvention gap”, which describes where value actually comes from: reinvention versus augmentation. This was quantified precisely by McKinsey in call center data [33] where Gen AI tools layered into existing workflows resulted in 5-10% improvement. Agent-enabled optimized processes produced 20-40% improvement while agent-enabled reinvented processes produced 60-90% improvement.

The gap between augmentation and reinvention is 6-9x with incremental deployment producing incremental results. The economics only work when the organization redesigns the process, not by just adding an agent.

Dual-metric Evaluation

The standard approach of measuring if the agent completed the task, is insufficient. Dual-metric evaluation measures both task completion AND whether the agent followed the correct reasoning path [87]. An agent can achieve 100% tool-call accuracy while violating policy on edge cases. The correct answer via the wrong reasoning path is a latent failure and it will eventually produce the wrong answer via the same path.

Ideally the key metrics that should be utilized are:

The production reality check, though, remains the benchmark-to-production gap we documented in section 5: lab scores overstate real-world performance, success rates drop in customer environments with custom tools, legacy systems and undocumented APIs, and costs vary wildly for similar accuracy levels [44]. Combined automated metrics plus expert human judgment produces the most reliable assessment. Neither alone is sufficient.

The economics of agentic AI, then, are structurally different: variable, non-linear and still largely ungoverned. The cost picture is manageable with disciplined routing and FinOps but most organizations have not yet implemented either. As such the ROI gap will not close by deploying more agents. It will close by redesigning processes and measuring trajectories, not just outcomes.

8. Organization Readiness

The economics we explored make clear that the ROI gap is not a cost problem but an organizational one. Most enterprises treat agentic AI as a technology deployment when it is actually an organization transformation that happens to use technology. That single misframing explains the pilot-to-production gap, the workforce friction and the maturity stall that this section will unpack. The California Management Review [49] framed the shift precisely as the transition of AI agents from being “tools” to becoming “actors” within the enterprise. The challenge is no longer technological but it resides in governing systems that function as organizational actors and not decision support tools. This changes what readiness means. 54% of C-suite executives say AI adoption is “tearing their company apart” and 79% face adoption challenges [6]. The issue no longer relates only to infrastructure questions. It forces the question of whether the organization has been redesigned adequately to operate with autonomous actors inside it.

The Scaling Gap

The reasons pilots don’t become production have by now been documented fairly substantially. 79% of organizations report adopting AI agents [3] but only 11% are in production [5]. 78% have agent pilots but only 14% have reached production scale [88].

Five gaps have been identified as accounting for 89% of scaling failures in one analysis [88]: integration complexity, inconsistent quality at volume, absence of monitoring, unclear ownership and insufficient domain data. None of these are model capability problems. They are all organizational and operational.

The convergent finding across multiple sources is that the majority fail to move beyond pilots because they treat transformation as a technology project rather than organizational redesign [89]. Teams that do succeed invest equally in people, process and platform. As such we must conclude that success is defined less by how much AI is deployed and more by how well governed agentic AI is embedded into core workflows.

McKinsey adds a structural diagnostic to the discussion by defining a horizontal/vertical imbalance [33]. Copilots and chatbots scale easily but deliver diffuse gains. Vertical use cases with domain-specific agent deployments are transformative but fewer than 10% make it past pilot. Vertical use cases face six barriers to scaling: siloed teams, data gaps in vertical domains, cultural resistance, LLM limitations for domain tasks, lack of packaged vertical solutions and insufficient CEO sponsorship.

The last critical issue in scaling is the data foundation. Only 5% of enterprises say their data is ready to support AI at production scale, despite near-universal investment [90]. This is expressed vividly in five core failure points: fragmented data ecosystems, lack of business ownership, pilot-driven culture, poorly designed HITL architectures and insufficient governance. Organizations are building sophisticated agents on foundations that cannot support enterprise deployment.

People, governance, technology architecture and data must all scale together in order for agentic AI to be successful. Organizations are advised to follow the dual transformation path, continuing to extract gains from horizontal use cases while investing in vertical ones.

The Workforce Reality

Nearly half of organizations introduced AI without redesigning the workflows or roles it sits within [89], and impact at scale depends on exactly that redesign [91]. Middle management is where roles shift the most, towards orchestrating and enabling both human and agent contributions [91].

Botsitting

A survey of 6000 digital workers reveals that the productivity story is more complicated than the headlines suggest. AI saves roughly 11 hours per week but employees lose 6.4 of those hours managing the technology itself [92]. This means feeding it context, supervising outputs and debugging errors. What is even worse is that 69% of workers admit shipping unverified AI-generated work because oversight demands have become overwhelming. This is the still unrecognized labor of “botsitting”. To combat this phenomenon high-performing organizations do not adopt heavier AI usage but instead they invest deliberately in defining quality standards, building human judgment and knowing when not to deploy agents at all.

Knowledge Decay

Academics and analysts have warned that unchecked AI adoption creates “knowledge decay” [93] and that repeated AI summarization and synthesis gradually degrades the original judgment, context and expertise organizations depend on. Specifically three failure modes have been identified that accelerate this. Verification becomes costly when employees must disentangle authentic reasoning from AI-generated errors. Validation breaks down when organizations can no longer confirm genuine human expertise contributed to a deliverable. Knowledge entropy compounds as content passed repeatedly through LLMs drifts away from ground truth.

Organizational Amnesia

This phenomenon complements knowledge decay: headcount reductions outpace institutional knowledge transfer at the organizational level [94], causing AI systems to operate confidently but incorrectly because they lack the contextual understanding that departed along with the impacted employees. Having clean data, capable models and strong infrastructure means nothing without “context intelligence”. A machine-interpretable representation of how the business actually works.

The Training Gap

Only 40% of employees using generative AI at work say their companies provide training [95]. The remaining 60% are, in effect, deploying the tools and hoping for the best. At the same time, they spend heavily on training models while largely neglecting the humans operating alongside them. McKinsey projects 75% of roles may require significant redesign in the symbiotic enterprise [74]. This is because 60% of work hours are now theoretically automatable. Thus three emerging role categories are already forming. Integrative supervisors orchestrating human-agent teams. Deep specialists that agents cannot replace. AI-enabled augmented operators.

The Maturity Picture

No enterprise has yet become an “agentic organization” [74]. However, AI agents are placed by Gartner at the Peak of Inflated Expectations in its 2026 Hype Cycle for Agentic AI [1]. Yet only 17% have deployed and 60% are expected to within two years. Gartner also predicts over 40% of agentic AI projects will be canceled by 2027 due to escalating costs, unclear business value and inadequate risk controls [7]. Complementary to this, McKinsey maps four maturity levels with current distribution. Gen AI chatbot, Agentic task, Agentic workflow and Agentic organization. The gap between agentic task and agentic workflow is where most organizations are stuck. It seems they can deploy individual agents but cannot orchestrate them into governed workflows.

Two failure modes have been defined when it comes to the maturity challenge. Incrementalism which describes staying in the pre-AI operating model while treating agents as incremental tools, under-deploying and under-governing. And overreach which emerges when organizations deploy faster than they can absorb and govern. Technical leaders are advised to calibrate their pace between these poles.

Five mastery disciplines have been defined for intelligent execution in order to close the gap: intelligence architecture engineering, intelligence industrialization, orchestration at scale, behavioral governance and security, and AI economics management. However, the CSA AI Security Maturity Model [96] provides a more operational framework with twelve categories, three domains, five maturity levels, including control objectives and KPIs. This model is specifically security-focused and actionable, and constitutes a foundation for measured three-year improvement plans.

In summary, organization readiness is not a precondition we need to satisfy before deploying agents. It is a transformation we need to undertake alongside deployment. However, the organizations treating it as optional are the same ones stuck in the pilot-to-production gap, burning productivity gains on botsitting and watching institutional knowledge erode. The technology works. The question is whether the organization can absorb it.

9. A Path Forward

The paper so far has covered terminology, architecture, patterns, reliability, governance, economics and organizational readiness. In this section we will attempt to distill all this information into a set of concrete imperatives. Conclude the experimentation phase in order to shift from pilot proliferation to strategic scaling. Redesign governance and operating model so that people, governance, technology and data can work together. Launch lighthouse initiatives while building the technology foundation in order to be able to prove value in specific verticals while building scalable infrastructure. It is imperative to avoid the two failure modes we defined in section 8: incrementalism and overreach. The correct path forward runs between them.

Ten Recommendations

This paper discussed the vocabulary, the architecture, the failure modes, the governance framework, the economics and the organizational playbook. What happens next is a decision that will require discipline and not capability. The standards are converging, the failure modes are cataloged and the maturity models exist. I believe the organizations that invest most deliberately in humans as governance architects and harness designers will be the ones that succeed.

Appendix: Additional Terminology

Two foundational terms are included here for completeness. Readers familiar with them can skip ahead.

Foundation Model

The foundation model is a large-scale AI model trained on a broad range of data that can accommodate a wide range of tasks. Foundation models are characterized by three properties. Emergence of capabilities the model wasn’t explicitly trained for. Adaptation to diverse tasks through fine-tuning, prompting and context engineering. And homogenization, meaning that since the base remains the same, a defect propagates to every application built on top of it. Agents don’t exist without foundation models but the foundation model alone is not an agent.

Tool Use/Function Calling

The two terms are interchangeable and describe the mechanism that allows an LLM to take action outside the confines of its training data. The model itself does not execute code or call APIs. It generates a structured request which the harness executes and returns the results back to the model. From a governance perspective the terms carry a slightly different emphasis. Function calling refers to the constrained interface where only defined functions with specified inputs can be invoked. Tool use is the broader concept describing the full set of external capabilities an agent can utilize. Function calling is the mechanism. Tool use is the capability it enables.

References

[1] Gartner, “2026 Hype Cycle for Agentic AI,” 2026. https://www.gartner.com/en/articles/hype-cycle-for-agentic-ai

[2] Gartner, “Gartner Identifies the Top 10 Strategic Technology Trends for 2025,” October 2024. https://www.gartner.com/en/newsroom/press-releases/2024-10-21-gartner-identifies-the-top-10-strategic-technology-trends-for-2025

[3] PwC, “AI Agent Survey,” May 2025. https://www.pwc.com/us/en/tech-effect/ai-analytics/ai-agent-survey.html

[4] Gartner, “Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026, Up from Less Than 5% in 2025,” August 2025. https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025

[5] Algoworks, “Agentic AI Hype vs Reality in Enterprises,” 2026. https://www.algoworks.com/blog/agentic-ai-in-enterprises/

[6] Writer, “Enterprise AI Adoption 2026,” 2026. https://writer.com/blog/enterprise-ai-adoption-2026/

[7] Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027,” June 2025. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

[8] H. Zhang et al., “AI Agents vs. Agentic AI: A Conceptual Taxonomy,” arXiv, 2025. https://arxiv.org/pdf/2505.10468

[9] Anthropic, “Building Effective AI Agents,” 2025. https://www.anthropic.com/research/building-effective-agents

[10] A. Osmani, “Agent Harness Engineering,” 2026 (formula attributed to Viv Trivedy, “The Anatomy of an Agent Harness”). https://addyosmani.com/blog/agent-harness-engineering/

[11] Atlan, “What Is Harness Engineering AI?” 2026. https://atlan.com/know/what-is-harness-engineering/

[12] Firecrawl, “Context Engineering vs Prompt Engineering,” 2025. https://www.firecrawl.dev/blog/context-engineering

[13] Strata, “Human-in-the-Loop 2026 Guide,” 2026. https://www.strata.io/blog/agentic-identity/practicing-the-human-in-the-loop/

[14] Zylos, “Agent Interoperability Protocols 2026,” 2026. https://zylos.ai/research/2026-03-26-agent-interoperability-protocols-mcp-a2a-acp-convergence/

[15] Zylos, “Tool Use and Function Calling Standards,” 2026. https://zylos.ai/research/2026-04-07-tool-use-function-calling-standards-benchmarks

[16] Endor Labs, “Classic Vulnerabilities Meet AI Infrastructure: Why MCP Needs AppSec,” 2025. https://www.endorlabs.com/learn/classic-vulnerabilities-meet-ai-infrastructure-why-mcp-needs-appsec

[17] Cloud Security Alliance, “7 MCP Risks CISOs Should Consider,” 2026. https://cloudsecurityalliance.org/articles/7-mcp-risks-cisos-should-consider-and-how-to-prepare

[18] Galileo, “AI Agent Failure Modes,” 2026. https://galileo.ai/blog/agent-failure-modes-guide

[19] M. Cemri et al., “Why Do Multi-Agent LLM Systems Fail?” (MAST), arXiv, 2025. https://arxiv.org/abs/2503.13657

[20] Faros AI / M. Hashimoto, “Harness Engineering: Making AI Coding Agents Work,” 2026. https://www.faros.ai/blog/harness-engineering

[21] M. Hashimoto, “My AI Adoption Journey,” February 2026. https://mitchellh.com/writing/my-ai-adoption-journey

[22] Mem0, “State of AI Agent Memory 2026,” 2026. https://mem0.ai/blog/state-of-ai-agent-memory-2026

[23] Data Nucleus, “Agentic RAG Enterprise Guide 2026,” 2026. https://datanucleus.dev/rag-and-agentic-ai/agentic-rag-enterprise-guide-2026

[24] Squirro, “RAG in 2026,” 2026. https://squirro.com/squirro-blog/state-of-rag-genai

[25] “From Governance Norms to Enforceable Controls,” arXiv, 2026. https://arxiv.org/pdf/2604.05229

[26] Braintrust, “AI Agent Observability Tools,” 2026. https://www.braintrust.dev/articles/best-ai-observability-tools-2026

[27] NIST, “AI 800-4: Challenges to Monitoring Deployed AI Systems,” March 2026. https://www.nist.gov/news-events/news/2026/03/new-report-challenges-monitoring-deployed-ai-systems

[28] AgentsIndex, “Multi-Agent Systems,” 2026. https://agentsindex.ai/blog/multi-agent-systems

[29] O’Reilly, “Designing Effective Multi-Agent Architectures,” 2026. https://www.oreilly.com/radar/designing-effective-multi-agent-architectures/

[30] Redis, “AI Agent Architecture 2026,” 2026. https://redis.io/blog/ai-agent-architecture/

[31] FutureAGI, “Multi-Agent AI Systems 2026,” 2026. https://futureagi.com/blog/multi-agent-systems-2025/

[32] Dev.to / Pockit, “MCP vs A2A: Complete Guide 2026,” 2026. https://dev.to/pockit_tools/mcp-vs-a2a-the-complete-guide-to-ai-agent-protocols-in-2026-30li

[33] McKinsey / QuantumBlack, “Seizing the Agentic AI Advantage,” June 2025. https://www.mckinsey.com/capabilities/quantumblack/our-insights/seizing-the-agentic-ai-advantage

[34] Arize, “Why AI Agents Break: Production Failures,” 2025. https://arize.com/blog/common-ai-agent-failures/

[35] Maxim, “AI Hallucinations in 2026,” 2026. https://www.getmaxim.ai/articles/ai-hallucinations-in-2025-causes-impact-and-solutions-for-trustworthy-ai/

[36] OWASP GenAI Security Project, “LLM01:2025 Prompt Injection,” 2025. https://genai.owasp.org/llmrisk/llm01-prompt-injection/

[37] OWASP via HelpNetSecurity, “Prompt Injection AI Security Failures,” June 2026. https://www.helpnetsecurity.com/2026/06/11/owasp-prompt-injection-ai-security-failures/

[38] OWASP, “Top 10 for Agentic Applications 2026,” December 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

[39] OpenAI, “Understanding Prompt Injections: A Frontier Security Challenge,” 2025. https://openai.com/index/prompt-injections/

[40] TechTimes, “Prompt Injection May Be a Permanent Flaw,” June 2026. https://www.techtimes.com/articles/318361/20260614/ai-agent-security-hits-its-reckoning-prompt-injection-may-permanent-flaw-not-patchable-bug.htm

[41] Airia, “AI Security 2026: The Lethal Trifecta,” 2026. https://airia.com/ai-security-in-2026-prompt-injection-the-lethal-trifecta-and-how-to-defend/

[42] Meta AI, “Agents Rule of Two: A Practical Approach to AI Agent Security,” October 2025. https://ai.meta.com/blog/practical-ai-agent-security/

[43] MITRE, “ATLAS: Adversarial Threat Landscape for AI Systems,” 2026. https://atlas.mitre.org/

[44] AI Accelerator Institute, “Benchmark Theater, Explained: AI Test Scores vs Production,” 2026. https://www.aiacceleratorinstitute.com/the-benchmark-gap-explained-what-ai-leaderboards-measure-and-what-they-miss/

[45] Temporal, “AI Reliability,” 2026. https://temporal.io/blog/ai-reliability-is-a-decade-old-problem

[46] Gravitee, “State of AI Agent Security 2026,” 2026. https://www.gravitee.io/state-of-ai-agent-security

[47] McKinsey via AgentMarketCap, “AI Trust Report 2026,” 2026. https://agentmarketcap.ai/blog/2026/04/07/mckinsey-ai-trust-2026-agentic-governance-framework

[48] Kiteworks, “2026 Data Security and Compliance Risk Forecast,” 2026. https://www.kiteworks.com/cybersecurity-risk-management/ai-agent-data-governance-why-organizations-cant-stop-their-own-ai/

[49] California Management Review, “Governing the Agentic Enterprise,” March 2026. https://cmr.berkeley.edu/2026/03/governing-the-agentic-enterprise-a-new-operating-model-for-autonomous-ai-at-scale/

[50] WEF, “AI Agents in Action: Foundations for Evaluation and Governance,” 2025. https://www.weforum.org/publications/ai-agents-in-action-foundations-for-evaluation-and-governance/

[51] Okta, “AI Agents at Work 2026,” 2026. https://www.okta.com/newsroom/articles/ai-agents-at-work-2026-agentic-enterprise-security/

[52] CIO.com / IBM IBV, “CIOs Plagued by Growing AI Accountability Gap,” 2026. https://www.cio.com/article/4183249/cios-plagued-by-a-growing-ai-accountability-gap.html

[53] CoSAI, “Agentic Identity and Access Management,” 2026. https://www.coalitionforsecureai.org/wp-content/uploads/2026/04/agentic-identity-and-access-control.pdf

[54] InfoQ, “Designing Continuous Authorization for Sensitive Cloud Systems,” 2026. https://www.infoq.com/articles/continuous-authorization-cloud/

[55] InfoQ, “AI Agent Identity and Permission Challenges: Uber and Auth0,” June 2026. https://www.infoq.com/news/2026/06/ai-agent-identity-uber-auth0/

[56] I. Sebastian & P. Weil (MIT CISR), “The AI Decision Matrix,” EA Voices, June 2026. https://eavoices.com/2026/06/18/the-ai-decision-matrix/

[57] TechTarget, “Human-in-the-Loop Shouldn’t Rubber-Stamp Decisions,” 2026. https://www.techtarget.com/searchcio/feature/Human-in-the-loop-shouldnt-rubber-stamp-decisions

[58] CIO.com, “Who Authorized the AI Agent? Breaking the Blame Loop,” 2026. https://www.cio.com/article/4184151/who-authorized-the-ai-agent-breaking-the-blame-loop-in-agentic-ai.html

[59] CIO.com, “Architecture-as-Code: The Next Frontier for Enterprise Governance,” 2026. https://www.cio.com/article/4184567/architecture-as-code-is-the-next-frontier-for-enterprise-governance.html

[60] Acceldata, “Agentic AI Data Governance,” 2026. https://www.acceldata.io/blog/enhance-security-and-control-with-agentic-ai-data-governance

[61] CISA + G7, “Software Bill of Materials for AI: Minimum Elements,” May 2026. https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements

[62] SecurePrivacy, “AI Risk & Compliance 2026,” 2026. https://secureprivacy.ai/blog/ai-risk-compliance-2026

[63] “AI Agents Under EU Law,” arXiv, 2026. https://arxiv.org/pdf/2604.04604

[64] Gartner, “Gartner Unveils Top Predictions for IT Organizations and Users in 2026 and Beyond,” October 2025. https://www.gartner.com/en/newsroom/press-releases/2025-10-21-gartner-unveils-top-predictions-for-it-organizations-and-users-in-2026-and-beyond

[65] NIST, “AI Risk Management Framework,” updated March 2025. https://www.nist.gov/itl/ai-risk-management-framework

[66] Cloud Security Alliance, “Agentic AI Governance: NIST Standards,” March 2026. https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/03/governance-nist-ai-agent-standards-agentic-governance-v1-csa-styled.pdf

[67] ISO/IEC, “42001:2023, AI Management System,” December 2023. https://www.iso.org/standard/81230.html

[68] AIUC Consortium, “AIUC-1: AI Agent Standard,” 2025. https://www.aiuc-1.com/

[69] Singapore IMDA, “Model AI Governance Framework for Agentic AI,” January 2026. https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf

[70] Singapore IMDA, “Singapore Launches New Model AI Governance Framework for Agentic AI,” January 2026. https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2026/new-model-ai-governance-framework-for-agentic-ai

[71] Y. Bengio et al., “International AI Safety Report 2026,” arXiv, February 2026. https://arxiv.org/pdf/2602.21012

[72] CIO.com / MIT Technology Review, “AI Found 2,000 Vulnerabilities in 7 Weeks,” 2026. https://www.cio.com/article/4185253/ai-found-2000-vulnerabilities-in-7-weeks-weve-patched-almost-none-of-them.html

[73] CIO.com, “US Reverses Export Restrictions on Anthropic’s Fable 5, Mythos 5 AI Models,” July 2026. https://www.cio.com/article/4191550/us-reverses-export-restrictions-on-anthropics-fable-5-mythos-5-ai-models.html

[74] McKinsey / QuantumBlack, “The Symbiotic Enterprise,” June 2026. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-symbiotic-enterprise

[75] Addepto, “Agentic AI, Token Optimization, and Workflow Redesign in Modern AI Consulting,” 2026. https://addepto.com/blog/agentic-ai-token-optimization-and-workflow-redesign-in-modern-ai-consulting/

[76] EY, “Agentic AI Enterprise Token Cost,” 2026. https://www.ey.com/en_us/insights/ai/agentic-ai-token-costs

[77] CIO.com, “The Hidden Cost of Becoming AI-Ready,” 2026. https://www.cio.com/article/4187968/the-hidden-cost-of-becoming-ai-ready.html

[78] CIO.com, “The AI Adoption Spending Spree Is Over,” 2026. https://www.cio.com/article/4183263/the-ai-adoption-spree-is-over-time-to-focus-on-value.html

[79] CIO.com, “IT Hurtles Toward the Great Enterprise Pricing Reset,” 2026. https://www.cio.com/article/4184688/it-hurtles-toward-the-great-enterprise-pricing-reset.html

[80] CIO.com, “By the Numbers: The AI Inferencing Market,” 2026. https://www.cio.com/article/4181783/by-the-numbers-the-ai-inferencing-market-and-the-infrastructure-decisions-that-define-it.html

[81] Zylos, “AI Agent Cost Optimization,” 2026. https://zylos.ai/research/2026-02-19-ai-agent-cost-optimization-token-economics

[82] Requesty, “AI Agent Cost Optimization: How to Cut LLM Spend with Routing,” 2026. https://www.requesty.ai/blog/ai-agent-cost-optimization-how-to-cut-llm-spend-by-80-percent-with-routing

[83] CIO.com, “Tokenomics in Enterprise AI,” 2026. https://www.cio.com/article/4184596/tokenomics-in-enterprise-ai.html

[84] Finout, “FinOps for the Agentic Era,” 2026. https://www.finout.io/blog/how-finops-must-evolve-for-the-agentic-era-of-ai

[85] FinOps Foundation, “State of FinOps 2026,” 2026. https://data.finops.org/

[86] BCG, “AI Radar 2026: As AI Investments Surge, CEOs Take the Lead,” January 2026. https://www.bcg.com/publications/2026/as-ai-investments-surge-ceos-take-the-lead

[87] Master of Code, “AI Agent Evaluation,” 2026. https://masterofcode.com/blog/ai-agent-evaluation

[88] Digital Applied, “AI Agent Scaling Gap,” March 2026. https://www.digitalapplied.com/blog/ai-agent-scaling-gap-march-2026-pilot-to-production

[89] Deloitte, “Enterprise AI Transformation Predictions 2026,” 2026. https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/blogs/pulse-check-series-latest-ai-developments/ai-transformation-predictions-2026.html

[90] CIO.com, “Why Most Enterprise AI Programs Fail,” 2026. https://www.cio.com/article/4184158/why-most-enterprise-ai-programs-fail-and-how-to-turn-them-around.html

[91] WEF, “Organizational Transformation in the Age of AI,” 2026. https://www.weforum.org/publications/organizational-transformation-in-the-age-of-ai-how-organizations-maximize-ais-potential/

[92] CIO.com, “The Hidden Cost of Enterprise AI: 6.4 Hours a Week Babysitting Bots,” 2026. https://www.cio.com/article/4183804/the-hidden-cost-of-enterprise-ai-6-4-hours-a-week-babysitting-bots.html

[93] CIO.com / Oxford / Davenport, “Your AI Strategy May Be Training Employees to Stop Thinking,” 2026. https://www.cio.com/article/4188178/your-ai-strategy-may-be-training-employees-to-stop-thinking.html

[94] CIO.com, “Preventing Organizational Amnesia in the Age of AI,” 2026. https://www.cio.com/article/4187989/preventing-organizational-amnesia-in-the-age-of-ai.html

[95] CIO.com, “Building ‘Idiot Proof’ Systems Is Not the Answer,” 2026. https://www.cio.com/article/4188202/building-idiot-proof-systems-is-not-the-answer.html

[96] Cloud Security Alliance, “AI Security Maturity Model (AISMM),” May 2026. https://cloudsecurityalliance.org/artifacts/ai-security-maturity-model

#Ai #Ai-Governance #Enterprise-Architecture #Technology-Strategy #Mcp #Security