The Architecture Decision to Make Before Starting Your AI Project

By the end of 2026, Gartner projects that 40% of enterprise applications will embed task-specific AI agents - up from under 5% just twelve months ago.[¹] That is the most aggressive adoption curve Gartner has ever measured across emerging technologies. And yet, in the same breath, Gartner also predicts that more than 40% of those agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls.[²]

Read those two numbers together. The industry is simultaneously sprinting toward AI deployment and heading directly into a wall it can already see coming.

The reason both things are true at once is the same reason they've always been true in enterprise technology: the first question everyone asks is the wrong one. Companies ask "How do we use AI to solve this?" and then work backward from that answer, finding justifications for the model they've already decided to build. Nobody in the dominant incentive chain - not the frontier labs that profit from every token burned, not the fast-moving AI shops that win by shipping quickly, not the platform vendors whose renewal story depends on AI being the headline - nobody is incentivized to ask the harder, earlier question. That question is:

This document maps the full spectrum of AI agent deployment architectures - from systems where the agent handles everything including its own orchestration, to systems where the agent handles only the narrow slice of the problem that nothing else can. Every mode on this spectrum involves an agent. What changes across the spectrum is how much of the system the agent controls, how much autonomy it has to act, and how much deterministic structure has been built around it to contain and constrain that autonomy.

The goal is not to make the case that agents are good or bad. The goal is to give you the analytical framework to decide exactly where an agent belongs in your system, what autonomy it actually needs, and what to build around it so it only does the part nothing else can do.

The Spectrum: Five Agent Deployment Modes

There is a spectrum of agent deployment architectures, and every real system sits somewhere on it. The poles are not hypothetical - they are both in production at scale in 2026, with meaningfully different outcomes. Between them are three real intermediate modes that enterprises actually build. Understanding where each one breaks, and why, is the entire point.

The five modes, from least to most constrained:

1. Fully Autonomous Agent - the agent orchestrates itself and acts directly on systems without human involvement

2. Orchestrated Multi-Agent - multiple specialized agents coordinate through a planner to complete complex tasks

3. Tool-Using Agent with Human Review - the agent reasons and acts through tools, but a human gates every output before it takes effect

4. Deterministic-First Agent - deterministic rules handle the majority of the workflow; the agent is called only when the rules cannot resolve the situation

5. Single-Scope Agent - the agent does one narrowly defined job inside a fully deterministic frame, handing its output to the deterministic system that acts on it

   
   

The critical point about this spectrum: every mode involves an agent. Mode 5 is not "no AI" - it is an agent operating under maximum constraint. The question is never whether to use an agent. The question is how much of your system you are willing to let the agent control, and whether that level of control is actually justified by the problem.

The Four Dimensions That Matter

Most architectural comparisons of AI agent deployment focus on capability - what can the agent do? That is the wrong primary lens for any production system that touches real data, real users, or real business outcomes. The dimensions that matter in practice are:

• Implementation effort - how long and complex is it to build, test, and maintain? This is not just development time; it includes the effort required to make the agent trustworthy, which is a fundamentally different scope for a fully autonomous agent versus a tightly constrained one.

  
  

• Security and blast radius - what is the worst-case failure mode, and how contained is it? In 2026, 88% of enterprises that have deployed agents reported at least one security incident tied to those agents.[³] The architecture determines whether that incident is a nuisance or an existential event.

  
  

• Scalability and predictability - how does the system behave at volume, under stress, or when inputs change in ways nobody anticipated? Scalability for agent systems is not just a compute question; it is a behavioral question. An agent that works 95% of the time is not a scalable system if the 5% failure mode is catastrophic and undetectable.

  
  

• Token cost - what does the system actually cost to run? Enterprise LLM API spend passed $8.4 billion in 2025 and is on track to double again.[⁴] Per-token prices fell roughly 80% between 2025 and 2026 - and enterprise AI bills went up anyway, because volume increased faster than prices fell.[⁵] Agentic AI is the primary driver: a single agentic workflow that appears to the user as one action may trigger 10 to 20 LLM calls under the hood, and the average fully agentic task requires 5 to 30 times more tokens than a constrained inference call.[⁶]

  
  

• A fifth dimension - trust and predictability of output - runs across all four and is arguably more important to business outcomes than any of them individually. An agent whose behavior can be explained, audited, and defended is worth more operationally than a more capable agent that works unpredictably. This is the dimension that almost never appears in capability benchmarks, and it is the one that determines whether the system actually gets used.

  
  

Mode 1: Fully Autonomous Agent

What it is

