Stacking Patterns to Build AI Agents

Q: What does it mean to "stack" AI patterns?

Stacking means chaining individual AI patterns so the output of one becomes the input of the next. A single pattern handles one bounded task. A stack handles a sequence of tasks that together constitute a full role, such as attending a call, updating the CRM, and surfacing the rep's next action before the next morning.

Q: How many patterns does it take to build a role-level AI Agent?

The 4-Pattern Assembly framework defines the minimum viable role-level agent as four layers: Ingest/Classify, Retrieve/Score, Generate/Recommend, and Execute/Monitor. Sub-four-layer stacks handle task clusters, not full roles. Both the AI Sales Operator and AI Support Agent examples in this article operate at the four-to-five-layer threshold.

Q: What is the most common failure point in pattern stacks?

Data format mismatches at the handoff between patterns cause the majority of early-stage failures. Pattern A produces free text. Pattern B expects structured JSON. Nothing flows. The fix is to define the handoff schema before building either layer, treating the join contract as a first-class architectural artifact.

Q: Why do so few enterprises successfully scale AI agents to production?

Deloitte's 2025 data shows only 11% of enterprises that pilot AI agents run them in production. The bottleneck is not model capability. It is integration complexity (every pattern needs a connector to every system it reads or writes), governance gaps at the joins between patterns, and the absence of a shared entity model across the stack.

Q: What is the difference between Level 2 patterns and Level 3 AI Agents in the ACE Framework?

Level 2 patterns are stateless and bounded. They receive input, produce output, and own no persistent context. Level 3 AI Agents own a role. They hold persistent state about their domain, accumulate institutional knowledge across runs, and have combined authority across multiple systems. Moving from Level 2 to Level 3 requires data infrastructure and governance design, not just additional patterns.

Q: How do you handle latency in a multi-pattern stack?

Map the latency budget before building. Synchronous copilot interactions require under 2 seconds total. A 5-pattern stack where each step takes 2 seconds exceeds that budget by 8 seconds. The solution is either to reduce pattern depth, parallelize independent layers, or shift the interaction model to async background processing where latency tolerance is 30-60 seconds.

Q: What governance requirements change when patterns are stacked?

Individual patterns have bounded governance: they can take action within their specific capability. Stacks create governance surface at every join. Data flows between patterns, authority compounds, and audit requirements multiply. The generate-vs.-execute boundary from the ACE Framework is the practical starting point: identify every point in the stack where the system takes action in an external system, and design explicit approval gates at those points.

Pattern stacking diagram showing individual AI patterns combining into a role-level AI Agent with data flows between layers

A single pattern does one thing well.

Meeting Intelligence turns call recordings into structured notes and action items. Scoring and Routing classifies inbound leads and assigns them to the right rep. Workflow Copilot surfaces the next-best action in the CRM sidebar. Each of these is a real, deployable capability.

But none of them, alone, is an AI Sales Operator.

An AI Sales Operator attends the call. It updates the CRM, researches the account, drafts the follow-up, monitors deal health, and surfaces the next action when the rep opens the record the following morning. It handles a whole job, not a single task.

The difference between a single pattern and an agent that handles a role is stacking. This article explains the concept, works through two complete examples, and covers where stacks break down and how to design them so they don't.

The concept of stacking

Patterns become building blocks when their outputs become inputs to the next pattern.

Key Facts: AI Agent Stacking in Production

Only 11% of enterprises that pilot AI agents ever run them in production, per Deloitte's 2025 Emerging Technology Trends study. The bottleneck is almost always integration and governance, not model capability.

Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027, citing escalating costs, unclear business value, and inadequate risk controls.

66% of production agent implementations now use multi-agent system designs rather than single-agent approaches, reflecting industry-wide recognition that no single pattern handles a full role. (Landbase, 2026)

Anthropic's Building Effective Agents guide, drawn from dozens of production deployments, makes this explicit: the most capable agentic systems aren't built with a single sophisticated model but by composing simpler patterns in well-defined sequences, where each layer hands structured output to the next.

Stacking is architectural composition, not just feature combination. The output of Meeting Intelligence (structured notes, action items, sentiment, key objections) flows into the Workflow Copilot as context for the next-action suggestion. The CRM update from the Workflow Copilot changes the deal record that Scoring and Routing uses to re-prioritize the rep's pipeline. Each pattern advances the work further along the job cycle.

The key design insight: the join between patterns is where most stacking failures happen. Not the patterns themselves. The handoffs between them.

If Meeting Intelligence produces a free-text summary and Workflow Copilot expects a structured JSON object with specific fields, nothing flows. If the latency budget assumes each pattern responds in 200 milliseconds but the Autonomous Agent step takes 8 seconds, the whole stack violates the user experience requirements. If an error in pattern 2 passes silently to pattern 3, the downstream patterns optimize from corrupted input without knowing it.

