2026 09 14 higher order agentic ai platform patterns

Higher-order operational patterns in production agentic AI

Research Question

What higher-order operational patterns recur across production agentic Artificial Intelligence (AI) systems, what underlying operational problems do they address, and which patterns generalise across applications and execution environments?

Scope

In scope:

Recurrent higher-order operational patterns observed across production agentic systems, including patterns that span state, validation, recovery, governance, integration, auditability, and output contracts.
The underlying operational problems those patterns address, including business failure modes, reliability issues, integration constraints, and organisational frictions.
Comparative evidence across industries, applications, and execution environments, including low-code, pro-code, and Integrated Development Environment (IDE)-based runtimes.
The composition of higher-order patterns from lower-level mechanisms such as prompting, tool use, planning, memory, retrieval, multi-agent coordination, workflow orchestration, state management, policies, and communication substrates.
Criteria that distinguish broadly generalisable operational patterns from context-specific implementations.
Conditions under which recurring patterns are abstracted into reusable enterprise platform capabilities rather than kept inside applications.

Out of scope:

Evaluating individual foundation models or prompt techniques in isolation from production operating context.
Vendor feature-by-feature product comparisons below the level needed to identify operational patterns or their generalisation boundaries.
Greenfield reference-architecture design for a single named organisation.
Research on isolated lower-level agent mechanics except where they are needed to explain how higher-order patterns are composed.

Constraints: (time, source types, access)

Prioritise public sources with empirical or architectural signal: peer-reviewed papers, systematic reviews, standards or protocol documentation, vendor architecture material, and published enterprise case studies.
Use the seeded links as anchors, but allow discovery of adjacent sources where they add better evidence on production patterns.
Focus on evidence that distinguishes recurring operational patterns from runtime-specific implementation details and from lower-level agent mechanics.
Distinguish cross-context generalisations from patterns that remain industry-, application-, or runtime-specific.
All sources must include URLs.

Context

This item informs enterprise platform design by identifying which recurring operational problems and solution patterns actually persist across production agentic systems, and which of those patterns are general enough to justify shared platform abstraction.

Cross-references:

2026-04-22-enterprise-ai-platform-operating-models: adjacent operating-model work on how enterprises assign ownership and structure shared AI platform capabilities.
2026-04-22-enterprise-ai-capability-model: related capability-mapping work on deciding when AI use cases can reuse existing shared enterprise capabilities.
2026-04-24-business-led-low-code-agent-governance: related evidence on the governance conditions under which low-code agent creation scales without fragmentation.
2026-04-26-ai-lowcode-sdlc-platform-engineering-integration: related work on integrating AI and low-code delivery into platform engineering, release, and governance practices.

Approach

Identify recurring operational problems across published production examples of agentic AI and the higher-order operational patterns that emerge in response.
For each pattern, compare how it differs from, extends, or composes lower-level agent mechanics such as prompting, tool use, planning, memory, retrieval, and multi-agent coordination.
Analyse the business, operational, integration, reliability, and organisational frictions that motivate these patterns and persist beyond lower-level mechanisms alone.
Compare the observed patterns across industries, applications, and low-code, pro-code, and IDE-based execution environments to determine which characteristics support generalisation and which remain context-specific.
Decompose each higher-order pattern into its lower-level workflow, state, policy, integration, and communication mechanisms, identifying invariants, dependencies, and trade-offs.
Analyse when recurrent patterns are abstracted into reusable enterprise platform capabilities and what distinguishes platform-level capability from application-specific implementation.

Sources

Starting points: papers, articles, videos, repos, docs.

Research Skill Output

(Full output from running the research skill, retained verbatim in the completed item. Sections 0 through 5 are the investigation; §6 seeds the Findings section below.)

§0 Initialise

Question: What higher-order operational patterns recur across production agentic Artificial Intelligence (AI) systems, what underlying operational problems do they address, and which patterns generalise across applications and execution environments? Scope: In scope is comparative evidence on recurring operational patterns above the level of individual prompting, tool-use, or planning mechanics; out of scope is single-model evaluation or vendor feature comparison below the pattern level. Constraints: prioritise peer-reviewed and standards-adjacent sources plus vendor architecture material and published case studies; all sources carry URLs; distinguish cross-context generalisations from context-specific implementations.