The agent is both the brain and the hands. It receives a goal, reasons about how to achieve it, selects and executes tools, reviews its own outputs, self-corrects, and proceeds to the next step - without a human in the loop at any decision point. The agent orchestrates itself. In the most common architecture, a single large model (a "planner") is given access to a tool layer - APIs, databases, web access, code execution, file operations - and reasons about what to call and when.

Devin, built by Cognition AI, is the most widely discussed production example: given a software engineering task, it autonomously writes code, runs tests, debugs failures, searches documentation, and commits changes - end to end, without a human approving each step. OpenAI's Operator is another: a browser-native agent that navigates websites, fills forms, completes purchases, and executes multi-step tasks autonomously on a user's behalf. AI SDR agents like 11x and Artisan operate the same way at the sales layer - prospecting, researching leads, drafting and sending outreach emails, and managing follow-up sequences with no human reviewing individual actions before they go out.

The demo is always impressive. The production failure stories are what this document exists to prevent.

Effort

High at build time; extremely high at maintenance time. The initial build often looks straightforward - point a capable model at a tool set and let it run. The problems emerge in production: edge cases multiply, the agent makes reasonable-sounding decisions that turn out to be wrong in consequential ways, and debugging a multi-step autonomous reasoning chain is fundamentally harder than debugging deterministic code. There is no single line to check; the failure can happen anywhere in the agent's internal reasoning process.

Tool design is where most enterprise autonomous agent deployments fail. Poorly scoped tools lead to agents that get stuck, hallucinate capabilities they don't have, or - more dangerously - use real capabilities in ways they weren't intended to be used.

Security

This is the architecture's most serious liability. When an agent holds broad standing access to systems and can take real-world actions autonomously, a single point of compromise has an enormous blast radius. In 2026, 61% of agent security incidents were tied to over-permissioned credentials - agents granted more access than they needed for the task at hand. The secondary risk is prompt injection: 34% of deployed agents were successfully attacked through prompt injection, where malicious instructions embedded in data the agent retrieves cause the agent to take unintended actions.[⁷]

The mechanism is not theoretical. In the Slack AI data exfiltration incident, indirect prompt injection in a private channel caused an AI assistant to summarize sensitive conversations and route them to an external address - while the agent believed it was performing a routine summarization task. In a financial services case in 2025, a reconciliation agent was tricked into exporting an entire customer database because an injected instruction was phrased as a plausible business task.[⁸] OWASP's Q1 2026 Exploit Round-up confirmed that these attack classes - agent goal hijacking, tool misuse, and human-agent trust exploitation - are no longer theoretical. They are in production, in the wild, against real enterprise systems.[⁹]

The EU AI Act, effective August 2026, now requires organizations operating high-risk AI systems to design them for effective human oversight. Fully autonomous agents, by design, are structurally non-compliant with that requirement for any workflow classified as high-risk.[¹⁰]

Scalability

Volatile. Autonomous agents are non-deterministic by nature, which means their behavior under novel inputs is not predictable from observed behavior under familiar inputs. Scaling a non-deterministic system is not the same as scaling a deterministic one: adding load does not just add compute cost, it adds behavioral variance. Fully autonomous agent systems remain experimental in regulated industries as of 2026.[¹¹]

Token cost

The highest of any architecture by a significant margin. A single user-initiated task in a fully autonomous agent system can trigger 10 to 20 LLM calls, each with its own context window. Errors mid-chain are particularly expensive: a failure at step eight of a fifteen-step pipeline means seven inference calls have already been paid for and produced nothing usable. 60% of AI projects exceeded original cost estimates by 30 to 50%, and enterprise token consumption has increased 13 times since January 2025, driven primarily by agentic workloads.[¹²]

When it actually makes sense

Narrow domains where the task is well-defined but the execution path is genuinely unpredictable; where errors are recoverable and low-cost; where the value of speed and autonomy clearly outweighs the risk of uncontrolled action. Software development assistance in sandboxed environments is the most credible current production use case. Customer-facing autonomous agents with broad system access and no human gate are a different matter entirely.

Mode 2: Orchestrated Multi-Agent

What it is

Multiple specialized agents coordinate with each other - a planner agent breaks a task into sub-tasks and delegates them to specialized sub-agents, each of which has a narrower tool set and a more constrained operational scope. The Agent2Agent (A2A) protocol and Model Context Protocol (MCP) have become the standard infrastructure for this coordination layer in 2026.

Perplexity's Deep Research is the most visible consumer example: you watch it spawn parallel sub-tasks, assign them to specialized search and synthesis agents, and produce a structured report. The coordination is visible by design - which also makes its failure modes visible when one sub-agent produces something the orchestrator cannot handle. Gemini Deep Research operates the same way. At the enterprise layer, Salesforce Agentforce is the most deployed multi-agent architecture in production: a planner agent routes customer interactions to specialized sub-agents - one handling billing inquiries, one handling technical support, one handling escalations - each with its own constrained tool access and knowledge scope, coordinated by an orchestration layer running A2A.

