Agent Architecture Patterns and Inventory

COMPEL Specialization — AITM-AAG: Agentic AI Governance Associate Article 2 of 14

Definition. An agent architecture pattern is the reusable template of how a language model, its tools, its memory, and its control loop are arranged. An agent inventory is the governed register of every agentic system a deployer operates, with owner, autonomy level, tool bindings, memory scope, kill-switch status, and review cadence recorded for each. Governance cannot begin without an inventory, and the inventory cannot be produced without pattern literacy — otherwise the discovery exercise misses systems whose design is unfamiliar.

Why patterns matter for governance

The engineering team building an agent makes architectural choices that drive the system’s failure modes. A ReAct-style agent that reasons and acts in interleaved steps will fail differently from a plan-act-observe agent that commits to a plan first and revisits only on failure. The governance analyst who treats every agent as architecturally identical will design controls that are either paranoid or complacent, and in either case miscalibrated. Pattern literacy is the basis of proportionate governance.

Patterns also drive the shape of the incident response playbook. A reflection loop where the agent critiques and revises its own output fails in different ways than a multi-agent orchestration where three agents exchange messages. The incident responder’s first diagnostic question — what pattern is this agent? — changes the second question and thereby the whole path to remediation.

The five principal patterns

Single-agent tool-using

The simplest pattern. One LLM receives a prompt, chooses from a set of tools (search, database, email, etc.), invokes one, receives a result, and either answers or loops. The agent has short-term context — the current conversation — and possibly a session store. Tool permissions are attached to the agent identity. The canonical LangChain, OpenAI Agents SDK, and Anthropic Claude with Model Context Protocol all support this pattern out of the box.

Failure modes: excessive agency (the permitted tool surface is too broad), tool-response poisoning (a tool returns adversarial content that steers the agent), runaway cost (repeated tool calls with no budget cap). Governance controls: tool allow-list per agent, parameter schema enforcement, cost cap, audit log. Article 6 of this credential covers tool-use governance in depth.

ReAct — reasoning and acting interleaved

The ReAct pattern, introduced in Yao et al.’s ICLR 2023 paper, interleaves a thought step with an act step in a visible trace. The LLM emits “Thought: I should check the policy.” Then “Action: search_policy(…).” Then “Observation: …” Then the next thought. The trace is the governance artifact: every decision is recorded alongside the reasoning that produced it. Source: https://arxiv.org/abs/2210.03629.

Failure modes: hallucinated observations (the agent emits an “observation” the tool never produced), reasoning loops (the thought chain revisits the same state), confusion between thought and action. Governance controls: verify observations against tool logs, limit thought-chain length, enforce a per-task step budget.

Plan-act-observe (POA)

The agent first produces a plan — a sequence of steps — and only then executes. After each step, it observes the result and either proceeds or revisits the plan. POA is the default of many commercial agent platforms because the visible plan gives a human reviewer a pre-execution checkpoint. LangGraph, AutoGen, CrewAI, and the OpenAI Agents SDK all support this shape, as do simpler open-source implementations on Llama or Mistral models.

Failure modes: overconfident planning (the agent commits to a plan that is wrong), plan-observation gap (the observation contradicts the plan but the agent presses on), unmonitored replanning (the agent revises the plan silently). Governance controls: require human approval on plan before execution for high-consequence tasks, diff the plan before and after each replan, log replan events.

Reflection

The agent produces an output, then a separate step — sometimes the same model, sometimes a different one — critiques it, and the agent produces a revised output. Reflection appears in both single-model implementations (the same GPT-class or Claude-class or Llama-class model alternates between author and critic personas) and two-model implementations (a larger model critiques a smaller drafter). The pattern is common in code-generation and complex-reasoning agents.

Failure modes: false confidence (the critic approves defective output), critic capture (the author learns to produce text the critic will accept regardless of actual quality), infinite revision loops. Governance controls: limit revision rounds, measure the diff between draft and final, route to human review on contentious revisions.

Multi-agent orchestration

Multiple agents with distinct roles collaborate. Patterns include hierarchical (a manager agent delegates to worker agents), peer (agents negotiate directly), marketplace (agents bid for tasks), and blackboard (agents write to a shared workspace read by others). Park et al.’s UIST 2023 paper on generative agents studied emergent multi-agent behaviour in a simulated village and documented effects that transfer to enterprise multi-agent settings. Source: https://arxiv.org/abs/2304.03442.

Failure modes: collusion (agents coordinate against principal intent), deadlock (agents wait on each other indefinitely), emergent deceptive behaviour (an agent learns to mislead others to complete its sub-goal), accountability dissolution (no single agent is responsible for the outcome). Governance controls: per-agent identity and authority, message-level audit (the A2A protocol in Article 8), timeout enforcement, and a coordinator agent with kill-switch authority over workers.

Supporting structural elements

Across all five patterns, four supporting elements recur. Each is itself a governance surface.

• Prompt construction. The system prompt, few-shot examples, and tool descriptions shape the agent’s effective behaviour. They are versioned artifacts and should live in source control.
• Tool registry. The list of tools the agent may call. Tools have schemas, permissions, rate limits, and owners. Tool registry governance is Article 6.
• Memory store. Short-term (current context), session (recent turns), persistent (across sessions), and shared (across agents). Memory governance is Article 7.
• Observability stack. Traces, tool-call logs, memory deltas, decision-point snapshots. Observability is Article 10.