Good stacking design means designing the joins as carefully as the patterns.

"Multi-agent implementations where each layer validates its input before processing achieve 3x lower error propagation rates than stacks that pass outputs downstream without validation. The join is the architecture." (Shakudo Enterprise AI Production Report, 2026)

So what changes when patterns combine into a full agent? The next section explains the distinction.

Level 2 vs Level 3

The ACE Framework distinguishes between patterns at Level 2 and AI Agents at Level 3 along three dimensions:

Scope: Level 2 patterns solve specific, bounded tasks. Level 3 Agents own a role. An AI Sales Operator owns the rep's workflow. An AI Support Agent owns the support queue. The Agent's scope spans the entire job function, not individual tasks within it.

Data authority: Level 3 Agents hold persistent state about their domain. The AI Sales Operator knows the full deal history, the rep's performance patterns, which outreach templates have worked in which industry segments. That institutional knowledge accumulates across runs and informs subsequent ones. Individual Level 2 patterns are stateless: they receive input and produce output without accumulating context.

Governance surface: Level 2 patterns have bounded authority. They can do what their specific capability does. Level 3 Agents have combined authority across multiple capabilities and multiple systems. Their governance requirements are proportionally more complex. The approval gates, audit trails, and scope constraints that apply to each pattern multiply at the Level 3 layer.

Moving from Level 2 to Level 3 is not a matter of adding more patterns.

It's a design decision to give a system ownership of a role, with the data infrastructure and governance architecture that ownership requires. McKinsey's research on seizing the agentic AI advantage confirms this framing: fewer than 10% of enterprises that experiment with agents ever scale them, and the gap is almost always infrastructure and governance, not model capability.

"Enterprises that treat Level 3 agent deployments as a feature addition rather than a role ownership decision see a 4x higher project cancellation rate in year two than those that scope the governance and data infrastructure first." (McKinsey QuantumBlack, 2025)

The two worked examples below show what that infrastructure actually looks like in practice.

Worked example 1: AI Sales Operator

The AI Sales Operator stacks five patterns: Meeting Intelligence, RAG Assistant (Retrieval-Augmented Generation), Scoring and Routing, Workflow Copilot, and Anomaly Agent. Here's how each layer contributes and how they hand off.

Layer 1: Meeting Intelligence

What it does: Ingests the call recording, transcribes, extracts action items, key objections, and deal signals.
In this context: Every sales call flows through Meeting Intelligence automatically. Output is a structured record with transcript, action items, sentiment analysis, and objections tagged by ACE category.
Output to next layer: Structured call summary with key fields: deal stage, objections raised, next steps committed, prospect's stated timeline, rep's name.

Layer 2: Workflow Copilot

What it does: Takes the call summary plus existing CRM context and generates the next-best action for the rep.
In this context: As soon as the call ends, the rep opens the CRM record and sees the draft follow-up email, the updated stage recommendation, and the action checklist from the call.
Input from layer 1: Structured call summary. The Workflow Copilot cannot ingest raw audio or raw transcript. The Meeting Intelligence output must be structured correctly for the Copilot to use it.
Output to next layer: Rep reviews and approves actions. CRM record is updated with new stage, notes, and next task.

Layer 3: Scoring and Routing

What it does: Re-scores the deal based on updated signals and re-prioritizes the rep's pipeline.
In this context: After each CRM update, the Scoring model re-calculates the deal score (combining recency, engagement signals, stage, and firmographic data). The rep's pipeline view re-orders automatically.
Input from layer 2: Updated CRM record fields. Specifically, the stage update and the action completion signals.
Output to next layer: Updated priority ranking in the rep's pipeline view. High-priority deals surface to the top.

Layer 4: RAG Assistant

What it does: Surfaces relevant product documentation, case studies, and objection-handling playbooks based on the rep's active context.
In this context: When the rep has a "compliance objections raised" flag on a deal, the RAG Assistant surfaces the three most relevant case studies from regulated industries and the standard compliance objection playbook.
Input: The deal record context, specifically the objection tags from Meeting Intelligence and the industry segment from CRM firmographics.
Output: Document snippets with links, visible in the CRM sidebar when the rep is working on the deal.

Layer 5: Anomaly Agent

What it does: Monitors deal health over time and flags abnormal patterns.
In this context: If a deal that was at 85% confidence 10 days ago has had no engagement in 12 days, the Anomaly Agent flags it as "deal at risk" and triggers a Workflow Copilot re-engagement suggestion.
Input: Historical engagement signals, deal stage progression rates across the full pipeline.
Output: Alert surfaced to rep and manager with suggested recovery action.

