Agentic Design Patterns: What the Field Has Named, and What It Hasn’t

By Tahir  /  OpenBox AI

Enterprise leaders responsible for AI governance are making consequential procurement and deployment decisions about agentic AI without a shared evaluation framework. Security and technology executives face competing vendor claims, inconsistent architectural terminology, and agentic systems whose behavioral properties are difficult to characterize before deployment and challenging to verify during a regulatory audit.

The underlying problem is structural. The field lacks agreed-upon nomenclature for the architectural approaches being built, deployed, and audited across regulated industries. Without consistent terminology, procurement reviews become subjective, AI governance programs rely on narrative reconstruction, and risk assessments cannot be compared across vendors.

Mature engineering disciplines solve this problem through design patterns. A pattern is not a product, a framework, or a proprietary technique. It is a named, recurring solution to a well-defined structural problem. Once a solution carries a name, practitioners can reference it with precision, auditors can verify its presence or absence, and architects can reason about system properties without examining every line of implementation code.

Agentic AI now has a partial pattern vocabulary. In March 2024, Andrew Ng synthesized four agentic design patterns that gave the field its first stable architectural framework: Reflection, Tool Use, Planning, and Multi-Agent Collaboration. That framework is useful and largely accurate. It is also, in one critical respect, incomplete: the four patterns describe how agents reason and act. None of them addresses how agents are governed. This article identifies that AI governance gap and proposes two patterns to close it.

What Is an Agentic Design Pattern?

The concept of a design pattern originates in building architecture. In their 1977 work A Pattern Language, Christopher Alexander, Sara Ishikawa, Murray Silverstein, and their colleagues documented recurring solutions to design challenges encountered across towns, buildings, and rooms. Their core insight was direct: when skilled builders encounter the same design problem repeatedly and resolve it well, the solution deserves a name. Once named, practitioners can reference and extend it without reconstructing the underlying argument each time.

Software engineering adopted that logic in 1994, when Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, known collectively as the Gang of Four, published Design Patterns: Elements of Reusable Object-Oriented Software. Their catalog of twenty-three patterns did not change what experienced engineers knew. It changed what they could say to each other. Once a solution carries a recognized name, a team can invoke it precisely and proceed.

The same logic now applies to agentic AI. When the field agrees on a recognized vocabulary for agentic design patterns, AI governance becomes actionable at a level of abstraction above the implementation. An auditor can ask whether a deployed system implements the Planning pattern with bounded execution that can be independently verified. That is a tractable question. Asking an auditor to reconstruct agent decision-making from a large orchestration codebase is not.

Why Agentic Design Patterns Matter for Enterprise AI Governance

For engineers, agentic design patterns provide a shared vocabulary. For enterprise AI governance, risk, and compliance functions, they provide an audit surface that is portable, legible, and not dependent on access to proprietary implementation details.

Procurement teams evaluating agentic AI vendors can ask which patterns their systems implement and what architectural constraints those implementations carry. This converts broad assurance claims about vendor compliance into a set of specific, verifiable commitments. Pattern-level due diligence advances AI compliance goals in a way that general safety attestations cannot.

For AI governance auditors, the pattern vocabulary makes the right questions obvious. Because agentic systems can act without direct human involvement, auditors must understand the architecture behind those actions. Was a Reflection loop in place before a consequential decision was committed? What tool access did the agent hold at execution time? Was the plan subject to review before execution began? These are pattern-level questions. They do not require access to proprietary model internals.

Architectural review teams benefit equally. Working at the pattern level, a reviewing team can ask whether the Reflection loop is bounded, whether Tool Use is scoped to authorized systems and data sources, and whether Multi-Agent Collaboration defines explicit trust boundaries between participating agents. These questions are considerably more tractable when posed at the pattern level than when derived from implementation code alone, and they can be answered before deployment rather than after an incident.

The regulatory dimension reinforces all of these considerations. The EU AI Act, the NIST AI Risk Management Framework, and ISO/IEC 42001 each require organizations deploying high-risk AI systems to demonstrate that consequential automated decisions are subject to auditable controls.1 None of those frameworks specifies implementation details. Each requires evidence of structured and repeatable governance. Named agentic design patterns provide a practical vocabulary for producing and documenting that evidence across the enterprise AI governance program.

The Four Canonical Agentic Design Patterns