The theory is that specialization produces better outcomes. The practice is considerably more complex.

Effort

Very high. Multi-agent systems require building and maintaining not just each agent individually, but the orchestration layer that coordinates them - including failure handling, state management across sessions, and behavior when one agent in a chain produces an unexpected output that breaks the downstream agent's assumptions. Ad hoc multi-agent deployment without orchestration is the primary cause of agent sprawl - and agent sprawl in 2026 is a real enterprise problem, with the share of organizations orchestrating multiple AI agents doubling from 9% to 18% in a single quarter while governance and control mechanisms sat at 36%.[¹³]

Security

Larger attack surface than a single agent, because every agent-to-agent communication channel is a potential injection point. The first malicious MCP server was caught in the wild in 2026: a package called postmark-mcp shipped fifteen clean versions to build legitimacy before quietly adding a single line of exfiltration code.[¹⁴] Every connected resource in a multi-agent system becomes a potential injection point, and the blast radius of a compromised sub-agent can propagate through the entire orchestration chain before a human has visibility into what happened.

Scalability

Theoretically better than a single autonomous agent, because specialization reduces the reasoning burden on any individual model. In practice, scalability is limited by the brittleness of the orchestration layer: failures cascade in ways that are harder to predict and recover from than single-agent failures. The more agents in a chain, the more ways the chain can break.

Token cost

Very high. Every agent-to-agent communication involves token spend. Orchestrator calls to sub-agents, sub-agent responses back to the orchestrator, validation calls, retry calls after failures - the total token footprint of a multi-agent workflow is materially larger than a single-agent workflow completing the same task, even when the individual model calls are smaller.

Mode 3: Tool-Using Agent with Human Review

What it is

A single agent can access tools - search, databases, code execution, APIs - but all outputs are gated behind a human review step before they take effect. The agent can reason, retrieve, and draft; it cannot act unilaterally. A human is always the last gate before anything leaves the system or modifies data.

GitHub Copilot is the most widely used example: it reads your codebase, reasons about context, and suggests completions and edits - but every suggestion requires your explicit acceptance before a single character changes.

Cursor in agent mode goes further, autonomously reading files, running terminal commands, and refactoring across a codebase - but surfaces a diff for human approval before any change is committed.

Anthropic's Cowork operates on the same principle at a broader scope, working across files, apps, and browser tabs to complete multi-step tasks while keeping you in control of what actually gets done.

In the legal domain, Harvey AI researches case law, drafts documents, and reasons across large bodies of legal text - but every output is reviewed and approved by a lawyer before it goes anywhere near a client or a filing.

Nothing ships without a human deciding it should.

Effort

Moderate. The tool layer and prompt architecture still require careful engineering, but the human review gate fundamentally changes the risk profile of what "getting it wrong" means. Errors are caught before they cause downstream consequences, which dramatically reduces the stakes of testing and validation during development.

Security

Substantially better than fully autonomous architectures. The blast radius of any individual error or security incident is bounded by the human review gate. Prompt injection can still affect the agent's outputs, but those outputs cannot take unilateral action on external systems. The attack surface is narrower, and the consequences of exploitation are more contained.

Scalability

Moderate. Human review introduces a throughput constraint - the system can only process as many tasks as reviewers can evaluate. This is a genuine limitation for high-volume use cases, but it is also a feature for high-stakes ones: the throughput ceiling ensures that the pace of agent action never outpaces the human capacity to verify it. For many enterprise workflows, this is the right trade-off.

Token cost

Moderate-to-low. A tool-using agent with review still calls the model once per task, but the structured tool calls and human-gated outputs eliminate the retry loops and cascading failures that inflate token costs in autonomous architectures. The cost profile is predictable in a way that fully autonomous agent costs are not.

Mode 4: Deterministic-First Agent

What it is

Deterministic rules and logic handle the majority of the workflow - routing, classification, rule-based responses, structured data processing, compliance checks. The agent is invoked only when the deterministic system hits something it cannot resolve: an unstructured input that rules cannot parse, a judgment call that requires reading context, an exception that falls outside the rule set. When the agent is called, its output feeds back into the deterministic system or to a human gate - it never acts directly on the world.

This is not a watered-down version of an agent. It is an agent deployed where it actually earns its place.

Zendesk AI is the clearest enterprise example in production at scale: deterministic routing rules handle ticket classification, priority assignment, and queue management for the majority of customer support volume. When a ticket arrives that falls outside the rule set - ambiguous language, complex multi-issue requests, emotionally escalated customers - the agent is invoked to draft a response. That draft goes to a human agent for review before it reaches the customer. The deterministic layer handles volume. The agent handles exceptions.

