AI Agent Architecture: Two Stacks, Not Five Layers

AI agent architecture is the set of components around a language model that let it take input, hold state, turn a goal into steps, call tools, and check its own work. Almost every published version of it stops there. That omission is the subject of this article.

Our position at LeapForce is that a five-layer stack describes an agent that is capable and says nothing about whether it is permitted. The layer deciding whether an action may happen at all — identity, authorization, approval, budget, record — is architecture, not compliance decoration bolted on after the demo works.

Someone asked the right question on Hacker News on 8 July 2026. A developer posting as Eapz_06 wrote that "our agent neeeds to interact with real production database", then asked what architecture, what guardrails, and what problems people hit past the prototype stage. No answer built only from perception, memory, planning, tools and reflection reaches that question.

The short answer: design AI agent architecture as two stacks, not one — a capability stack (perception, memory, planning, tool use, reflection) and an authority stack (identity, authorization, approval, budget, record) — and refuse to connect any tool whose authority row you cannot fill in.

Last updated: July 30, 2026.

The two stacks. Most agent architecture diagrams draw only the left column.

One disclosure first: we have not built and benchmarked these architectures ourselves, so every performance number below belongs to a named third party and is linked. Our only first-hand data is the framework version table in the frameworks section, pulled from PyPI and npm on 30 July 2026.

What AI agent architecture actually means

AI agent architecture is the arrangement of components that turns a language model into something able to pursue a goal over several steps and change the state of an outside system. It covers how input arrives, what the agent remembers, how it sequences work, which tools it invokes, how it detects errors, and who authorised any of it. Each is a decision with a failure mode attached.

The vocabulary predates the current wave. Russell and Norvig define an agent as "anything that can be viewed as perceiving its environment through sensors and acting upon that environment through effectors". Swap sensors for API responses and effectors for tool calls and the definition holds. What changed is that the reasoning component became a general-purpose model you did not write, which moved the engineering out of the reasoner and into everything around it.

The most useful modern distinction is Anthropic's. Its engineering note on building effective agents separates workflows, "systems where LLMs and tools are orchestrated through predefined code paths", from agents, "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks". Write the order of the steps and you built a workflow. Let the model pick it at runtime and you built an agent, which owes the system a different class of control.

That last row is why agent architecture is a discipline rather than a diagram. A bad answer costs a reader a minute; a wrong action costs a corrected ledger. On a separate Hacker News thread about productionising agents, a practitioner posting as chirdeeps put it well: "the constraint shifts from intelligence to reliability the moment agents start modifying shared systems".

Most teams are meeting that shift now. McKinsey's state of AI survey, published 5 November 2025, found 23 percent of respondents scaling an agentic AI system somewhere in their enterprise and 39 percent experimenting, while "in any given business function, no more than 10 percent of respondents say their organizations are scaling AI agents". Plenty of first agents. Very few second ones.

What AI agent architecture is not

Four things get called agent architecture and are not. Mistaking any of them for the architecture is how teams end up debugging a personality when they have a permissions problem.

It is not the model. Model choice moves accuracy, latency and cost, not what happens when a tool call succeeds against the wrong record.

It is not the prompt. A system prompt is a request, not a control. In Defeating Prompt Injections by Design, submitted March 2025, Debenedetti and colleagues argue that injection must be handled by construction rather than instruction. Their system, CaMeL, splits a privileged model that sees the trusted query from a quarantined model that handles untrusted data, extracts control flow and data flow explicitly, and enforces capability-based restrictions in a custom Python interpreter so untrusted content cannot influence which code path runs. They report provable security on 77 percent of AgentDojo tasks against 84 percent utility undefended. The design claim matters more than the number: the enforcement point sits outside the model.

It is not the framework. Frameworks give you the loop, the retry, the checkpointer and the tracing hooks. They do not decide which action classes need a human. Anthropic's advice is blunt for a vendor: developers should "start by using LLM APIs directly: many patterns can be implemented in a few lines of code", and frameworks "can also make it tempting to add complexity when a simpler setup would suffice".

It is not an org chart. Naming one component "the Researcher" and another "the Critic" is a prompt-authoring convention. It says nothing about what either may touch, and it quietly multiplies the parts of the architecture that do cost you something.

The capability stack: the five layers every agent has