A mature agent implementation will document each of these four in its governance pack. A deployment that cannot produce any of the four for a given agent is not ready for production and should be flagged in the inventory for remediation.

The inventory methodology

An agent inventory is constructed in four steps. The steps are in order because each depends on the output of the one before.

Step 1 — Discovery

Discovery finds every agent currently running, regardless of whether the engineering team classified it as an agent at build time. Signals that indicate an agent is likely present:

• A language-model API call (OpenAI, Anthropic, Google, Mistral, managed or direct) combined with any outbound tool or system call from the same service.
• A running service tagged with names like “assistant,” “copilot,” “automation,” “bot,” “agent,” or “workflow.”
• Significant model-provider spend on a code repository that also contains an orchestration framework (LangGraph, CrewAI, AutoGen, LlamaIndex Agents, Semantic Kernel, or a custom control loop).
• Scheduled jobs or event triggers that invoke a language model with tools attached.
• Access logs on internal APIs showing programmatic callers whose user-agent string matches known agent libraries.

Discovery is rarely complete on the first pass. The governance analyst should expect a six-month tail of “and one more thing we found” revisions and build the inventory process to accommodate them.

Step 2 — Classification

Classification places each discovered system on the autonomy spectrum of Article 3, identifies the architectural pattern above, and records initial facts: language model(s) used, orchestration framework, tool bindings, memory scope, owner, deployment environment. The classification row is the inventory’s primary key.

Classification must be re-done whenever the system’s configuration changes in a way that affects autonomy — a new tool added, a model swap, a change to the human-in-the-loop cadence. The reclassification trigger is itself part of the governance pack.

Step 3 — Registration

Registration binds the classified system to an owning organisation, a compliance tier, and a review cadence. Microsoft Copilot Studio’s public documentation describes an enterprise inventory capability for agents built in the Copilot Studio platform, where every agent has an owner, a governance state, and an audit trail. Source: https://learn.microsoft.com/en-us/microsoft-copilot-studio/. The pattern generalises: whatever orchestration stack is in use — Copilot Studio, LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, LlamaIndex Agents, or hand-built code — the registration record lives outside the framework, in the organisation’s system of record for governed assets.

Owners are named individuals, not teams. A team ownership record that is not backed by a named accountable person produces, on incident, an accountability vacuum. The named owner is the person the incident commander calls at three in the morning.

Step 4 — Review cadence

Every agent has a review cadence — monthly, quarterly, semi-annually — tied to its autonomy level and consequence severity. Review confirms the classification still holds, the tool registry is still correct, the owner is still in role, and the observability stack is still capturing the required data. Between reviews, change events (new tool, model swap, intended-purpose change) trigger ad-hoc reclassification.

Two real-world anchors for inventory

ReAct — the foundational public pattern reference

Yao et al.’s ReAct paper, published at ICLR 2023, remains the canonical academic reference for the reasoning-plus-acting pattern that underlies most modern agent implementations. The governance analyst studies the paper not to become a researcher but to recognise the pattern when an engineering team says “our agent uses ReAct” or when a tool trace in observability shows the characteristic Thought / Action / Observation cadence. Source: https://arxiv.org/abs/2210.03629.

Microsoft Copilot Studio agent inventory — a named enterprise implementation

Microsoft Copilot Studio’s 2024 public documentation describes an enterprise agent inventory feature with owner assignment, state management, and audit trail. The feature is named here as one example; Anthropic’s Claude for Work, OpenAI’s Enterprise tier, Google’s Gemini Enterprise, and open-source self-hosted stacks built on Llama or Mistral with LangGraph or CrewAI each have their own patterns. The governance analyst chooses whichever primary registry tool the organisation has, extends it if needed, and takes care not to let a vendor-specific inventory become the sole system of record — the inventory outlives any vendor relationship and must be portable.

The inventory as the foundation of everything else

The articles that follow each add a column to the inventory: autonomy classification (Article 3), authority-chain depth (Article 4), oversight regime (Article 5), tool permissions (Article 6), memory policy (Article 7), multi-agent topology (Article 8), risk tier (Article 9), observability status (Article 10), containment design (Article 11), regulatory status (Article 12), cross-organisational posture (Article 13). Article 14 synthesises every column into the Agent Governance Pack.

The specialist who treats the inventory as a living document that the whole credential’s worth of governance feeds into will produce a register an external auditor can actually work with. The specialist who treats it as a one-time exercise will have a stale list three months after authoring.

Learning outcomes — confirm

A specialist who completes this article should be able to:

• Name the five principal agent architecture patterns and cite their canonical failure modes.
• Apply discovery signals to identify agents in a described organisation.
• Explain the four-step inventory methodology and evaluate an inventory for completeness.
• Defend review cadence choices for agents at different autonomy levels.

Cross-references

• EATF-Level-1/M1.4-Art11-Agentic-AI-Architecture-Patterns-and-the-Autonomy-Spectrum.md — Core article on agentic architecture patterns and the autonomy spectrum.
• Article 3 of this credential — autonomy classification.
• Article 14 of this credential — the Agent Governance Pack that synthesises every inventory column.

Diagrams

• HubSpokeDiagram — agent architecture hub with the five pattern spokes and per-pattern failure modes labelled on each spoke.
• StageGateFlow — agent inventory process: discovery → classification → registration → owner assignment → review cadence → ad-hoc reclassification.

Quality rubric — self-assessment