ServiceNow's Now Assist operates identically: ITSM workflows are fully deterministic for structured requests; the agent is called only when a ticket's content requires genuine language understanding or cross-system reasoning that rules cannot perform.

Intercom's Fin takes the same approach in customer messaging - a deterministic routing and escalation layer handles everything it can, the agent handles the rest, and the human is always available as the fallback the system routes to when neither can resolve it.

Effort

Moderate, front-loaded. The upfront design effort is higher than in a fully autonomous architecture, because you have to actually think through which parts of your workflow are deterministic and which genuinely require an agent. This is not optional effort - it is the work that makes the system trustworthy. The ongoing maintenance burden is substantially lower: deterministic components are debuggable in ways that agent reasoning chains are not, and the agent's scope is narrow enough to test and validate systematically.

Security

Good. The agent's attack surface is limited to the specific exception cases it is designed to handle. Prompt injection can still occur, but its consequences are bounded - the agent's output feeds a deterministic rule or a human gate, so a successfully injected instruction cannot cause the system to take unilateral action. The blast radius is contained by design.

Scalability

High. Deterministic components scale at effectively zero marginal cost. The agent is called only when genuinely needed, which means the token footprint scales with the volume of genuinely complex exceptions, not with total workflow volume. For a system that processes a million tickets where 95% can be resolved by rules and 5% require agent judgment, the cost profile is dramatically different from a system that routes all one million through the agent.

Token cost

Low-to-moderate, and predictable. Because the deterministic core handles high-volume, structured cases that do not require inference, the token bill reflects only the actual work the agent does. This is the architecture that Coinbase used to cut its AI spend nearly in half while token usage continued to grow - not through spend alerts, but through architectural decisions about what actually needed an agent versus a rule.[¹⁵]

Mode 5: Single-Scope Agent

What it is

The agent does one narrowly defined job, called once per trigger, producing a structured output that feeds directly into a deterministic system that acts on it.

No orchestration, no multi-step reasoning loops, no tool use beyond what the single job requires. The agent is asked to do the one thing it is genuinely better at than deterministic code - reading unstructured content, making a classification judgment, extracting structure from chaos - and everything else is handled by the deterministic frame around it.

The key distinction from Mode 4: in Mode 4, the deterministic system routes to the agent as an exception handler. In Mode 5, the agent is a fixed, permanent component of every workflow instance - but its job is so narrowly scoped that it functions more like a specialized function call than an autonomous actor.

Intercom Fin at its most constrained deployment is a clean example: the agent's entire job is to read an incoming customer message and determine whether it can be answered from the defined knowledge base. If yes, it drafts the answer. If no, it routes to a human. Two outputs. One job. The deterministic system manages everything else - routing, escalation, ticketing, SLA tracking.

Harvey and Ironclad in contract review mode operate the same way: the agent's job is to read a contract clause and classify it against a defined rubric - in scope, out of scope, flagged for review. The deterministic workflow system manages what happens next. The agent never touches the workflow.

Glean's workplace search agent does one job per query: retrieve and surface relevant documents from the enterprise corpus. It does not act on what it finds, does not decide what to do with results, and does not initiate follow-on actions. The deterministic application layer handles everything downstream of the retrieval.

This is the architecture the incentive chain around AI is least likely to suggest, because it involves the fewest billable tokens and the smallest possible scope for the agent. It is also the architecture with the best production track record.

Effort

Lowest of any architecture at build time. The agent's job is so narrow and well-defined that testing and validation are tractable. There is a real upfront cost in system design - you have to know exactly what question you are asking the agent, and build the deterministic infrastructure around it - but the implementation of the agent itself is simple by design.

Scalability

Highest of any architecture. Deterministic code at the orchestration layer scales linearly and predictably. The agent's inference step is a single, well-defined function call. There are no multi-step reasoning chains to fail, no tool calls to misfire, no inter-agent communications to corrupt.

Token cost

Lowest. One call, narrow context, structured output. The cost is predictable, modelable before launch, and driven only by the actual volume of triggers that require the agent's specific judgment.

Security

Best of any architecture. The agent receives only the specific input it needs for its narrow job, produces a structured output, and hands off to the deterministic system. Prompt injection is possible but its consequences are limited to that one constrained output, which is validated by the deterministic layer before it affects anything downstream.

The Harness Layer: Why Two Systems at the Same Mode Can Produce Completely Different Outcomes

Choosing a deployment mode is the starting decision, not the final one. Two systems can both be Mode 4 on paper - deterministic-first with an agent handling exceptions - and produce completely different outcomes in production across every dimension that matters: cost, security, scalability, trust, and model independence. The variable that explains that gap is the harness layer.