Perception, memory, planning, tool use, reflection. Every published account of AI agent architecture covers this part, and we call it the capability stack. It is a useful decomposition because each layer is a decision rather than a given, and each has a documented way of going wrong. What it cannot tell you is whether the resulting action should be permitted. This is the necessary half of the picture.

Perception and the input layer: everything the agent reads is a potential instruction

The input layer decides what counts as an instruction. In a chat agent that is the user's message. In anything connected to a mailbox, a ticket queue or a document store it is also every byte of retrieved content, and the model has no reliable way to tell your instruction from text that merely looks like one.

So the design question is not "how do I word the system prompt more firmly" but "which inputs are trusted, which are quarantined, and what may a quarantined input cause". A cheap version of CaMeL's answer is available to any team: classify every source at ingestion, and forbid untrusted sources from selecting which tool runs. The common shortcut, concatenating everything into one context window and hoping, is not a perception layer. It is the absence of one.

Memory: what carries across turns, sessions and runs

Memory decides what survives, and there is a real hierarchy to it. The clearest early statement is MemGPT by Packer and colleagues, October 2023, which borrowed operating-system virtual memory to split a main context, the model's context window, from an external context outside it, moving data between the two to create "the appearance of large memory resources through data movement between fast and slow memory".

In practice most agent memory architecture reduces to four questions:

• Working memory. What is in the context window on this call, and what gets evicted when it fills?
• Episodic memory. What does it recall about previous runs of the same task, and for how long?
• Retrieval. What can it fetch on demand, from where, under whose access rights? A retrieval-augmented agent is only as bounded as the index it is pointed at.
• Write-back. What may it add to memory, and can that written memory later be read as instruction?

The fourth question gets skipped, and it is where memory stops being a capability question and becomes an authority question. If the agent writes to a store it later reads as instruction, an attacker who influences one run has influenced every run after it. Retrieval inherits an access-control problem too: an agent retrieving on a user's behalf must retrieve only what that user could have read.

The planning module: turning a goal into an ordered set of steps

Planning decides how a goal becomes steps. The dominant pattern is still ReAct by Yao and colleagues, October 2022, which interleaves reasoning traces with actions so that "reasoning traces help the model induce, track, and update action plans as well as handle exceptions, while actions allow it to interface with external sources". On ALFWorld and WebShop the paper reports absolute success-rate gains of 34 and 10 points over imitation and reinforcement learning baselines.

Plan-then-execute is the alternative shape: produce the whole plan first, then run it. That gives a human something to review before anything happens, which is worth a great deal when actions are irreversible, and it breaks the moment reality diverges from the plan.

Treating the plan as a contract is the trap in this layer. A plan is the model's current intention, revised on the next observation, so any control attached to the plan rather than to the action is one the agent can plan its way around. This is why the authority stack hangs off the tool boundary, not off the planner.

The tool layer: the only place an agent changes the world

Tool use matters most and gets the least design attention. Everything else in an agent produces text. This layer produces consequences.

OWASP's LLM Top 10 names the resulting risk Excessive Agency and breaks it into three root causes worth memorising, because real incidents map to one of them. From the LLM06 entry: excessive functionality, where the agent reaches tools beyond its task; excessive permissions, where those tools hold broader privileges than the task needs; and excessive autonomy, where high-impact actions proceed with no verification or approval. None of the three is a model defect. Each is an architecture decision someone made or failed to make.

Two unglamorous rules follow. Prefer many narrow tools over one general one: post_credit_note(invoice_id, amount) is auditable and boundable in a way run_sql(query) never will be. And separate read tools from write tools cleanly enough to grant one without the other, because much useful agent work needs no write access.

The obvious objection is budget. Most teams cannot get five new endpoints built on a system of record just because an agent would like them, and the honest fallback is not to skip the boundary but to move it. Point the agent at a read-only replica for everything it needs to know, and let it produce a proposed write that a person executes in the existing interface. That is slower and it is a real downgrade in automation, but it keeps the authority question answerable while the endpoints get scheduled. An agent with a broad write credential because narrow ones were too expensive has not saved the money, it has moved the cost to whoever handles the first incident.

The reflection loop: how the agent notices it was wrong