This five-layer stack is what makes the AI Sales Operator feel like a role, not a feature. None of the individual patterns, deployed alone, produces this experience. The integration is the product. For the ROI case that makes this stack worth building, why sales ops is the highest-ROI AI use case breaks down the numbers.

For a deeper look at what the AI Sales Operator does across the rep's full day, see What Is an AI Sales Operator.

Worked example 2: AI Support Agent

The AI Support Agent stacks five patterns differently: Scoring and Routing, RAG Assistant, Document Review, Workflow Copilot, and Autonomous Agent. The handoffs work differently because the support use case has a different shape.

Layer 1: Scoring and Routing

What it does: Receives every incoming ticket, classifies it by type (billing dispute, technical issue, feature request, escalation), scores urgency, and routes to the right queue.
In this context: High-urgency billing disputes go to the Autonomous Agent path. Technical issues above a complexity threshold route to a senior agent. Low-urgency standard requests go to the RAG-assisted self-service path.
Output to next layer: Ticket with classification tags, urgency score, and routing decision.

Layer 2: RAG Assistant (for Tier 2+ tickets routed to humans)

What it does: For tickets handled by human agents, the RAG Assistant surfaces the 3 most relevant past resolutions from the knowledge base.
In this context: The human agent sees the ticket and, in the same interface, the top 3 resolution suggestions with similarity scores and the specific resolution steps used.
Input: Ticket text and classification tags from Scoring and Routing.
Output: Suggested resolutions surfaced to the human agent as context.

Layer 3: Workflow Copilot (for human agents on complex tickets)

What it does: During the human agent's active work on a ticket, the Copilot suggests the next response draft, the correct macro to apply, and any missing fields to fill before closing.
In this context: As the human agent types a response, the Copilot surfaces a pre-drafted version based on the ticket context and the RAG-retrieved resolution pattern.
Input: Active ticket context, human agent's current cursor position, and RAG output from layer 2.
Output: Response draft and checklist for the human agent.

Layer 4: Document Review (for regulated industries)

What it does: Reviews the draft response before it's sent, checking for compliance requirements (FINRA language, HIPAA disclosures, required disclaimers).
In this context: For financial services and healthcare customers, every response draft passes through Document Review before it can be submitted.
Input: Draft response from Workflow Copilot.
Output: Approved/flagged status, with flagged items highlighted and corrected language suggested.

Layer 5: Autonomous Agent (for Tier 1 structured resolutions)

What it does: Handles the Tier 1 tickets that Scoring and Routing identified as resolvable without human involvement (billing disputes under threshold, standard refund requests, password reset flows).
In this context: The Autonomous Agent has access to the payment processor API, the ticket system, and the email sender. It reads the ticket, verifies the claim, issues the resolution, closes the ticket, and sends confirmation.
Input: Structured ticket with classification tags and authorized resolution scope.
Output: Closed ticket with resolution log and customer confirmation sent.

This stack illustrates a key design pattern: not all tickets go through all layers. The Scoring and Routing decision at layer 1 determines which downstream layers a given ticket passes through. The Autonomous Agent handles a specific, bounded subset. Human-assisted layers handle the rest.

The 4-Pattern Assembly Framework

The 4-Pattern Assembly is a named architecture for building role-level AI Agents from exactly four pattern layers: (1) an Ingest/Classify layer that structures raw input, (2) a Retrieve/Score layer that enriches with context, (3) a Generate/Recommend layer that produces the human-facing output, and (4) an Execute/Monitor layer that acts on approvals and flags drift. Any agent that handles a full role can be mapped to these four positions. Patterns below four layers handle tasks. Patterns at four layers or above handle roles.

Rework Analysis: Based on the two worked examples in this article and production patterns documented by McKinsey, Gartner, and Anthropic, agents that reach the 4-Pattern Assembly threshold (Ingest, Retrieve, Generate, Execute) show consistently higher adoption retention than sub-4-layer stacks. Rework's implementation data shows that sales teams using a full 4-layer AI Sales Operator reduce average deal-cycle admin time by 60-70 minutes per rep per day, compared with 15-20 minutes for teams using a single-pattern copilot only.

Where stacks break down

Data format mismatches between patterns. Pattern A produces a free-text summary. Pattern B expects a structured JSON object. Nothing flows. The fix is not to blame either pattern. It's to design the schema of the handoff before building either layer. The handoff contract is the most important piece of the architecture.

Latency compounds. A 5-pattern stack where each pattern takes 2 seconds to respond takes 10 seconds before the user sees anything. McKinsey's analysis of reimagining tech infrastructure for agentic AI highlights latency compounding as one of the most underestimated challenges when moving from single-model to multi-agent deployments. In a copilot context where the user is actively waiting, 10 seconds is too long. In an async background process (post-call CRM update), 10 seconds is fine. Map the latency budget against the user experience requirement before committing to the stack depth.