The agent harness is the non-LLM engineering infrastructure that surrounds the agent - the system layer comprising memory, tool routing, execution control, orchestration logic, observability, and safety constraints that determines what the agent can actually do and touch. A useful shorthand from current architectural practice: Agent = Model + Harness.[¹⁶] The model generates outputs; the harness decides which of those outputs are actually allowed to execute, and under what conditions.

This is not a governance wrapper bolted on after the fact. A mature harness is a full operating environment with several distinct components, each of which directly impacts the dimensions we have been measuring:

• Memory and persistence. A stateless agent that starts fresh on every call has a fundamentally different cost and security profile than one with scoped, persistent memory across sessions. Without memory architecture, agents re-solve the same problems repeatedly at token cost. With it, the system gets smarter and cheaper over time - but only if the memory scope is deliberately constrained. An agent with unbounded memory access has a larger blast radius than one whose memory namespace is scoped to exactly what it needs. HLWGRM OS is a working example: every contact's full history persists permanently, but the AI agents that operate on that data access only what is relevant to the specific job they have been called to do, with PII stripped before anything reaches a language model.

  
  

• Learning loops. A harness can be static - the same rules, the same routing, the same prompts forever - or it can evolve based on measured outcomes. MetaHarness ships Darwin Mode as a core component: the harness mutates its own configuration, tests each change in a sandboxed environment, and keeps only what measurably improves performance. This is not the model learning - the model stays frozen. The harness learns. The distinction matters enormously for auditability: a learning harness that evolves against defined, measurable criteria is governable in a way that an autonomously reasoning agent is not.

  
  

• Model routing intelligence. Most organizations route every task to the same frontier model because the interface does not differentiate. A mature harness routes each task to the cheapest model capable of doing it well, learned from the organization's own evaluation logs. The pricing spread between the cheapest and most expensive production models in 2026 is roughly 4,500 times.[¹⁷] A harness with intelligent routing does not just reduce cost - it makes the entire system model-agnostic, which directly determines vendor independence. A system whose harness abstracts the model layer can swap providers without rebuilding anything. A system without that abstraction is coupled to whoever it started with, at whatever price that vendor decides to charge.

  
  

• Identity, provenance, and audit trails. A harness with witness-signed releases, per-agent identity infrastructure, and end-to-end tracing of every model call produces a system whose outputs are defensible when something goes wrong. Without it, debugging a failure in a multi-step agentic workflow means reconstructing what happened from logs that were never designed to answer that question. In regulated industries and under EU AI Act requirements effective August 2026, provenance is moving from a nice-to-have to a compliance requirement.[¹⁸]

  
  

• Evaluation and observability. A harness that continuously measures whether the agent is actually performing - tracking output quality, catching prompt drift before users notice it, monitoring cost per task against defined budgets - is what separates systems that stay on the spectrum from ones that drift toward autonomy over time without anyone noticing. Most 2026 AI cost programs stopped at dashboard-level visibility and reported overruns more precisely without fixing them. The harness is where the fix actually lives.

  
  

• Execution control and blast radius containment. Default-deny tool access, scoped permissions, ephemeral execution environments, capability tokens - these are harness-layer properties that directly determine how far a failure or a successful attack can propagate. Two Mode 1 systems with identical model capabilities have completely different blast radii depending on whether the harness enforces least-privilege access or grants broad standing credentials. The Autonomous Action Runtime Management specification (AARM), published by the Cloud Security Alliance in February 2026, formalizes exactly this control plane - defining a vendor-neutral standard that requires every agent-initiated action to be intercepted, evaluated against policy and stated intent, and recorded with a tamper-evident receipt before execution. AARM's five authorization decisions - ALLOW, DENY, MODIFY, STEP_UP, and DEFER - are the formal expression of what a mature execution control layer looks like at the harness level.[³³] Disclosure: the author is a member of the AARM Technical Working Group.

The practical implication is that the deployment mode spectrum and the harness layer are not independent variables. The harness layer is what determines where a system actually lands on every dimension we have described - not where it was designed to land. A Mode 4 system with no harness to speak of will drift toward the cost, security, and reliability profile of Mode 1 over time, as the system grows, new developers touch it, and the original architectural intent erodes. A Mode 2 system with a mature harness - scoped memory, intelligent routing, human review gates, continuous evaluation - can be made meaningfully safer and cheaper than a Mode 3 system without one.

This is also why the harness concept operates at multiple layers simultaneously. MetaHarness enforces architectural decisions in code - it is a factory for producing agent harnesses that ship with default-deny MCP, scoped memory namespaces, model routing intelligence, governance policy, and witness-signed provenance baked in before a line of application code is written. HLWGRM OS enforces the same discipline at the GTM layer - a purpose-built system where agents execute against rules Rory has defined, every external action requires a human send with no configuration path around it, and PII never reaches a language model after it has served its purpose. Different implementations, same discipline: the harness holds the architectural intent in place so it does not erode under the pressure of a growing system and changing teams.