Reflection is the feedback loop that lets an agent detect its own failure and retry differently. The reference work is Reflexion by Shinn and colleagues, March 2023, which has agents "verbally reflect on task feedback signals" and hold that reflection in an episodic memory buffer, reporting 91 percent pass@1 on HumanEval.

It is also the layer where over-claiming is easiest. The largest empirical study of multi-agent failures to date is Why Do Multi-Agent LLM Systems Fail? by Cemri and colleagues at Berkeley and collaborators, first posted March 2025 and revised October 2025. It rests on 1,600-plus annotated traces across seven frameworks, with the taxonomy itself developed from 150 of them at an inter-annotator agreement of kappa 0.88. That taxonomy has 14 failure modes in three categories, and the October revision puts 21.3 percent of failures in task verification: premature termination at 6.2 percent, no or incomplete verification at 8.2 percent, and incorrect verification at 9.1 percent. Mode-level rates and category shares are computed on different bases, so they do not sum. An agent that checks its own work and gets the check wrong is worse than one that never checks, because it reports confidence it has not earned.

So the conclusion is narrow. Self-reflection is a quality mechanism, not a safety mechanism, and it cannot be what stands between the agent and an irreversible action.

The authority stack: five controls the capability layers cannot supply

The authority stack answers a different question: not can the agent do this but may it. Five controls carry that load and none can live inside the model: identity, authorization, approval, budget, record. None of the five appears on a standard AI agent architecture diagram, and none is optional once the agent can write to a system other people depend on.

The clearest external statement of the gap comes from Gartner. In a press release dated 26 May 2026, Gartner argues that applying uniform governance to all AI agents regardless of autonomy level causes failure, and locates the root cause precisely: failure is most likely when organisations do not "distinguish between an agent's ability to act and the scope of access it is granted". It predicts that by 2027, 40 percent of enterprises will demote or decommission autonomous AI agents over governance gaps found only after a production incident. Ability to act is the capability stack. Scope of access is the authority stack. Conflating them is the named failure.

A short talk on the same separation in zero-trust terms, from IBM Technology, February 2026:

A. Identity: the agent is a principal, or it is a shared secret

Every agent action runs as somebody. If you did not decide who, the answer is whichever service account the prototype borrowed, and you now have an actor with no owner, no scope and no expiry. The fix is a first-class non-human identity with a named human owner, minimum scopes and an expiry date, which we covered in our earlier analysis of owner, scope and expiry for AI agents. It makes every later control possible: you cannot authorize, budget or audit an actor you cannot name.

OWASP's Top 10 for Agentic Applications, released in December 2025 with more than 100 contributors, names Identity and Privilege Abuse among its risks alongside Agent Behavior Hijacking and Tool Misuse and Exploitation. Rock Lambrose, CEO and founder of RockCyber, framed the shift in that release as moving from single-model interactions to "what happens when those models can plan, persist, and delegate across tools and systems".

B. Authorization: decided outside the model, on the live request

Authorization is the control most often implemented as a sentence in a prompt. OWASP's mitigation list for Excessive Agency is unambiguous about where it belongs: "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed." Read that as an architecture instruction. The allow/deny decision is a function of identity, scope and target, evaluated in the request path, returning the same answer whether or not the model asked politely.

Protocol plumbing is converging on the same discipline. The Model Context Protocol authorization specification requires MCP servers to "validate that access tokens were issued specifically for them as the intended audience", states they "MUST NOT accept or transit any other tokens", and forbids a server calling an upstream API from passing "through the token it received from the MCP client". Rules any competent API gateway has enforced for a decade, restated because agent plumbing kept breaking them.

That specification has since moved. On 28 July 2026 the MCP maintainers shipped a revision whose headline change is a stateless protocol core. The initialize handshake and the Mcp-Session-Id header were retired. Requests now carry Mcp-Method and Mcp-Name headers, so your "gateway, rate limiter, or WAF can route and meter on those headers instead of parsing JSON bodies". Dynamic Client Registration gave way to client metadata documents, and Roots, Sampling and Logging were deprecated with at least twelve months of continued support. If you wired agents to tools over MCP last year, your authorization assumptions have a version number and it moved this week. To be exact about what we checked: the audience-binding and token-passthrough rules quoted above are from the 2025-06-18 specification, which we fetched and verified. We have not audited the authorization section of the 2026-07-28 revision, so if you are adopting it, read that section yourself rather than assuming the older rules carried over unchanged. Our analysis of MCP server security covers the connector side.