In March 2024, Andrew Ng synthesized approaches that the research and engineering community had been developing independently for several years, providing the field with its first stable and widely referenced named framework.2 The four canonical agentic design patterns are Reflection, Tool Use, Planning, and Multi-Agent Collaboration. Credit for the names belongs to Ng’s synthesis; the underlying approaches were already in active use.

Reflection is the agentic design pattern in which an agent generates an initial output, evaluates that output against its own reasoning, and revises before committing the result. The self-critique may be performed by the same model instance or delegated to a second agent acting as an evaluator.

In a claims-processing environment, the agent reviews its recommendation to approve, deny, or escalate a claim against applicable policy terms and the claimant record before writing the result to the system of record. Reflection reduces the frequency with which flawed reasoning reaches consequential outputs. It is not a guarantee of correct decisions.

Tool Use is the agentic design pattern that extends an agent’s effective reach by invoking external systems: APIs, databases, search engines, code interpreters, and operational platforms. A claims-processing agent may call a claims management API, retrieve policy documents from a document repository, and query a fraud-detection database within a single reasoning cycle.

Because tools operate on live systems and can produce irreversible effects, Tool Use is where agent governance concerns become most immediate. Every tool invocation can cross an authorization boundary or trigger an audit requirement, and the four canonical patterns do not collectively specify how those crossings should be governed.

Planning is the agentic design pattern that decomposes a complex goal into a sequence of subtasks, reasons about their dependencies, and coordinates execution across those subtasks. Approaches in this pattern interleave reasoning with action, producing a trace that is partially inspectable before execution completes.

A logistics agent coordinating routing, inventory allocation, and delivery scheduling across a distribution network exemplifies this pattern: it breaks a compound operational goal into discrete components and assembles their outputs into a coherent plan. For AI governance purposes, the plan itself is an auditable artifact: a structured record of the agent’s intended course of action before any consequential step is taken.

Multi-Agent Collaboration is the agentic design pattern that coordinates multiple agent instances, each holding a distinct role, toward a shared objective. The logistics scenario extends naturally: a routing subagent, an inventory subagent, and a scheduling subagent each produce specialized outputs that an orchestrating agent assembles into a final operational recommendation.

Multi-Agent Collaboration increases capability and governance complexity together. Every inter-agent communication channel is a potential point of policy drift, and reconstructing the provenance of a final action becomes substantially more difficult when multiple agents have contributed to its production.

The AI Governance Gap in the Current Agentic Design Pattern Framework

The four agentic design patterns describe how agents reason, interact with external systems, decompose objectives, and coordinate distributed work. None addresses the question that AI governance leaders must answer before, during, and after a regulatory audit: what the agent did, why it did it, and whether that evidence can withstand adversarial scrutiny.

The gap is concrete. Consider a payment authorization agent operating in a financial services environment. Once executed, a payment is effectively irreversible. The four canonical agentic design patterns describe how such an agent might reason, invoke payment systems, and coordinate across services.

They do not address how to intercept a proposed payment before execution, verify the agent’s authorization to act, confirm that the action falls within defined policy boundaries, or record the resulting decision in a manipulation-resistant form. That discipline, pre-execution agent governance, falls entirely outside the current canonical framework.

Practitioners in regulated industries have recognized this gap for several years. Production teams have independently developed runtime guardrails, policy-as-code controls, verifiable credentials, and tamper-evident audit logs. No recognized naming convention for these approaches has emerged. Effective solutions exist, but they have not been classified as agentic design patterns in the established sense of the term.

Several bodies of prior work from the research and practitioner communities illustrate the runtime AI governance approaches that have converged across the field.

Microsoft’s Agent Governance Toolkit, released in April 2026, provides the most complete open-source implementation of agent governance primitives currently available.3

Huang et al., whose work on Safiron was accepted at ICLR 2026, demonstrated that pre-execution governance at the planning stage is an architecturally sound intervention. The system intercepts a planned action before it executes, evaluates whether the plan presents risk, and generates an auditable rationale for its assessment.4

Shamsujjoha et al. of CSIRO’s Data61 established a defense-in-depth framing for agentic AI governance in their 2024 paper. Their central argument is that effective runtime AI governance requires independent control layers across the agent architecture: at input, plan, tool call, and output. No single failure point should expose the full system.5