The harness is not optional infrastructure. It is what makes the deployment mode you chose at design time the deployment mode you actually have in production six months later.

The Token Bill Nobody Modeled

Average inference spend now represents 85% of enterprise AI budgets, and 60% of AI projects exceed original cost estimates by 30 to 50%.[¹⁹] Token prices fell roughly 80% between 2025 and 2026. Enterprise AI bills went up anyway.

Token prices have fallen 280 times over two years, but total enterprise AI spend has risen 320% in the same period.[²⁰] The driver is volume - specifically the shift to agentic AI workflows that trigger 10 to 20 LLM calls per user task, RAG architectures that inflate context windows three to five times, and always-on monitoring agents that consume compute 24 hours a day.

The FinOps Foundation is documenting cases where enterprises are running three times over their 2026 token allocations.[²¹] The explanation is not complexity. It is arithmetic. When tokens are cheap, teams stop treating them as a resource with economic value. Prompts grow bloated. Context windows fill with irrelevant history. Agentic workflows trigger cascading calls without any model of the total token cost of a task.

The cheapest production LLM models in 2026 cost around $0.04 per million tokens. The most expensive frontier reasoning models cost upward of $180 per million tokens - a 4,500 times pricing spread.[²²] Most organizations route tasks to frontier models by default because the interface does not differentiate, when the same result could be achieved at a fraction of the cost.

The architecture is the fix. Not alerting, not dashboards, not FinOps programs. The only lever that actually bends the cost curve is deciding, at design time, which tasks need an agent and which tasks do not.

The Attack Surface You Built on Purpose

Among enterprises that have deployed agents, 88% reported at least one security incident tied to those agents.[²³] Most failures trace back to two root causes: agents granted more access than they need, and agents acting on data they should never have touched. The 61% tied to over-permissioned credentials confirms what identity teams feared: when an agent holds broad standing access and gets hijacked, the blast radius is enormous. The 34% prompt-injection rate shows that the most basic agentic attack - feeding the agent malicious instructions through data it processes - lands on one in three deployed agents.

The AI security landscape demonstrates a clear transition from theoretical risks to real-world exploitation, with attackers increasingly targeting agent identities, orchestration layers, and supply chains rather than just model outputs.[²⁴] Incidents reveal that AI is now a force multiplier for cyberattacks, while misconfigured permissions, excessive autonomy, and weak validation controls enable data exfiltration, remote code execution, and cascading failures. The AARM specification formalizes eleven threat classes that any conformant runtime control plane must address - including prompt injection (T1), confused deputy attacks (T2), data exfiltration (T3), goal hijacking (T4), memory poisoning (T5), intent drift (T6), cross-agent propagation (T7), over-privileged credentials (T8), and malicious tool output (T11).[³³] The taxonomy is worth internalizing: it maps the attack surface of every mode on this spectrum, and the threat classes that are unaddressable without a harness - T6 intent drift, T7 cross-agent propagation, T8 over-privilege - are precisely the ones that most production deployments currently have no control for.

The mechanism behind most of these incidents is structural, not incidental. An attacker cannot access a sensitive financial database directly due to firewall rules. However, a customer support agent has API credentials to check billing status. By injecting instructions via a support ticket, the attacker coerces the agent into retrieving not just their own record, but the entire customer table. The agent has the privilege, so the network layer approves the request. The security failure occurs not at the network level, but in the semantic layer - the agent's understanding of what it should retrieve.[²⁵]

This is not a bug that can be patched. It is an architectural property of systems where the agent has broad access and makes autonomous decisions. The only structural fix is narrowing the agent's access to what it actually needs for its specific, bounded job.

Attackers spent the past year learning that the easiest way to compromise an agent is to poison something the agent trusts.[²⁶] Every connected resource in an agentic system is a potential injection point - a fact that becomes exponentially more consequential as the agent's tool access and autonomous action capabilities expand.

Why Most Agentic Projects Fail Before They Scale

Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls.[²] RAND Corporation research confirms that AI projects fail at twice the rate of traditional IT projects, with over 80% never reaching meaningful production use.[²⁷]

The core problem lies in poor governance, undefined business value, and insufficient operational discipline. As agents gain autonomy to act, companies face a "capability-deployment verification gap," where successful pilots falter in production due to neglected integration, data access, and accountability.[²⁸]

Agentic systems require more robust data governance because they act on data autonomously. More complex integration architecture because a single user query can trigger dozens of internal agent calls. More demanding change management because the workflows they automate are often more central to operations.[²⁹]