C. Approval: which action classes stop for a named human

Approval converts an autonomous agent into a supervised one for a subset of actions. Done well it is narrow and boring: a list of action classes that pause, a named role that can release them, a record of who released what.

Frameworks support this directly. LangGraph's interrupt() "pauses graph execution and returns a value to the caller", saves state through a checkpointer, and resumes with Command(resume=...). The documented patterns are approve-or-reject, review-and-edit-state, and interrupting inside a tool function to edit its arguments before it runs. Note the architectural requirement: a durable checkpointer, because a run that pauses on Friday for a signature has to resume on Monday with its context intact. Approval is therefore a state management problem before it is a policy one, which is why teams that bolt it on late end up rewriting the runtime.

Gartner's warning here is worth quoting to anyone who thinks approval alone suffices. Describing its Level 3, "act with approval", Senior Director Analyst Shiva Varma says "human review is effective only if it remains a meaningful control", and that without security testing, approval workflows with audit trails and agent-specific incident response, "approvals can degrade under time pressure or approval fatigue, creating a false sense of safety". An approval queue nobody reads is worse than none, because it launders the decision.

D. Budget: a stop that triggers on spend, not on judgement

Budget stops a loop for reasons unrelated to whether the loop thinks it is doing well. Anthropic's write-up of its multi-agent research system reports that "agents typically use about 4× more tokens than chat interactions" and "multi-agent systems use about 15× more tokens than chats", and that in one evaluation "token usage by itself explains 80% of the variance" in performance. A component whose quality scales with spend needs a spend ceiling in its design, denominated in money rather than tokens so a finance owner can reason about it. We covered the routing side in our analysis of how model routing cuts LLM costs.

Two caps, not one: a per-run cap that kills a pathological loop, and a per-agent-per-period cap that catches the slow bleed of a thousand reasonable runs.

E. Record: attempted, refused, and completed

Record makes everything after the incident possible, and the requirement is stronger than logging in two ways. First, it has to reconstruct the action rather than the tokens: which identity, which tool, which arguments, which target, which approver, what it cost. Second, it has to include what was refused. An architecture that records only successful actions cannot answer the question every incident reviewer asks, which is what the agent tried to do and did not manage.

This is where architecture stops being a preference. Article 12 of the EU AI Act requires that high-risk systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system": a system property decided at design time, not a reporting exercise. Our earlier analysis of audit trails for agent actions covers what "reconstructable" has to mean.

Reactive, deliberative, hybrid: what the 1995 taxonomy still decides

The reactive / deliberative / hybrid split that every AI agent architecture explainer repeats is thirty years old and still load-bearing. Wooldridge and Jennings catalogued it in Intelligent Agents: Theory and Practice, Knowledge Engineering Review 10(2), June 1995, with three classes and named exemplars: deliberative architectures including IRMA, HOMER and GRATE\; reactive architectures including Brooks's behaviour languages, PENGI, situated automata and Maes's Agent Network Architecture; and hybrid architectures including PRS, TouringMachines, COSY and InteRRaP. It is a taxonomy of reasoning strategies*, not of products, which is why it maps onto current AI agent design patterns without much strain.

Reactive. Situation maps to action, with no internal world model and no multi-step plan. In modern terms: a classifier that routes, a single tool call, a rules layer in front of a model.

• Best for: high-volume, low-variance tasks where latency matters and the action set is small.
• Costs you: no memory of the last decision; no recovery beyond retry.
• Fails when: the task needs two steps that depend on each other.
• Verdict: underrated. Much of what is labelled "agentic" is a reactive router in a costume, and it is cheaper and more debuggable that way.

Deliberative. The agent builds a plan against an internal representation, then executes it.

• Best for: irreversible or expensive actions, and anything a human must review first.
• Costs you: latency, and brittleness when the world moves between planning and execution.
• Fails when: the environment changes faster than the plan can be rebuilt.
• Verdict: right when the plan itself is the artifact a human approves. A common case, under-served by ReAct-by-default tooling.

Hybrid. Fast paths for the routine, deliberation for the rest, usually in layers.