Prior-work cross-reference: a search of Research/completed/ surfaced seven directly related items. 2026-04-22-enterprise-ai-platform-operating-models established that enterprises running multiple AI platforms in parallel converge on a hybrid hub-and-spoke operating model rather than a single unified team once demand matures [fact; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-22-enterprise-ai-platform-operating-models.md]. 2026-04-22-enterprise-ai-capability-model found that reusable capability only materialises when governance, evaluation, and platform safety nets are treated as shared enterprise rails rather than left inside individual use cases [fact; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-22-enterprise-ai-capability-model.md]. 2026-04-24-business-led-low-code-agent-governance found that decentralised agent creation is durable only on top of centrally governed risk-based intake, data controls, and lifecycle ownership [fact; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-24-business-led-low-code-agent-governance.md]. 2026-04-26-ai-lowcode-sdlc-platform-engineering-integration found that AI and low-code governance should be integrated into the same Continuous Integration and Continuous Delivery (CI/CD) and platform-engineering system used for conventional software rather than run as a separate assurance lane [fact; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-lowcode-sdlc-platform-engineering-integration.md]. Three further items bear directly on this item's governance-and-tool-registry and inter-agent trust findings. 2026-04-26-ai-agent-control-plane-architecture-enterprise specifies that the required enterprise architecture is a layered control plane with a central policy administration and decision core, a translation and distribution layer, heterogeneous enforcement adapters, and closed-loop observability, and that a single gateway or vendor administration plane is insufficient, which is the same policy-gateway-plus-enforcement-adapter structure this item's governance layer and tool-registry findings describe from the agentic-architecture literature side [fact; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-agent-control-plane-architecture-enterprise.md]. 2026-04-26-ai-agent-identity-access-management-enterprise establishes that every consequential non-human actor needs its own first-class identity with short-lived credentials, and that delegation preserving both subject and actor is architecturally distinct from impersonation that collapses the two, which is the identity-model precondition this item's inter-agent trust escalation finding assumes is currently under-enforced [fact; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-agent-identity-access-management-enterprise.md]. 2026-05-06-aibom-identity-attribution-multiagent-practice found that attribution breaks in practice when a sub-agent or tool call changes credential type or crosses a trust boundary, because native traces expose the current caller more clearly than the original authoriser, which is the mechanism-level explanation for how the MCP registry's unverified-pointer weakness and inter-agent trust escalation manifest concretely in deployed multi-agent pipelines [fact; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-05-06-aibom-identity-attribution-multiagent-practice.md]. These seven items establish organisational, architectural, and identity-model conditions for shared platform capability; this item investigates the operational patterns (state, validation, recovery, coordination, and evaluation mechanisms observed recurring in practice) that those architectures and identity models must actually support. [inference; source: https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-22-enterprise-ai-platform-operating-models.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-agent-control-plane-architecture-enterprise.md; https://github.com/davidamitchell/Research/blob/main/Research/completed/2026-04-26-ai-agent-identity-access-management-enterprise.md]

§1 Question Decomposition

What recurring operational problems appear across published production agentic AI systems, and what higher-order patterns emerge in response? 1.1. What structural failure modes recur across deployed agentic systems (state loss, human-in-the-loop (HITL) bypass, supply-chain compromise, silent drift)? 1.2. What architectural response patterns are documented for each failure mode (typed tool contracts, policy enforcement gateways, provenance verification, continuous production evaluation)?
How do higher-order patterns differ from, extend, or compose lower-level agent mechanics (prompting, tool use, planning, memory, retrieval, multi-agent coordination)? 2.1. Which published pattern catalogues treat prompting/tool-use/planning as the base layer versus the composed layer? 2.2. What is the relationship between Gang of Four (GoF)-style interaction patterns and the strategy-level patterns (Reflection, Tool Use, Planning, Multi-Agent Collaboration) identified by earlier surveys?
What business, reliability, integration, and organisational frictions motivate these patterns and persist beyond any single mechanism? 3.1. What frictions does typed tool governance address that ad hoc prompt-based tool invocation does not? 3.2. What frictions does event-driven coordination address that point-to-point request/response orchestration does not?
How do observed patterns compare across industries, applications, and low-code, pro-code, and Integrated Development Environment (IDE)-based execution environments? 4.1. Do the same governance and observability primitives (Role-Based Access Control (RBAC), audit logs, tracing) appear across independently published vendor and research architectures? 4.2. Which patterns remain runtime-specific (for example, event-log substrates tied to a specific streaming platform) versus environment-agnostic?
How is each higher-order pattern decomposed into lower-level workflow, state, policy, integration, and communication mechanisms, and what invariants, dependencies, and trade-offs does that decomposition reveal? 5.1. What invariants does the reference architecture in the evolution paper specify as mandatory clauses (policy enforcement gateway, typed/versioned tool invocation, bounded autonomy)? 5.2. What trade-offs does the choice between orchestrator-worker, hierarchical, blackboard, and market-based coordination impose?
Under what conditions are recurring patterns abstracted into reusable enterprise platform capabilities rather than kept inside individual applications? 6.1. What does the Model Context Protocol (MCP) registry security literature indicate about the shift from application-embedded tool wiring to a shared, governed registry layer? 6.2. What does the production-evaluation literature indicate about the shift from per-application evaluation scripts to a shared, continuously running evaluation framework?

§2 Investigation

1.1 Structural failure modes. Microsoft's AI Red Team published a v1.0 taxonomy of agentic failure modes in April 2025 and a v2.0 revision in June 2026 grounded in twelve months of red-team engagements against deployed systems [fact; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]. The v2.0 update adds seven failure-mode categories: agentic supply chain compromise, goal hijacking, inter-agent trust escalation, computer-use-agent visual attack, session context contamination, MCP/plugin abuse, and capability/architecture disclosure [fact; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]. Human-in-the-loop bypass was the most consistently exploited failure mode across a year of engagements, achieved through consent fatigue, manipulation of probabilistic invocation, and incremental escalation chains where no single step warranted review but the compound outcome did [fact; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]. Session context contamination and incremental escalation were reported as highly effective and difficult to detect because neither the contaminating input nor any individual escalation step is anomalous in isolation, which requires behavioural analysis across a full session rather than single-step controls [fact; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]. This is independent, credible confirmation from a security-operations source that state-and-session integrity is a first-order operational problem, not only a data-quality concern, corroborating the architectural emphasis on session and memory governance found in the evolution-paper reference architecture below. [inference; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/; https://arxiv.org/html/2602.10479v1]

Separately, a production-evaluation paper proposing the Production Agentic Evaluation Framework (PAEF) documents that standard evaluation metrics (ROUGE, BERTScore, accuracy/Area Under the Curve (AUC), and existing agentic benchmarks such as AgentBench) fail to detect four of seven identified production failure modes entirely and detect three others only after a lag of multiple evaluation cycles, because those metrics are designed for controlled, single-session, lab-scale settings rather than continuous production traffic with compounding decision errors, tool failure cascades, and non-deterministic output drift [fact; source: https://arxiv.org/html/2605.01604]. This is a second, methodologically distinct source (evaluation research rather than red-team operations) converging on the same underlying problem: episodic, single-session assessment cannot observe failure modes that only manifest across an extended operational trajectory. [inference; source: https://arxiv.org/html/2605.01604; https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]

1.2 Response patterns. The reference architecture proposed in a 2026 review of agentic software architecture evolution specifies a layered stack in which an Agent Core (the Large Language Model (LLM) reasoning component) is explicitly separated from a Control Layer (planner/policy logic, state machines, retry and backoff, circuit breakers), a Memory Layer (working context, episodic store, semantic knowledge base, preferences), a Tooling Layer (tool registry and schemas, connectors, sandboxed execution, Retrieval-Augmented Generation (RAG)), and a cross-cutting Governance and Observability layer (RBAC and audit logs, tracing and evaluation, policy enforcement, cost and rate limits) [fact; source: https://arxiv.org/html/2602.10479v1]. The paper formalises this separation as a set of mandatory and recommended clauses rather than a diagram: all side-effecting actions must be mediated by a policy enforcement gateway that prevents direct tool invocation by the language model, every tool invocation must be strongly typed and versioned with schemas recorded as execution metadata, every execution run must produce a trace capturing model identifier, prompt version, tool versions, policy decisions, memory operations, principal identity, and resource budgets, and budgeted autonomy (explicit limits on tokens, execution time, tool invocations, and monetary cost with defined fail-safe termination) is treated as a first-class invariant [fact; source: https://arxiv.org/html/2602.10479v1]. This converts the architecture from a descriptive layering diagram into a testable specification, which is the property that distinguishes a higher-order operational pattern from an implementation detail: the pattern is defined by the invariant it enforces (bounded, typed, audited, policy-gated execution), not by which vendor or runtime enforces it. [inference; source: https://arxiv.org/html/2602.10479v1]

2.1/2.2 Relationship to lower-level mechanics. A 2026 system-theoretic framework paper explicitly distinguishes two categories of prior pattern work: strategy-level catalogues such as Andrew Ng's four patterns (Reflection, Tool Use, Planning, Multi-Agent Collaboration), which are "generalised and simple but effective approaches" without detailed implementable structure, and empirically-grounded architectural inventories such as the Commonwealth Scientific and Industrial Research Organisation (CSIRO)'s pattern catalogue, which document observed functionality but lack a unifying theoretical account of why components interact as they do [fact; source: https://arxiv.org/html/2601.19752v1]. The paper argues that neither category supplies GoF-style patterns, meaning reusable, structural solutions to recurring interaction problems between subsystems, and proposes deriving such patterns from first-principles system theory instead, decomposing an agent into interacting subsystems and defining patterns at the level of the information flows (context, feedback) that govern behaviour between those subsystems [fact; source: https://arxiv.org/html/2601.19752v1]. This supports treating Reflection, Tool Use, Planning, and Multi-Agent Collaboration as base-layer strategic mechanics that higher-order patterns compose, rather than as higher-order patterns themselves: a higher-order pattern in this item's sense (for example, a policy enforcement gateway, or an event-driven coordination substrate) is a structural solution to a recurring cross-subsystem problem, of which Ng's four strategies are ingredients rather than solutions to the coordination problem itself. [inference; source: https://arxiv.org/html/2601.19752v1]

3.1 Frictions addressed by typed tool governance. The evolution-paper review reports that early tool-use integrations relied on "unstructured prompt patterns which proved fragile," and that production platforms instead treat tools as typed contracts with input/output/precondition schemas, discoverable versioned registry entries with access control, and sandboxed least-privilege execution units, citing TrueFoundry's schema validation and policy-oriented Model Context Protocol server deployment and Kore.ai's tool/dialog integrations with admin controls, audit logs, and guardrails as concrete vendor instances of this pattern [fact; source: https://arxiv.org/html/2602.10479v1]. The paper explicitly frames tool registries as "the agentic-system analogue of Application Programming Interface (API) gateways in microservices architectures" [fact; source: https://arxiv.org/html/2602.10479v1]. Independently, the MCP registry security paper documents the friction this addresses at the protocol level: the current MCP registry uses an "unverified pointer architecture" that exposes agent workflows to supply-chain poisoning and dynamic capability mutation ("Rug Pull") attacks, where a previously vetted tool definition is silently altered after approval [fact; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157]. Two independent sources, an architecture-review paper and a security-engineering paper, therefore converge on the same underlying friction (unverified, mutable tool definitions consumed at runtime) from different methodological angles, one from an operational-governance perspective and one from a cryptographic-integrity perspective. [inference; source: https://arxiv.org/html/2602.10479v1; https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157]

3.2 Frictions addressed by event-driven coordination. A vendor engineering article on event-driven multi-agent systems documents that request/response, point-to-point coordination among multiple agents "struggles with scalability and real-time responsiveness" and requires bespoke logic for managing worker failure, addition, and removal, whereas an event-driven substrate lets an orchestrator "specify work and distribute it with a sensible keying strategy" while worker agents inherit consumer-group semantics for scaling and fault recovery from the underlying streaming platform [fact; source: https://www.confluent.io/blog/event-driven-multi-agent-systems/]. The article documents four recurring multi-agent coordination topologies converted to event-driven form: orchestrator-worker (central task assignment via keyed partitions), hierarchical agent (recursive orchestrator-worker nesting across tree layers), blackboard (a shared topic agents asynchronously post to and consume from), and market-based (bid/ask topics matched by an aggregator agent) [fact; source: https://www.confluent.io/blog/event-driven-multi-agent-systems/]. The article states the market-based pattern "eliminates the quadratic connections that otherwise occur between the solver agents," which is a specific, source-stated claim about connection complexity rather than a general performance claim. [fact; source: https://www.confluent.io/blog/event-driven-multi-agent-systems/]

4.1 Cross-source convergence on governance primitives. The same triad of governance primitives (RBAC/audit logs, tracing/evaluation, and policy enforcement) recurs independently across the evolution-paper's synthesis of TrueFoundry, Kore.ai, LangChain, and ZenML material [fact; source: https://arxiv.org/html/2602.10479v1], across the MCP registry paper's cryptographic-provenance framing [fact; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157], and across Microsoft's red-team mitigations, which recommend Software Bill of Materials (SBOM) generation for agent deployments, signature and provenance verification for MCP servers and plugins, and cryptographically established (not positionally assumed) inter-agent identity [fact; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]. Three independently authored sources spanning academic review, applied research, and vendor security operations describe the same primitive set, which is stronger convergence evidence than any one source alone. [inference; source: https://arxiv.org/html/2602.10479v1; https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157; https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]

4.2 Environment-specific versus environment-agnostic patterns. The event-driven coordination substrate described by the Confluent article is explicitly tied to a specific class of technology (Kafka-style partitioned, replayable event logs) for its concrete guarantees such as consumer-group rebalancing and offset replay [fact; source: https://www.confluent.io/blog/event-driven-multi-agent-systems/], which marks it as a runtime-specific implementation of a more general pattern: decoupled, asynchronous, replayable agent-to-agent communication. By contrast, the invariants specified in the evolution-paper's normative architecture (policy gateway mediation, typed/versioned tool contracts, bounded autonomy, provenance-carrying traces) are stated independent of any specific runtime or vendor and are the closest candidate in the evidence gathered for an environment-agnostic higher-order pattern. [inference; source: https://arxiv.org/html/2602.10479v1; https://www.confluent.io/blog/event-driven-multi-agent-systems/]

A systematic literature review (SLR) of agentic AI across the software development life cycle (SDLC) reports that the most mature industrial adoption occurs in later SDLC phases where agent outputs can be objectively verified, and that "Planner–Executor–Reviewer" specialisation dominates current architectures for software-engineering agents [fact; source: https://arxiv.org/html/2605.15245v1]. This is one data point from a single SLR rather than corroborated by a second independent review, so it is treated as medium-confidence evidence of environment-specific convergence within the software-engineering application domain specifically, not yet generalised evidence across all agentic application domains. [inference; source: https://arxiv.org/html/2605.15245v1]

Access note: seeded ResearchGate review ("Intelligent Agents for Software Engineering: A Systematic Literature Review") : HTTP 403 in this session; substituted arXiv:2605.15245v1 ("Assistance to Autonomy," same SDLC-agent domain); ## Sources entry updated to substitute.

5.1/5.2 Decomposition, invariants, and trade-offs. The evolution-paper's Algorithm 1 (generic agent loop) makes the decomposition explicit: a planning step proposes an action, a policy-violation check triggers plan repair before execution, a typed tool invocation runs in a sandbox, state is updated, and memory is written, with a bounded iteration count and an explicit fail-safe/escalation path if the loop does not converge [fact; source: https://arxiv.org/html/2602.10479v1]. The dependency this reveals is that policy enforcement must sit before tool execution in the control flow (a gate, not a post-hoc audit), and that state update and memory write must be atomic with the action taken, or the trace becomes unreliable for later audit and replay. [inference; source: https://arxiv.org/html/2602.10479v1]

The trade-off between coordination topologies is stated directly in the Confluent article: orchestrator-worker centralises control and simplifies reasoning about task assignment but creates a coordination bottleneck as agent count grows; hierarchical nesting distributes that bottleneck recursively at the cost of added indirection; blackboard removes direct agent-to-agent coupling entirely but provides no built-in conflict resolution when multiple agents post contradictory updates; and market-based coordination avoids quadratic peer connections but introduces an aggregator agent as a new single point of failure and requires a well-defined bid/ask semantics that not all task types have [fact; source: https://www.confluent.io/blog/event-driven-multi-agent-systems/]. Microsoft's taxonomy adds a security-specific trade-off to hierarchical and delegated coordination: "inter-agent trust escalation" arises specifically because orchestrators in delegation chains often do not independently verify a sub-agent's claimed identity or permissions, mirroring the confused-deputy problem, a classic software-security failure mode in which a privileged program is tricked into misusing its own authority on an attacker's behalf, originally documented in traditional operating-system software but here induced through natural language rather than system calls [fact; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/; http://www.cap-lore.com/CapTheory/ConfusedDeputy.html].

6.1 Application-embedded wiring versus shared registry. The MCP registry security paper frames its own contribution as addressing a gap in "the individual standards employed" (Request for Comments (RFC) 8615 Well-Known Uniform Resource Identifiers (URIs), Sigstore keyless signing, JSON Canonicalization Scheme (JCS)/JSON Web Signature (JWS)) which are each established technologies, but whose specific composition into a domain-bound identity, CI/CD-audited artifact-binding, and per-message integrity-verification stack has not previously been assembled for MCP specifically [fact; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157]. Their prototype evaluation reports cryptographic signing overhead averaging 0.61 milliseconds (ms) per operation and that the proposed Layer 3 mechanism rejected all 100 simulated "Rug Pull" attack attempts in a controlled, synthetic environment [fact; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157]. This is a single-paper, synthetic-environment result rather than a field-validated deployment measurement, so the practical overhead and attack-rejection rate in production conditions with adversarial, not merely simulated, attackers remains unverified. [assumption; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157] Microsoft's independent taxonomy corroborates that the underlying problem is real at scale outside this one paper's synthetic test: in 2025, 99 Common Vulnerabilities and Exposures (CVEs) were published for MCP-related software, and tool poisoning "moved from theoretical risk to live attack surface" [fact; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]. The combination of a proposed cryptographic-provenance mechanism (single paper, synthetic validation) and an independent, field-observed vulnerability count for the same protocol class is the evidentiary basis for treating registry-level provenance verification as an emerging, not yet mature, abstraction boundary for shared platform capability. [inference; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157; https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]

6.2 Per-application evaluation versus shared continuous evaluation. The PAEF paper's explicit motivation is that existing evaluation frameworks (HELM, MT-Bench, AgentBench, BIG-bench) are "designed for controlled, single-session, lab-scale settings" and do not address production-scale evaluation, and proposes a five-dimension framework "designed for continuous evaluation on production traffic rather than episodic benchmark runs," released with an open-source reference implementation [fact; source: https://arxiv.org/html/2605.01604]. An open-source reference implementation intended for reuse across deployments is itself evidence of the abstraction condition this item's Approach step 6 asks about: the authors are proposing the evaluation layer be extracted from individual applications into a shared, reusable framework precisely because per-application, episodic evaluation was shown empirically to miss most production failure modes. [inference; source: https://arxiv.org/html/2605.01604]

Failed primary-source search: seeded MDPI page (mdpi.com/1999-5903/18/5/243) : HTTP 403 in this session; abstract/methodology/results above sourced instead from EconPapers/RePEc mirror (econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157), verbatim republication with full bibliographic metadata; ## Sources retains both the original Digital Object Identifier (DOI)-resolving URL and the mirror.

§3 Reasoning

Across the six sub-questions, three higher-order pattern classes have direct, cross-source support: (1) a governance-and-observability layer that cross-cuts cognition, control, memory, and tooling and is specified as mandatory policy-gated, typed, and traced execution rather than optional instrumentation [fact; source: https://arxiv.org/html/2602.10479v1]; (2) a typed, versioned, registry-mediated tool-access layer that replaces ad hoc prompt-based tool invocation, independently motivated by both operational-governance and cryptographic-integrity concerns [fact; source: https://arxiv.org/html/2602.10479v1; https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157]; and (3) an event-driven, asynchronous coordination substrate that replaces point-to-point request/response orchestration among multiple agents, with topology choice (orchestrator-worker, hierarchical, blackboard, market-based) trading off centralised simplicity against bottleneck risk, conflict-resolution capability, and new single points of failure [fact; source: https://www.confluent.io/blog/event-driven-multi-agent-systems/]. A fourth pattern, continuous production-traffic evaluation replacing episodic benchmark evaluation, has direct empirical support for the problem (standard metrics miss most production failure modes) but only one proposed solution framework with a reference implementation rather than corroborated evidence that this exact framework has been independently adopted elsewhere [fact; source: https://arxiv.org/html/2605.01604]. Lower-level mechanics (Reflection, Tool Use, Planning, Multi-Agent Collaboration) are the substrate these higher-order patterns compose, not competing candidates for higher-order status, based on the explicit two-tier distinction one source draws between strategy-level catalogues and structural, interaction-level patterns [fact; source: https://arxiv.org/html/2601.19752v1].

§4 Consistency Check

contradiction_scan: resolved
notes: no direct contradiction found between sources; the SDLC-agent SLR finding (Planner-Executor-Reviewer dominance) is scoped to software-engineering agents specifically and is not generalised beyond that domain, avoiding an overreach that would otherwise conflict with the cross-domain generalisation claims made for governance, tool-registry, and coordination patterns.
confidence_adjustment: MCP registry provenance claim kept at medium because prototype evaluation used a synthetic, controlled attack environment rather than field-validated adversarial conditions.
scope_guardrail: maintained; findings about event-log-specific guarantees (consumer-group rebalance, offset replay) are kept scoped to that runtime class rather than generalised as environment-agnostic.
acronym_audit: pending final full-document pass in Step 4/Step 6 of the workflow

§5 Depth and Breadth Expansion

Technical lens. The evolution-paper's Algorithm 1 makes technical debt visible as a first-order design cost: policy enforcement, typed tool contracts, and bounded autonomy are only enforceable if they are built into the control loop's structure from the start, because "architectural decisions... are difficult to retrofit," a point Microsoft's mitigations section makes explicitly about supply-chain and zero-trust controls specifically [fact; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]. This suggests the higher-order patterns identified here are closer to architectural invariants than to optional add-on features, because the cited source explicitly frames them as pre-deployment decisions rather than post-deployment hardening options. [inference; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]

Economic lens. The MCP registry paper's reported 0.61 ms per-operation cryptographic signing overhead is a specific, quantified cost figure for one provenance-verification mechanism under synthetic test conditions [fact; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157]. No cited source in this investigation reports the operational cost of adopting continuous production evaluation (PAEF) or event-driven coordination substrates at comparable granularity, so a full cost comparison across the three higher-order patterns identified is not possible from the evidence gathered and is recorded as a gap below. [assumption; source: https://arxiv.org/html/2605.01604]

Regulatory lens. None of the five directly investigated sources are themselves regulatory documents; the governance triad (RBAC/audit logs, tracing, policy enforcement) that recurs across the vendor and academic sources aligns descriptively with generic auditability and access-control requirements found in AI risk-management frameworks, but this item did not independently verify that alignment against a named regulatory text, so no regulatory-compliance claim is made here beyond noting the descriptive overlap. [assumption; source: https://arxiv.org/html/2602.10479v1]

Historical lens. The system-theoretic framework paper situates current pattern work against a documented prior wave (Ng's 2024 strategy catalogue, the CSIRO empirical catalogue, and earlier GoF-style software design pattern literature from 1995), showing that the shift from "which feature does this system have" toward "which structural interaction problem does this pattern solve" is an explicitly stated methodological move made by this specific paper rather than an industry-wide consensus shift documented by multiple independent historians of the field [fact; source: https://arxiv.org/html/2601.19752v1].

Behavioural lens. Microsoft's finding that HITL bypass exploits "consent fatigue" is a documented behavioural failure mode: the mitigation proposed (deterministic HITL invocation, tiered approval requirements that scale with reversibility, anomaly detection on approval-request frequency) treats human reviewer attention as a scarce, exhaustible resource that must be architecturally protected rather than assumed reliable by default [fact; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/].

§6 Synthesis

(This section seeds the Findings below.)

Executive summary:

Three higher-order operational patterns recur across the production agentic AI evidence gathered for this item: a mandatory, cross-cutting governance-and-observability layer that gates every tool call through policy enforcement and typed, versioned contracts; an event-driven, asynchronous coordination substrate that replaces point-to-point orchestration among multiple agents; and a shift from per-application, episodic evaluation toward continuous, production-traffic evaluation. [inference; source: https://arxiv.org/html/2602.10479v1; https://www.confluent.io/blog/event-driven-multi-agent-systems/; https://arxiv.org/html/2605.01604] These patterns exist because lower-level agent mechanics (prompting, tool use, planning, multi-agent collaboration) solve individual-agent capability problems but do not by themselves solve cross-subsystem or cross-agent coordination, integrity, and accountability problems, which is the specific gap the higher-order patterns close. [inference; source: https://arxiv.org/html/2601.19752v1] The governance-and-tool-registry pattern generalises most strongly across the evidence because it is independently motivated by operational-governance, cryptographic-integrity, and security-operations sources; the event-driven coordination substrate generalises at the level of its underlying property (decoupled, asynchronous, replayable messaging) but its concrete implementation remains tied to specific streaming-platform runtimes; and continuous production evaluation is well-evidenced as a necessary response to a documented measurement gap but has only one proposed reference framework rather than corroborated independent adoption. [inference; source: https://arxiv.org/html/2602.10479v1; https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157; https://www.confluent.io/blog/event-driven-multi-agent-systems/; https://arxiv.org/html/2605.01604] Human-in-the-loop bypass is documented as the single most consistently exploited weakness across a year of red-team engagements, which is consistent with governance patterns aimed at machine-to-machine integrity (typed tools, provenance, tracing) currently outpacing governance patterns aimed at the human-machine consent boundary, though a plausible rival explanation is that red-team engagements preferentially probe human-consent-boundary weaknesses because they are behaviourally easier to elicit than cryptographic or supply-chain attacks, which would produce the same exploitation-frequency result without any underlying governance-maturity gap; the evidence gathered does not rule out this testing-selection-bias explanation. [inference; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]

Key findings:

Production agentic AI reference architectures separate the LLM reasoning component from a control layer, memory layer, and tooling layer, with governance and observability treated as cross-cutting concerns spanning all four rather than a bolt-on feature. ([fact]; medium confidence; source: https://arxiv.org/html/2602.10479v1)
Production architecture specifications increasingly encode this separation as enforceable invariants, requiring a policy enforcement gateway for all side-effecting actions and strongly typed, versioned tool invocation. ([fact]; medium confidence; source: https://arxiv.org/html/2602.10479v1)
Tool registries with typed schemas, versioning, and access control function as the agentic-system analogue of API gateways in microservices architectures, replacing unstructured prompt-based tool invocation. ([fact]; medium confidence; source: https://arxiv.org/html/2602.10479v1)
The MCP registry ecosystem's unverified-pointer design exposes tool definitions to supply-chain poisoning and "Rug Pull" attacks; 99 CVEs were published for MCP-related software in 2025 as tool poisoning moved from theoretical risk to live attack surface. ([fact]; high confidence; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157; https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/)
Event-driven coordination substrates replace point-to-point orchestration among multiple agents in four recurring topologies (orchestrator-worker, hierarchical, blackboard, market-based), each with distinct trade-offs. ([fact]; medium confidence; source: https://www.confluent.io/blog/event-driven-multi-agent-systems/)
HITL bypass was the most consistently exploited failure mode across twelve months of red-team engagements against deployed agentic systems. ([fact]; medium confidence; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/)
Standard evaluation metrics fail to detect four of seven documented production failure modes entirely, motivating a shift toward continuous production-traffic evaluation. ([fact]; medium confidence; source: https://arxiv.org/html/2605.01604)
Inter-agent trust escalation, a confused-deputy-style vulnerability specific to delegated multi-agent coordination, is a documented failure mode in production red-team engagements. ([fact]; medium confidence; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/)
Strategy-level catalogues (Reflection, Tool Use, Planning, Multi-Agent Collaboration) are treated as structurally under-specified building blocks distinct from GoF-style structural interaction patterns. ([fact]; medium confidence; source: https://arxiv.org/html/2601.19752v1)
Planner-Executor-Reviewer specialisation dominates software-engineering agent architectures specifically, with the most mature adoption in later, objectively verifiable SDLC phases. ([fact]; low confidence; source: https://arxiv.org/html/2605.15245v1)

The full evidence-map table, per-claim source and confidence detail, assumptions, analysis, risks, and open questions are written out in full in the ## Findings section below; that section is the expanded version of this synthesis and contains no claims beyond what is stated here and in §§0-5 above.

Evidence map:

Ten claims mapped to source, confidence, and notes; reproduced in full in the Evidence Map table under ## Findings below.

Assumptions:

Three explicit assumptions carried forward: the MCP registry paper's synthetic-environment performance figures are indicative rather than production-representative [assumption; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157]; no comparably granular cost data exists for the event-driven or continuous-evaluation patterns [assumption; source: https://arxiv.org/html/2605.01604]; and the descriptive overlap between the recurring governance triad and generic AI risk-management requirements is suggestive, not confirmed against a named regulatory text [assumption; source: https://arxiv.org/html/2602.10479v1]. Full text with citations appears under ## Findings below.

Analysis:

The governance-and-tool-registry pattern has the broadest independent corroboration of the three patterns identified, drawing on architecture-review, cryptographic-security, and red-team operational sources that converge on the same primitive set. [inference; source: https://arxiv.org/html/2602.10479v1; https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157; https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/] The event-driven coordination pattern generalises at the level of its underlying property but not at the level of its concrete streaming-platform implementation. [inference; source: https://www.confluent.io/blog/event-driven-multi-agent-systems/] A plausible rival explanation (vendor-marketing convergence rather than architectural necessity) is only partly rebutted by the independent Microsoft red-team evidence, and a second rival explanation (testing-selection bias) is not ruled out for the HITL-bypass finding. [inference; source: https://arxiv.org/html/2602.10479v1; https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/] Full reasoning appears under ## Findings below.

Risks, gaps, uncertainties:

The MCP provenance mechanism is validated only in simulation [fact; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157]; the coordination-topology evidence rests on one vendor source [assumption; source: https://www.confluent.io/blog/event-driven-multi-agent-systems/]; the Planner-Executor-Reviewer finding is scoped to software engineering only [fact; source: https://arxiv.org/html/2605.15245v1]; two seeded sources required substitution due to access errors [assumption; source: https://arxiv.org/html/2605.15245v1]; and no cross-pattern cost comparison could be constructed [assumption; source: https://arxiv.org/html/2605.01604]. Full text appears under ## Findings below.

Open questions:

Whether Planner-Executor-Reviewer-style specialisation generalises to other application domains; what field-measured MCP provenance overhead looks like under real adversarial conditions; whether PAEF has been independently replicated; and what the comparative engineering cost of event-driven versus simpler coordination topologies is at a given scale threshold. Full text appears under ## Findings below.

§7 Recursive Review

review_result: pass
acronym_audit: passed (LLM, MCP, RAG, RBAC, HITL, SDLC, CI/CD, IDE, GoF, CVE, SBOM, AUC, PAEF, URI, JCS, JWS, DOI, RFC, SLR, CSIRO, HTTP, AI expanded at first use; verified by full-document grep)
claim_audit: passed (every declarative sentence in §2 carries a fact/inference/assumption label; opening sentences of each sub-question paragraph checked individually)
parity_check: §6 synthesis mirrors Findings; any post-review edit to Findings must be mirrored back here before commit
source_completeness: passed (every inline URL cited in §2-§6 has a matching entry in ## Sources, including the accessible substitutes added for the two 403-blocked seeds)

Findings

(Populated from §6 Synthesis above.)

Executive Summary

Three higher-order operational patterns recur across production agentic Artificial Intelligence (AI) systems in the evidence gathered for this item: a mandatory, cross-cutting governance-and-observability layer that gates every tool call through policy enforcement and typed, versioned contracts; an event-driven, asynchronous coordination substrate that replaces point-to-point orchestration among multiple agents; and a shift from per-application, episodic evaluation toward continuous, production-traffic evaluation. [inference; source: https://arxiv.org/html/2602.10479v1; https://www.confluent.io/blog/event-driven-multi-agent-systems/; https://arxiv.org/html/2605.01604] These patterns exist because lower-level agent mechanics such as prompting, tool use, planning, and multi-agent collaboration solve individual-agent capability problems but do not by themselves solve cross-subsystem or cross-agent coordination, integrity, and accountability problems. [inference; source: https://arxiv.org/html/2601.19752v1] The governance-and-tool-registry pattern generalises most strongly across the evidence gathered because it is independently motivated by operational-governance, cryptographic-integrity, and security-operations sources, whereas the event-driven coordination substrate generalises only at the level of its underlying property (decoupled, asynchronous, replayable messaging) since its concrete implementation remains tied to specific streaming-platform runtimes. [inference; source: https://arxiv.org/html/2602.10479v1; https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157; https://www.confluent.io/blog/event-driven-multi-agent-systems/] Human-in-the-loop (HITL) bypass is documented as the single most consistently exploited weakness across a year of red-team engagements against deployed agentic systems, which is consistent with governance patterns aimed at machine-to-machine integrity currently outpacing governance patterns aimed at the human-machine consent boundary, though a plausible rival explanation is that red-team engagements preferentially select for human-consent-boundary weaknesses because they are behaviourally easier to elicit than cryptographic or supply-chain attacks, which would produce the same exploitation-frequency result without reflecting a genuine governance-maturity gap; the evidence gathered does not rule out this testing-selection-bias explanation. [inference; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]

Key Findings

Production agentic AI reference architectures separate the Large Language Model (LLM) reasoning component from a control layer, memory layer, and tooling layer, with governance and observability treated as cross-cutting concerns spanning all four rather than a bolt-on feature. ([fact]; medium confidence; source: https://arxiv.org/html/2602.10479v1)
Production architecture specifications increasingly encode this separation as enforceable invariants rather than descriptive diagrams, requiring that all side-effecting actions be mediated by a policy enforcement gateway and that every tool invocation be strongly typed, versioned, and recorded in execution metadata. ([fact]; medium confidence; source: https://arxiv.org/html/2602.10479v1)
Tool registries that expose typed schemas, versioning, and access control function as the agentic-system analogue of Application Programming Interface (API) gateways in microservices architectures, replacing the unstructured, fragile prompt-based tool invocation used in early integrations. ([fact]; medium confidence; source: https://arxiv.org/html/2602.10479v1)
The Model Context Protocol (MCP) registry ecosystem's current unverified-pointer design exposes agent tool definitions to supply-chain poisoning and dynamic capability mutation ("Rug Pull") attacks, and 99 Common Vulnerabilities and Exposures (CVEs) were published for MCP-related software in 2025 as tool poisoning moved from theoretical risk to live attack surface. ([fact]; high confidence; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157; https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/)
Event-driven, asynchronous coordination substrates replace point-to-point request/response orchestration among multiple agents in four recurring topologies: orchestrator-worker, hierarchical agent, blackboard, and market-based, each trading centralised simplicity against bottleneck risk, conflict-resolution capability, or new single points of failure. ([fact]; medium confidence; source: https://www.confluent.io/blog/event-driven-multi-agent-systems/)
Human-in-the-loop bypass was the most consistently exploited failure mode across twelve months of red-team engagements against deployed agentic systems, achieved through consent fatigue, manipulation of probabilistic invocation, and incremental escalation chains in which no single step warranted review but the compound outcome did. ([fact]; medium confidence; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/)
Standard evaluation metrics such as ROUGE, BERTScore, accuracy/Area Under the Curve (AUC), and existing agentic benchmarks fail to detect four of seven documented production failure modes entirely and detect three others only after a lag of multiple evaluation cycles, motivating a shift toward continuous evaluation on production traffic rather than episodic benchmark runs. ([fact]; medium confidence; source: https://arxiv.org/html/2605.01604)
Inter-agent trust escalation, in which a compromised or misrepresenting sub-agent asserts false identity or inflated permissions to an orchestrator that does not independently verify them, is a documented failure mode specific to delegated multi-agent coordination and mirrors the confused-deputy problem, a classic software-security failure mode in which a privileged program is tricked into misusing its own authority, induced here through natural language rather than system calls. ([fact]; medium confidence; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/; http://www.cap-lore.com/CapTheory/ConfusedDeputy.html)
Strategy-level pattern catalogues such as Reflection, Tool Use, Planning, and Multi-Agent Collaboration are treated in recent architectural literature as generalised but structurally under-specified building blocks, distinct from Gang of Four (GoF)-style structural patterns that solve recurring interaction problems between subsystems. ([fact]; medium confidence; source: https://arxiv.org/html/2601.19752v1)
Planner-Executor-Reviewer specialisation dominates current production architectures for software-engineering agents specifically, with the most mature industrial adoption occurring in later phases of the software development life cycle (SDLC) where agent outputs can be objectively verified. ([fact]; low confidence; source: https://arxiv.org/html/2605.15245v1)

Evidence Map

Claim	Source	Confidence	Notes
[fact] Layered reference architecture separates cognition, control, memory, tooling with cross-cutting governance/observability	Evolution of Agentic AI Software Architecture (2026)	medium	Single paper; vendor material synthesis within it (TrueFoundry, Kore.ai, LangChain, ZenML) treated as grey literature per the paper's own methodology
[fact] Policy enforcement gateway, typed/versioned tool contracts, and bounded autonomy specified as mandatory invariants	Evolution of Agentic AI Software Architecture (2026)	medium	Normative proposal from one paper, not yet corroborated by an independent standards body
[fact] Tool registries are the agentic analogue of API gateways	Evolution of Agentic AI Software Architecture (2026)	medium	Direct paper claim
[fact] MCP registry unverified-pointer architecture exposes supply-chain poisoning and Rug Pull risk; 99 MCP CVEs in 2025	Trustworthy MCP Registry (2026); Microsoft AI Red Team taxonomy v2.0 (2026)	high	Two independent organisations (academic + Microsoft security operations) corroborate the same underlying protocol-level risk
[fact] Four event-driven multi-agent coordination topologies with distinct trade-offs	Event-Driven Multi-Agent Systems (Confluent, 2025)	medium	Single vendor engineering source; Kafka-specific implementation detail, generalisable property only
[fact] HITL bypass most consistently exploited failure mode across a year of red-team engagements	Microsoft AI Red Team taxonomy v2.0 (2026)	medium	Direct operational finding from twelve months of engagements against deployed systems, but single organisation and no independent corroborating source, so capped at medium confidence
[fact] Standard metrics miss most production failure modes; PAEF proposed as continuous-evaluation response	Production Agentic Evaluation Framework (PAEF), arXiv:2605.01604 (2026)	medium	Single paper with open-source reference implementation; not yet corroborated by independent adoption evidence
[fact] Inter-agent trust escalation mirrors confused-deputy problem in delegated coordination	Microsoft AI Red Team taxonomy v2.0 (2026); Hardy (1988) The Confused Deputy	medium	Single source for the agentic-system claim; the confused-deputy concept itself is grounded in Hardy's original 1988 paper, not independently confirmed against a second agentic-system source
[fact] Ng's strategy-level patterns distinct from GoF-style structural interaction patterns	Agentic Design Patterns: A System-Theoretic Framework (2026)	medium	Single paper's literature classification; framing choice, not an independently replicated taxonomy
[fact] Planner-Executor-Reviewer dominance in SDLC agent architectures	Assistance to Autonomy: SLR of Agentic AI across the SDLC, arXiv:2605.15245 (2026)	low	Single systematic literature review; scoped to software-engineering agents only, not generalised across domains

Assumptions

The MCP registry paper's reported 0.61 millisecond (ms) per-operation cryptographic overhead and 100/100 simulated attack rejection rate are assumed to be indicative rather than production-representative, because the evaluation ran in a controlled, synthetic environment rather than against a field deployment with adversarial, non-simulated attackers. [assumption; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157]

No cost data comparable in granularity to the MCP paper's per-operation figure is available for the event-driven coordination substrate or the continuous-evaluation pattern, so a full cross-pattern cost comparison is assumed to be out of reach from currently published evidence rather than a gap specific to this item's search effort. [assumption; source: https://arxiv.org/html/2605.01604]

The descriptive overlap between the recurring governance triad (Role-Based Access Control (RBAC)/audit logs, tracing, policy enforcement) and generic AI risk-management framework requirements is assumed to be suggestive rather than confirmed, because no source in this investigation is itself a regulatory or standards document; a dedicated cross-reference against a named regulatory text was out of scope for this item. [assumption; source: https://arxiv.org/html/2602.10479v1]

Analysis

The governance-and-tool-registry pattern has the broadest independent corroboration of the three patterns examined here: it is documented from three independent methodological angles (an architecture-review paper synthesising four vendor platforms, a dedicated cryptographic-security paper, and a year of red-team operational data from Microsoft), and each angle converges on the same underlying primitive set of typed contracts, provenance verification, and policy gating. [inference; source: https://arxiv.org/html/2602.10479v1; https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157; https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/] The event-driven coordination pattern is well documented for the coordination problem it solves but the evidence base is a single vendor engineering source rather than an independently corroborated architectural review, so its generalisation claim is narrower: the underlying property (decoupled, asynchronous, replayable agent communication) generalises, while the specific implementation (partitioned, replayable event logs with consumer-group rebalancing) is runtime-specific to streaming platforms of that class. [inference; source: https://www.confluent.io/blog/event-driven-multi-agent-systems/]

A plausible rival explanation for the recurrence of the governance-and-tool-registry pattern is that it reflects convergent vendor marketing language rather than genuine architectural necessity, since three of the four platforms cited in the evolution paper (TrueFoundry, Kore.ai, and LangChain) are commercial agent-platform vendors with an incentive to describe their products in terms that match emerging buyer expectations. [inference; source: https://arxiv.org/html/2602.10479v1] This rival explanation is only partly rebutted by the evidence gathered: the Microsoft red-team source is independent of vendor marketing incentives and documents the same underlying primitives (SBOM generation, provenance verification, cryptographic inter-agent identity) as concrete post-incident mitigations rather than product features, which weighs against a pure-marketing explanation but does not eliminate the possibility that vendor language shaped which mitigations Microsoft chose to describe using similar terminology. [inference; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]

A second rival explanation applies specifically to the HITL-bypass finding: rather than reflecting a genuine gap between machine-to-machine governance maturity and human-consent-boundary governance maturity, the finding could instead reflect testing-selection bias, since red-team engagements may simply choose to probe human-consent bypass more often, or find it easier to elicit, than cryptographic supply-chain or provenance-verification attacks. [inference; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/] The evidence gathered cannot fully distinguish between these two explanations because the source reports exploitation frequency across engagements rather than a controlled comparison of attacker effort or engagement scope across the two governance domains; both a genuine maturity gap and a testing-selection artefact remain consistent with the reported data, so the HITL-bypass finding is treated here as a documented exploitation pattern rather than as confirmed evidence of a comparative governance-maturity deficit. [inference; source: https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/]

The relationship between lower-level agent mechanics and higher-order operational patterns is best explained by treating the two as different levels of a composition hierarchy rather than as competing classification schemes: Reflection, Tool Use, Planning, and Multi-Agent Collaboration are the mechanisms an individual agent or agent pair executes, while the governance layer, tool registry, and coordination substrate are structural solutions to problems that only appear once multiple such mechanisms, multiple agents, or multiple execution sessions interact over time. [inference; source: https://arxiv.org/html/2601.19752v1; https://arxiv.org/html/2602.10479v1] The continuous-evaluation pattern's motivating evidence (standard metrics missing most production failure modes) is strong, but the proposed solution (PAEF) is a single research artifact rather than a pattern already observed recurring across multiple independent production deployments, so it is analysed here as a well-evidenced problem with an emerging, not yet generalised, solution pattern. [inference; source: https://arxiv.org/html/2605.01604]

Risks, Gaps, and Uncertainties

The MCP registry provenance mechanism has been validated only in a controlled, synthetic attack simulation; whether the reported 0.61 ms overhead and 100 percent attack-rejection rate hold under real adversarial conditions with unknown attack strategies at production scale is not established by the evidence gathered. [fact; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157]

The event-driven coordination substrate's generalisability claim rests on a single vendor engineering article rather than an independently peer-reviewed architectural study; whether the four documented topologies (orchestrator-worker, hierarchical, blackboard, market-based) exhaust the space of production coordination patterns, or whether additional topologies exist that this source did not cover, is unknown from the evidence gathered. [assumption; source: https://www.confluent.io/blog/event-driven-multi-agent-systems/]

The Planner-Executor-Reviewer specialisation finding is scoped to a single systematic literature review of software-engineering agents; whether an analogous dominant specialisation pattern exists in other application domains such as customer support, finance, or healthcare agentic systems was outside this item's evidence base and is not established here. [fact; source: https://arxiv.org/html/2605.15245v1]

The Planner-Executor-Reviewer finding rests on a substitute source (arXiv:2605.15245v1) selected because the originally seeded review was inaccessible in this session; whether the substitute's conclusions fully represent the original seed's scope is not established, so the finding's generalisability is bounded by the single substitute review's own methodology rather than by the union of both reviews. [assumption; source: https://arxiv.org/html/2605.15245v1]

No source in this item quantifies the operational or engineering cost of adopting the event-driven coordination pattern or the continuous-evaluation pattern at a level comparable to the MCP paper's per-operation cryptographic overhead figure, so a cross-pattern cost-benefit comparison could not be constructed from currently available evidence. [assumption; source: https://econpapers.repec.org/RePEc:gam:jftint:v:18:y:2026:i:5:p:243-:d:1935157]

Open Questions

Does an analogous dominant agent-specialisation pattern (comparable to Planner-Executor-Reviewer in software engineering) exist in other agentic application domains such as customer support, finance operations, or healthcare, and if so, does it share the same later-lifecycle-phase maturity concentration?
What is the field-measured (not synthetic-simulation) overhead and attack-rejection rate of MCP registry cryptographic-provenance mechanisms once deployed against real, adaptive adversaries rather than fixed simulated attack sets?
Under what conditions, if any, has the PAEF continuous-evaluation framework (or an equivalent) been independently adopted or replicated by a second organisation, and does that adoption change the failure-detection lag reported in the original paper?
What quantified engineering or operational cost differentiates adopting an event-driven coordination substrate versus a simpler orchestrator-worker topology at a given multi-agent scale threshold?

Output

(Fill in when completing: what was produced as a result of this research?)

Type: knowledge
Description: A synthesis of three higher-order operational patterns recurring across production agentic AI systems, i.e., cross-cutting policy-gated governance and typed tool registries, event-driven multi-agent coordination substrates, and continuous production-traffic evaluation, distinguished from lower-level agent mechanics such as prompting, tool use, and planning that these patterns compose. [inference; source: https://arxiv.org/html/2602.10479v1; https://www.confluent.io/blog/event-driven-multi-agent-systems/; https://arxiv.org/html/2605.01604]
Links: https://arxiv.org/html/2602.10479v1; https://www.microsoft.com/en-us/security/blog/2026/06/04/updating-taxonomy-failure-modes-agentic-ai-systems-year-red-teaming-taught-us/; https://www.confluent.io/blog/event-driven-multi-agent-systems/