Enterprises that invest early in bounded autonomy - including clear limits, escalation paths, and accountability - deploy agents into higher-value workflows sooner and more safely. Organizations investing in unified AI governance frameworks put more than an order of magnitude more AI projects into production compared to those without governance structures.[³⁰]

The emerging compliance baseline is taking shape around two parallel tracks. The EU AI Act Article 14 establishes the human oversight requirement at the regulatory layer.[¹⁰] AARM establishes the runtime control standard at the technical layer - defining what "effective human oversight" actually looks like in a deployed agent system, with published conformance levels that give organizations a testable benchmark rather than a regulatory interpretation to argue about.[³³]

The specification is actively evolving, with a second version in development that strengthens the core tier and broadens the threat model. Together they represent the direction governance is moving: not away from agents, but toward agents that can be audited, interrupted, and held accountable at every action they take.

The constraint is not the obstacle. It is the mechanism.

Who Controls Your AI Controls Your Business

AI vendor lock-in is the dependency an organization creates when its workflows, agents, and integrations are built around a single AI model or provider. If that vendor is restricted, sanctioned, or repriced, the organization has no practical way to route around it. Single-vendor AI dependency is a systemic risk because the disruption is not limited to one team or workflow - it can halt every process built on that vendor at once.[³¹]

In 2026, this risk became concrete rather than theoretical. The US issued an export-control directive that suspended access to Anthropic's two most capable models for any foreign national, inside or outside the United States. Anthropic disabled both models for everyone, while its other models stayed available. Nineteen days later access was restored, after negotiations with the Commerce Department.[³²] A frontier model was switched off overnight by government action, and switched back only on terms the affected organizations had no part in negotiating.

The architecture is the hedge. Systems built on the deterministic-first model are model-agnostic by design: the agent's inference call is a single, well-defined function that can be pointed at any model capable of doing the specific, narrow job. Swapping providers is a configuration change, not a rebuild. Systems built around autonomous agents that depend on a specific model's reasoning patterns, tool-use behaviors, and prompt responses are the opposite: deeply coupled to a vendor whose availability, pricing, and regulatory status are outside anyone's control.

The Design Principle Behind All Five Modes

The practical implication of everything above is a design principle, not a technology preference: build the deterministic structure first, then let the agent earn its place in the gaps the structure cannot fill.

This means starting every agent project with an inventory of the problem, not an assumption about the solution. Which parts of this workflow are actually rule-followable? Which parts require judgment that no rule can capture? Which parts involve unstructured data that code cannot read? The answers to those questions, not the capability benchmarks of available models, should drive the architecture - and the mode selection.

An agent doing one narrowly scoped job inside a fully deterministic frame is not a lesser version of an autonomous agent. It is a more honest answer to the question of where the agent actually earns its place. The chaos is different across every problem domain. The instinct is identical: find the boundary where rules stop working and agent judgment starts, build the deterministic structure up to that boundary, and only let the agent in past it.

In 2026, the evidence that this instinct is correct is no longer theoretical. The enterprises that are scaling successfully with agents are not the ones that gave them the most autonomy. They are the ones that gave them exactly as much autonomy as the problem actually required.

Choosing the Right Mode for Your System

No single position on the spectrum is correct for all problems. The right architecture depends on the specific workflow, the specific risk tolerance, the specific cost constraints, and the specific data environment. But there are some questions that reliably surface the right answer:

• Is the failure mode recoverable? If the agent produces a wrong output, what happens? If the answer is "a human catches it before anything happens," that supports Mode 3 or better. If the answer is "a customer receives incorrect information," "a record gets modified incorrectly," or "a transaction executes," the system needs a human gate or a deterministic validator before any agent output touches a real system.

  
  

• What fraction of your workflow actually needs an agent? If 90% of your inputs can be handled by rules - because they are structured, because the logic is well-defined, because the answer can be looked up - then routing all of them through an agent is not a choice, it is a tax. Mode 4 or Mode 5 is not a compromise; it is the correct answer to what the workflow actually requires.

  
  

• Can you explain why the agent made the decision it made? Autonomous agents operating through multi-step reasoning chains are fundamentally difficult to audit. Deterministic-first systems with a constrained agent component are auditable at every step. As EU AI Act requirements take effect and regulatory scrutiny of high-risk AI systems increases, explainability is moving from a nice-to-have to a compliance requirement.

  
  

• What does vendor switching actually cost you? If you cannot describe how you would move your system to a different model provider without rebuilding it, you have a vendor lock-in problem, not a technology strategy. The architecture should make the agent's model swappable, because the model landscape in 2026 is changing fast enough that last year's best model is not necessarily this year's, and this year's available model may not be next year's either.

  
  