• Best for: almost everything real, which is why it dominated the 1990s literature and dominates now.
• Costs you: the hardest question in the field, which is which layer wins when two disagree.
• Fails when: arbitration is implicit. Undocumented precedence is how a fast path quietly overrides a safety check.
• Verdict: the default, on condition you write the precedence rules down. If you cannot say which layer wins, you do not have a hybrid architecture, you have two architectures in a trench coat.

None of this is archaeology. IBM's current explainer on agentic architecture still organises types under reactive, deliberative and cognitive headings. What none of the three tells you is who authorised the action, which is no criticism of work written about robots in labs.

One agent or many: the evidence on both sides

Add a second agent only when the work is genuinely parallel, exceeds one context window, or needs tool sets that should not be granted together. Orchestration is a cost you pay in coordination failures, not a capability you get for free. Otherwise a single agent with good context is more reliable and much cheaper. This is the branch that costs the most to reverse later, because agent count is the one AI agent architecture decision that multiplies every other one. The evidence points both ways depending on task shape.

For. Anthropic reports that "a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval", and that such systems "excel at valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools".

Against. Cognition's Walden Yan argued the opposite in Don't Build Multi-Agents on 12 June 2025, from two principles: "Share context, and share full agent traces, not just individual messages", and "Actions carry implicit decisions, and conflicting decisions carry bad results". His recommendation is a single-threaded linear agent with continuous context, plus a separate model compressing long histories into key details, events and decisions.

Measured. MAST splits its 14 failure modes into three categories. The October 2025 revision puts the shares at 41.8 percent system design issues, 36.9 percent inter-agent misalignment and 21.3 percent task verification — figures that moved between editions, so quote the current one. That middle category exists only in multi-agent systems. Its largest mode is reasoning-action mismatch at 13.2 percent, then task derailment at 7.4 percent. The paper is careful about remedies: high reliability "may requires combinatorial changes ranging from agent system organization to model level improvements", and for inter-agent misalignment specifically, "solutions focused on context or communication protocols are often insufficient".

Both camps agree on the mechanism and differ on the remedy. Anthropic itself notes that "some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today". Research is separable. Editing one codebase is not.

So: one agent if the work is sequential, if it needs write access, or if fewer than two people can debug it. Several if the work splits into independent read-heavy investigations that a final step combines, and you can afford roughly fifteen times the tokens of an equivalent chat.

The authority stack changes this calculus in a way the capability-only framing hides. Each extra agent is another identity to own, scope to review, budget to cap and record to correlate. A five-agent system is not five times the reasoning, it is five times the governance surface, plus the delegation edges between them. That cost appears on no token bill.

A worked example: the invoice-exception agent, end to end

This example is constructed for the article. It is not a customer system and no figure in it is measured; it exists so the two stacks of an AI agent architecture can be seen resolving into a concrete design.

The task. Accounts payable receives supplier invoices that fail automatic matching against purchase orders. A human opens each exception, reads the invoice and the PO, decides whether the difference is a legitimate price change, a partial delivery or an error, then posts a credit note, requests a corrected invoice, or escalates. Multi-step, retrieval from two systems, one irreversible write, clear escalation path: valuable, bounded, and reversible everywhere except one place.

Now the capability stack, with each decision made explicit.

That last row is the most common design error in this class of agent. If the check is arithmetic, do the arithmetic in code. A model asked whether its own sum is correct is performing a different task from adding numbers up.

And now the authority stack for the same agent.

One action, five checks. The refusal path is a first-class outcome, not an error.

• Identity. Its own non-human principal, owned by the AP team lead, with an expiry forcing annual re-review. It never borrows a person's credentials, so an employee leaving neither silently breaks it nor silently keeps it alive.
• Authorization. post_credit_note is permitted only against the EU entity, only for suppliers in the agent's segment, only up to a configured ceiling. The check runs in the finance API. Delete the entire prompt and the boundary holds.
• Approval. Credit notes above a threshold pause for a named approver. Requests for corrected invoices do not, being reversible and cheap. Approval is spent where reversal is expensive.
• Budget. A per-run ceiling that kills a loop stuck re-reading the same PDF, and a monthly ceiling so a quiet regression shows up as a stopped agent rather than a surprise line item.
• Record. One entry per attempted action: identity, tool, arguments, target, outcome, approver, cost. Refusals included, which is how you find out the agent tried to credit the wrong entity nine times in March.