Error propagation. A wrong output from pattern 2 is the input to pattern 3. If pattern 3 doesn't validate the input, it optimizes from corrupted data and produces a wrong output that flows to pattern 4. By the time the error surfaces, it's been multiplied. The fix is input validation at every layer, not just at the initial entry point. Each pattern should reject malformed or low-confidence inputs rather than trying to proceed.

Governance gaps at the joins. A governance policy might cover each individual pattern's Execute actions. But who approved the data flowing from Meeting Intelligence to Workflow Copilot? Who authorized the Scoring and Routing re-prioritization to happen automatically based on an AI-generated action item from a call? The joins between patterns create governance surface that the patterns' individual policies don't cover. Design the governance at the join, not just at the pattern level. The generate vs. execute boundary is the clearest place to start this conversation.

Failure mode	Where it typically surfaces	Mitigation
Data format mismatch	At the first handoff between patterns	Define handoff schemas before building; validate at every layer
Latency budget exceeded	After full stack is assembled	Benchmark each pattern independently; model total latency before deploying
Error propagation	Downstream from the first bad output	Input validation at every layer; low-confidence inputs should escalate, not pass silently
Governance gaps at joins	At the approval and audit design phase	Map governance requirements for each data flow, not just each pattern output
Shared entity model drift	When patterns reference the same "contact" or "deal" differently	Single entity model shared across all patterns; enforce at the data layer

Design principles for pattern stacks

Modular. Each pattern should be replaceable without rebuilding the entire stack. The Meeting Intelligence layer can be upgraded to a better model without changing the Workflow Copilot or Scoring and Routing layers, as long as the output schema stays consistent. Treat each layer as a contract with defined inputs and outputs, not as tightly coupled components.

Observable. Every handoff between patterns should be logged. Not just the final output. The full data flow: what the pattern received as input, what it generated, what it sent to the next layer, and when. Observability at the joins is the only way to debug the stack when something goes wrong. Logging only at the terminal output tells you what the final result was, not where the error originated.

Gracefully degrading. If the Anomaly Agent is unavailable (model timeout, API outage), the rest of the stack should continue working. The rep's Workflow Copilot should still surface next actions. The Meeting Intelligence should still update the CRM. Only the anomaly monitoring surface should go dark, with a visible indicator that alerts are temporarily paused. Design each layer's failure mode explicitly. A layer that's unavailable should produce a null output with a failure flag, not an error that crashes the stack.

Stack depth	Typical use case	Avg. latency (sync)	Error propagation risk	Governance complexity
1 pattern	Single task (transcription, routing, drafting)	Under 2s	Low	Simple
2-3 patterns	Task cluster (call + CRM update)	3-6s	Medium	Moderate
4-5 patterns (role-level)	Full function ownership (AI Sales Operator)	6-15s async OK	High without validation	Complex
6+ patterns	Cross-function orchestration	Async only	Very high	Requires dedicated governance layer

"The median time-to-value for enterprise AI agent deployments is 5.1 months, with sales development agents paying back in 3.4 months. Finance and ops agents average 8.9 months. Stack depth and data readiness are the primary variables, not model selection." (Landbase Agentic AI Report, 2026)

Prerequisites before stacking

Before building a multi-pattern stack, three infrastructure conditions need to be in place:

Shared data pipeline. All patterns in the stack need access to the same data store with consistent schemas. If Meeting Intelligence writes to one database and Scoring and Routing reads from another, the stack is siloed. The data pipeline is the connective tissue.

Shared entity model. Every pattern must reference the same definition of "contact," "deal," "ticket," or whatever the central entity is. If Meeting Intelligence knows a contact by their email address and Scoring and Routing identifies them by CRM record ID, the join breaks the moment a contact exists in one system but not the other.

Defined latency budget. Know the acceptable response time for the user experience you're building before assembling the stack. Copilot interactions are synchronous and have tight latency requirements (under 2 seconds). Background processing (post-call CRM updates) can tolerate 30-60 seconds. The stack depth must fit within the budget.

The path to Level 3

The worked examples in this article are the beginning of what the ACE Framework calls Level 3: AI Agents at the role level. The AI Sales Operator and AI Support Agent are both Level 3 constructs, each built by stacking Level 2 patterns with the right data infrastructure and governance architecture.

The progression from Level 2 to Level 3 is the progression from "AI that does tasks" to "AI that owns a function." That progression requires the infrastructure and design discipline described above. It's not a threshold you cross by adding one more pattern to a stack.

For the patterns that require careful prerequisites before they can participate in a stack, see Pattern Dependencies and Prerequisites. For where stacks work by department, see Pattern Combinations by Department.

AI Patterns