The Incentive Bias Behind Poor AI Architecture

None of the architecture choices above are technically difficult to understand. The reason most deployments still trend toward the autonomous end of the spectrum is not because autonomous agents are better - the data is fairly clear that they are not, in most production environments. It is because of who profits from which choice.

Frontier labs profit from more tokens burned, regardless of whether the task needed an agent. Fast-moving AI shops profit from shipping "point an agent at the problem" solutions quickly, because that ships faster than figuring out what actually needs an agent versus a rule. Platform vendors profit from AI being the headline that sells this year's renewal. Nobody in that chain is incentivized to hand you the harder, earlier question.

The harder, earlier question has to come from someone outside that chain entirely.

That is what HLWGRM builds: the discipline of asking where an agent belongs before assuming it does, and constructing the deterministic structure around it that makes the agent trustworthy. Not because constraint is the goal, but because constraint is what makes the system safe to scale - and safety to scale is what determines whether the investment actually earns its return.

Footnotes

[¹] Gartner, CIO and Technology Executive Survey 2026; Hype Cycle for Agentic AI 2026 (April 2026)

[²] Gartner, agentic AI project cancellation prediction (June 2025, widely reported through July 2026)

[³] Shattered.io, Agentic AI Security 2026 (June 2026)

[⁴] NeuralTrust, AI Token Optimization Guide (2026); The Deployment Layer, The Token Economy (June 2026)

[⁵] The Deployment Layer, The Token Economy (June 2026)

[⁶] Gartner, AI Inference Cost Crisis Analysis (March 2026); Oplexa, AI Inference Cost Crisis 2026 (March 2026)

[⁷] Shattered.io, Agentic AI Security 2026 (June 2026); Darktrace, agentic AI security report (2026)

[⁸] Stellar Cyber, Top Agentic AI Security Threats (March 2026)

[⁹] OWASP Gen AI Security Project, Exploit Round-up Report Q1 2026 (April 2026)

[¹⁰] EU AI Act, Article 14 (effective August 2026)

[¹¹] Techment, 5 Best AI Architectures for Enterprises Explained (2026)

[¹²] NeuralTrust, AI Token Optimization Guide (2026); Elvex, AI Token Cost Enterprise (May 2026)

[¹³] PointFive, Why Companies Overspend on AI (July 2026)

[¹⁴] Help Net Security, prompt injection and agentic AI failure analysis (June 2026)

[¹⁵] Brian Armstrong, Coinbase CEO statement on AI spend management (June 2026); The Source Code, Token Costs Are Breaking Enterprise AI Business Cases (July 2026)

[¹⁶] Boringbot, AI Agent Harnesses Explained (May 2026); arxiv: Architectural Design Decisions in AI Agent Harnesses (2026)

[¹⁷] Elvex, AI Token Cost Enterprise (May 2026)

[¹⁸] EU AI Act, Article 14 (effective August 2026); Aon, AI Risk 2026: Practical Agenda (2026)

[¹⁹] NeuralTrust, AI Token Optimization Guide (2026)

[²⁰] Oplexa, AI Inference Cost Crisis 2026 (March 2026)

[²¹] The Deployment Layer, The Token Economy (June 2026)

[²²] Elvex, AI Token Cost Enterprise (May 2026)

[²³] Shattered.io, Agentic AI Security 2026 (June 2026)

[²⁴] OWASP Gen AI Security Project, Exploit Round-up Report Q1 2026 (April 2026)

[²⁵] Stellar Cyber, Top Agentic AI Security Threats (March 2026)

[²⁶] Help Net Security, prompt injection and agentic AI failure analysis (June 2026)

[²⁷] RAND Corporation, AI project failure rate research (referenced across multiple 2026 assessments); Growth Acceleration Partners, Why Agentic AI Projects Fail Before They Make It to Production (June 2026)

[²⁸] Forbes / Gartner, Why 40% of Agentic AI Projects May Be Canceled By 2027 (July 2026)

[²⁹] SoftwareSeni, Why 88-95% of Enterprise AI Pilots Never Reach Production (March 2026)

[³⁰] Zen van Riel, Why 78% of AI Agent Pilots Never Reach Production (July 2026)

[³¹] AvePoint, Multi-Model AI Strategy 2026 (July 2026)

[³²] Kai Waehner, Trusted Agentic AI Landscape Q3 2026 (August 2026)

[³³] Errico, H. (2026). Autonomous Action Runtime Management (AARM): A System Specification for Securing AI-Driven Actions at Runtime. Cloud Security Alliance Technical Working Group Specification, February 2026. arXiv:2602.09433. https://aarm.dev/spec. A subsequent version of the specification is in development.