The useful output is not the design. It is the two places where filling in the authority rows changed the capability design. run_sql became five narrow tools because it could not be authorized. Planning became plan-then-execute because approval had to precede the write. Authority determined capability, which is this article's argument in miniature.

The Warrant Table: a diagnostic you can run in one sitting

The framework is deliberately small. For every action class your agent can take, write one row with five columns: runs as, may touch, who approves, spend cap, recorded where. We call the result a Warrant Table, and it is the shortest honest audit of an AI agent architecture we know how to describe. The attached rule is the point: no tool ships without a warrant. A cell you cannot fill in is not a documentation gap. It is a live architectural hole with a name.

This is our editorial framework for this article, not a product feature and not a standard. Applied to the invoice-exception agent:

Three notes on running it honestly.

Rows are action classes, not tools. "Post a credit note" splits into two rows because the amounts carry different approval requirements. If a tool needs two warrants depending on its arguments, that is two rows, and often two tools.

"Nobody approves" is a legitimate answer. Requiring approval everywhere is exactly the uniform-governance mistake Gartner describes, where over-restriction of simple agents "slows delivery and drives shadow development". The table exists to isolate the actions that do need a human from the many that do not.

An empty cell is the finding. The columns most likely to go blank are "spend cap", because nobody set one, and "recorded where", because the honest answer is often three systems that disagree.

Gartner's autonomy levels then sanity-check whether the warrant matches the ambition: Observe (read-only, output to the requesting user), Advise (recommendations, humans execute), Act with Approval (executes only after explicit human approval per action), Act Autonomously (executes within guardrails, humans review exceptions and aggregates, on continuous monitoring rather than per-decision review). If your Warrant Table says Level 2 and your roadmap says Level 4, the gap is the work.

What agent frameworks give you, and what they leave to you

Frameworks solve the loop, the state and the retry. They do not solve identity, cross-system authorization, organisation-wide budget or a single audit surface. Those are the parts of an AI agent architecture that belong to your environment rather than to your agent, and they outlive whichever library you picked.

They also move fast, which is itself an architectural fact. Here is what the major Python and JavaScript agent packages published as their current release, pulled from PyPI and npm on 30 July 2026, and the one table here we produced ourselves.

Seven of these ten shipped a release in the fourteen days before we looked, and six inside the last week. Pin versions, and keep your authority controls outside the layer that changes weekly.

What the frameworks do give you:

• Durable pause and resume. LangGraph's interrupt() plus a database-backed checkpointer is a real human-approval primitive, and the docs are explicit that the checkpointer "writes the exact graph state so you can resume later, even when in an error state".
• Input and output validation with a hard stop. The OpenAI Agents SDK returns a GuardrailFunctionOutput with a .tripwire_triggered flag; when it trips, an InputGuardrailTripwireTriggered or OutputGuardrailTripwireTriggered exception halts execution. Read the scope limits: input guardrails run "only for the first agent in the chain", output guardrails "only for the agent that produces the final output", and tool guardrails "do not apply to the handoff call itself". In a multi-agent graph those three sentences are real gaps.
• A standard way to reach tools. MCP gives one protocol instead of ten bespoke integrations, and since the 2026-07-28 revision a header-routable one with OAuth-aligned authorization.

What they leave to you, every time:

• One identity per agent, issued from the system your auditors already trust. No framework mints a principal in your identity provider.
• Authorization that holds across frameworks. Guardrails configured per-agent inside one SDK are a setting, not a policy.
• Budgets in currency, hierarchical, with an owner. Token counters are not budgets.
• One place where every agent action can be reconstructed. Framework tracing is per-application by design.

Frameworks are excellent at the capability stack and structurally unable to own the authority stack, because that stack is shared infrastructure and they are libraries.

How agent architecture meets regulation

Regulation now specifies parts of agent architecture directly, so the authority stack has compliance consequences whether or not you framed it that way. Three instruments matter, none of which asks about your model choice.