The SPIFFE project and the decentralized identity community have contributed agent identity primitives now being adapted to agentic AI environments: mechanisms for establishing not only that an action occurred, but which verified agent identity was responsible.6

Taken together, this body of work defines a consistent architectural direction for responsible AI deployment in agentic systems. What it has lacked is a name.

Two Proposed Agentic Design Patterns for Agent Governance

Despite variation in implementation, the approaches emerging across production systems, open-source projects, and academic research share enough structural characteristics to constitute recognizable agentic design patterns in the established sense. The two patterns proposed here represent one way to name and classify that convergent structure. They are a proposal, not a settled classification. A detailed technical examination will follow.

The Attested Action Pattern

The Attested Action Pattern is an agentic design pattern for runtime AI governance at the point of execution. Every consequential agent action is intercepted before execution by a deterministic policy gate. The gate authenticates the agent’s identity using verifiable credentials, evaluates the proposed action against machine-readable policy, and returns one of four decisions: allow, block, require human approval, or halt.

Each decision is cryptographically signed and appended to a tamper-evident audit log.

The pattern composes with the four canonical agentic design patterns rather than replacing them. It can intercept a Tool Use call, the output of a Planning step, or a delegated action within a Multi-Agent Collaboration structure.

Pre-execution governance of this kind is the most direct architectural approach available to prevent an irreversible action rather than merely record that it occurred. An unauthorized payment processed at 3 a.m. or a claims denial issued without human review illustrates the kind of outcome this pattern is designed to stop. Post-hoc observability is not runtime AI governance. It is incident documentation.

The Lineage-Bound Reasoning Pattern

The Lineage-Bound Reasoning Pattern is an agentic design pattern for AI governance earlier in the agent’s decision process. Rather than governing only at the moment of execution, it attests the full chain that produced each action: the plan, the retrieved context, the prior conversation, and the tool composition. This creates verifiable provenance for every consequential decision, not merely a record that a decision occurred.

That provenance supports several AI governance functions that the Attested Action Pattern alone cannot provide. These include prompt injection analysis (did a retrieved document alter agent behavior in an unauthorized way?), plan-level review before execution begins, and counterfactual audit (how would the decision have changed if specific context had been excluded?).

Most agentic deployments in production today cannot answer those questions from their existing audit trails. What they offer is reconstruction from logs not designed for adversarial scrutiny. The difference between reconstruction and verification is the difference between a governance claim and a governance proof.

The Lineage-Bound Reasoning Pattern is more architecturally complex than the Attested Action Pattern, and the research on its implementation is less settled. It represents, nonetheless, the direction toward which enterprise agentic AI governance is developing.

Agentic AI Governance: Naming What the Field Has Already Built

Production teams, open-source contributors, and academic researchers have independently converged on similar pre-execution governance architectures for agentic AI over the past two years. That convergence is evidence of a genuine structural requirement rather than a design preference.

Naming that requirement, with the same discipline the Gang of Four brought to object-oriented design, makes it actionable for enterprise AI governance programs that did not build equivalent solutions independently. The field now has enough accumulated evidence to do that naming with confidence.

A detailed technical write-up of both patterns will be published in the coming weeks.

Tahir is CTO of OpenBox AI, a runtime trust infrastructure platform for agentic systems.

Notes

1 European Parliament, Regulation (EU) 2024/1689 (EU AI Act), Art. 9 (risk management system requirements); NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), January 2023, GOVERN 1.1–1.7; ISO/IEC 42001:2023, Clause 9 (Performance Evaluation).

2 Andrew Ng, “What’s next for AI agentic workflows,” The Batch, DeepLearning.AI, March 2024.

3 Microsoft, Agent Governance Toolkit (released April 2, 2026). Available at github.com/microsoft/agent-governance-toolkit.

4 Huang et al., “Building a Foundational Guardrail for General Agentic Systems via Synthetic Data,” ICLR 2026 (preprint arXiv:2510.09781, October 2025).

5 Shamsujjoha et al., “Designing Multi-Layered Runtime Guardrails for Foundation Model Based Agents: Swiss Cheese Model for AI Safety by Design,” CSIRO Data61 (arXiv:2408.02205, August 2024).

6 SPIFFE (Secure Production Identity Framework for Everyone), spiffe.io; W3C, Decentralized Identifiers (DIDs) v1.0, W3C Recommendation, July 19, 2022.