The EU AI Act specifies two of the five controls almost by name. Article 12 is the record control as a technical property, quoted earlier. Article 14 requires human overseers to be able to "decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output". It also requires them to be able to "interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state". That is approval and budget as legal obligation, and per the same source those provisions enter into force on 2 August 2026. The article also names automation bias, requiring overseers to "remain aware of the possible tendency of automatically relying or over-relying on the output" — the legal form of Gartner's approval-fatigue warning. Our guide to EU AI Act compliance for deployers covers deployer obligations.

NIST gives the vocabulary for the rest. The AI Risk Management Framework, released 26 January 2023, rests on four functions, Govern, Map, Measure and Manage, extended by the Generative AI Profile (NIST AI 600-1) on 26 July 2024. Voluntary, and not an architecture, but the language enterprise risk teams will use to ask you about one.

The security frameworks converge on the same controls. OWASP's Excessive Agency mitigations read as an authority stack in list form. Minimise the extensions an agent may call, and the functions inside each. Avoid open-ended extensions. Cut downstream permissions to the task, and track user authorization so actions execute in that user's context. Use human-in-the-loop control for high-impact actions. Then implement authorization downstream rather than in the model.

LeapForce's own compliance framing names the EU AI Act, ISO/IEC 42001, the NIST AI RMF and SOC 2 as the reference set our platform is built with in mind. We claim no certification against any of them here, and you should not accept such a claim from any vendor without the report.

Where this analysis is uncertain

Several things above are weaker than the confident register suggests. Better to say which.

We have not benchmarked these architectures ourselves. There is no LeapForce test rig behind this piece, and no AI agent architecture described above was built and measured by us. The only first-hand data is the version table, collected on 30 July 2026 from public registries, which is a snapshot and not an experiment. Every performance number belongs to Anthropic, Berkeley, Google DeepMind or the authors named at each claim.

Gartner and McKinsey figures are surveys and predictions. Both 40 percent figures are analyst forecasts rather than observations, and Gartner's June 2025 release notes that its January 2025 investment numbers came from a poll of 3,412 webinar attendees, a self-selected audience. Treat them as directional.

The MAST distributions may not transfer. Those percentages come from traces across seven frameworks on research-style benchmarks. Whether 36.9 percent of failures would be inter-agent misalignment in an accounts-payable system is unknown, and the paper does not claim it. The category shares also shifted between the March and October 2025 editions, which is a reason to treat them as a picture of a moving field rather than a constant. CaMeL's 77 percent is likewise measured on AgentDojo with a custom interpreter, not in production with your tools; we cite it as a design argument about where enforcement belongs, not as a recommendation.

One source a reader would expect is only partly cited. OWASP's full Top 10 for Agentic Applications sits behind a document download we did not retrieve, so this article names only the three risks listed in the December 2025 announcement. If you are building against that framework, download the document rather than trusting a summary, including this one.

The Warrant Table is untested as a formal method. It is a checklist with no empirical validation, and it would not survive contact with a regulator as evidence of anything. Its only claim is that an empty cell is informative. The three-way taxonomy is likewise a lens rather than a specification: real systems are hybrids with undocumented arbitration, and calling one "deliberative" tells you less than reading its tool list.

Where this framing is wrong. If your agent is read-only, single-turn and internal, the authority stack collapses to identity plus a log and the rest is overhead. Do not build five controls for a summariser. The framing earns its cost the moment the agent can write.

Where LeapForce fits

LeapForce builds the authority stack as shared infrastructure rather than per-application code: one governed endpoint in front of every model, agent identities with an owner and an expiry, connectors scoped at the action level, human approval gates inside workflows, budgets in dollars, and a record of what an agent attempted including what it was refused. Our AI Gateway treats a single request as six ordered stages, Identify, Check, Protect, Route, Execute and Record, which is the authority stack as a request path. Its published rollout model is deliberately unheroic: Observe first. Enforce second. Optimize third. Point one team's traffic at the gateway in observe mode before enforcing anything, because the first useful output is finding out what is already happening.

To be plain about the boundary: LeapForce does not build your agent, and nothing on our platform will tell you whether your task wants one agent or five. The planner, the memory design, the tool implementations and the reflection loop stay yours. What we run is the layer underneath: access and identity for human and non-human principals, workflows with durable runs and approval gates, observability and audit for the record. Our site carries a standing disclosure that LeapForce is in active development and that per-capability build status, live or in development or roadmap, is available on request. Ask us for it rather than assuming everything named in this paragraph ships today.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.