Patterns & Practice: Chapter Recap

The decision tree. The pattern reference. The place where every IDAM analogy breaks.

Seven patterns. Four questions. One table that maps every AI analogy back to the IDAM concept it resembles — and names exactly where the resemblance ends. Use this before a planning meeting, not instead of the lessons.

The Decision Tree

Four questions, in order. The first "yes" that routes you to a pattern is your answer — stop there.

#	Question	If YES	If NO
1	Is the knowledge already in the model?	Proceed to Q3	RAG loop required → proceed to Q2
2	Is the path predictable?	Workflow pattern	Agent loop → proceed to Q4
3	Does it need tools or external actions?	Function calling / MCP	Direct generation (prompt engineering)
4	Does it need to adapt its approach mid-task?	Agent loop with state management	Deterministic multi-step workflow

Most enterprise AI use cases fail Q1 (the model doesn't know the buyer's internal data), which means RAG is almost always in the picture. The real fork is Q2. Predictable path means workflow; unpredictable path means agent. Q3 and Q4 are refinements, not new forks.

Buyers reach for agents when they mean workflows. Q2 is where you catch that.

If you remember nothing else from this chapter: the question "do we need an agent?" resolves at Q2, not Q4.

Pattern Quick Reference

Direct Generation (Prompt Engineering) — The model produces output from its training knowledge alone, shaped by the prompt.

When it comes up: When a buyer asks about AI-assisted drafting, summarization, or classification of content the model already understands — policy language, common security frameworks, standard contract clauses.

Don't confuse with: RAG. If the content is internal, proprietary, or changes frequently, direct generation will hallucinate. The model doesn't know what it doesn't know, and it won't tell you.

RAG Loop — The model queries an external knowledge store at inference time and uses retrieved content to generate its response.

When it comes up: Every time a buyer asks how the AI "knows" their internal data without retraining. The answer is always RAG — the model doesn't know it; it looks it up.

Don't confuse with: Fine-tuning. RAG retrieves at runtime; fine-tuning bakes knowledge into weights. Different cost, different update cycle, different failure mode when the knowledge changes.

Workflow Pattern — A deterministic sequence of model calls and tool invocations, orchestrated by code, with branching logic defined in advance.

When it comes up: When a buyer describes a repeatable process with known steps — "the AI reviews the ticket, checks the policy, and routes it." If you can draw the flowchart before the AI runs, it's a workflow.

Don't confuse with: Agent loop. Workflows branch on rules; agents branch on model judgment. The difference matters for auditability and for what happens when something unexpected occurs mid-process.

Agent Loop — An autonomous execution pattern where the model decides its next action based on current context, invokes tools, observes results, and continues until the task is complete.

When it comes up: When a buyer describes a task that requires judgment about what to do next — "the AI investigates the alert and takes remediation steps." The path isn't known in advance.

Don't confuse with: Workflow. If the buyer can enumerate every branch before the AI runs, they want a workflow. Agents are for the cases where they genuinely can't.

Function Calling — The mechanism by which a model outputs a structured request to invoke an external function, which the runtime executes and returns results from.

When it comes up: When a buyer asks how the AI "takes action" — creates a ticket, queries a database, sends a notification. Function calling is the bridge between model output and real-world effect.

Don't confuse with: MCP. Function calling is the mechanism; MCP is the protocol layer that standardizes what functions are available and how the model discovers them. You can have function calling without MCP; MCP is what makes function calling manageable at scale.

MCP (Model Context Protocol) — A standardized protocol for exposing tools, resources, and context to a model at runtime, so the model can discover and invoke capabilities without custom integration per tool.

When it comes up: When a buyer asks about connecting the AI to multiple enterprise systems — "can it talk to our ITSM, our directory, and our SIEM?" MCP is the answer to why that doesn't require nine separate integrations.

Don't confuse with: An API gateway. MCP is model-facing; an API gateway is client-facing. The authorization model is different because the caller is a model making probabilistic decisions, not a human or a deterministic application.

Evals — Structured evaluation runs that measure model or system behavior across a distribution of inputs, producing scores against defined criteria.

When it comes up: When a buyer asks "how do you know it's working?" or "how do you catch regressions?" Evals are the answer — not unit tests, not user feedback alone, but systematic measurement before and after changes.

Don't confuse with: Testing. Tests check specific inputs against expected outputs: pass/fail. Evals measure behavior across a distribution and produce scores. Pass/fail doesn't apply here — the score distribution either shifted or it didn't, and the direction matters as much as the magnitude.

Multi-Agent Topology — An architecture where an orchestrator agent delegates subtasks to specialized sub-agents, each with its own tools and execution context, coordinated toward a shared goal.

When it comes up: When a buyer describes a complex process requiring different expertise at different stages — triage, then remediation, then reporting. One agent can't hold all the context and tools without becoming unmanageable.

Don't confuse with: A single agent loop with multiple tools. A single agent can use multiple tools; a multi-agent topology uses multiple agents, each with its own execution context. The governance implications — credential scope, audit trail, delegation depth — multiply accordingly.

If you remember nothing else from this section: the pattern name tells you the decision logic. Workflow = code decides. Agent = model decides. Multi-agent = models decide, then delegate.

The IDAM Analogy Map

Use the IDAM column to help a buyer locate the concept in territory they already know. Stop using it the moment the conversation moves to implementation — the Key Divergence column is why.

AI Term	What It Means in AI	IDAM Equivalent	Key Divergence
Workflow	Orchestrated sequence of model calls and tool invocations with code-defined branching	Lifecycle automation / provisioning workflow	Lifecycle workflows branch on attribute values — deterministic rules. AI workflows can branch on model output, which is probabilistic. You cannot write a Joiner policy that says "if the model thinks this is high risk." The branching logic isn't auditable the same way.
Agent loop	Autonomous execution where the model decides its next action based on observed results	Privileged service account	A service account's permission scope is fixed at provisioning. An agent can discover and invoke new tools mid-task through function calling or MCP. Least privilege doesn't have a clean answer for a principal whose effective permissions expand at runtime.
RAG loop	Model queries external knowledge store at inference time; retrieved content shapes the response	Directory lookup / LDAP query	LDAP returns exact matches or "not found" — a clean binary. RAG returns ranked results by semantic relevance. Low-relevance results still get returned and used by the model. There is no clean failure mode equivalent to "entry not found."
Function calling	Model outputs structured request to invoke external function; runtime executes and returns result	API authorization	API authorization is enforced at the resource server — your policy engine decides. Function calling is decided by the model. You can restrict what functions are available; you cannot control which available function the model chooses to invoke. The decision layer is inside the model, not your policy engine.
MCP	Protocol layer that standardizes tool and resource exposure to the model at runtime	OAuth scopes / resource server	OAuth scopes are declared at registration and static for a given token. MCP tool availability is dynamic — the server can expose different tools based on context, discovered at runtime. Your authorization model has to account for capabilities that weren't known at token issuance.
Multi-agent topology	Orchestrator agent delegates subtasks to specialized sub-agents with their own execution contexts	Delegated administration	Delegated admin scope is set by a human at configuration time. An orchestrator agent can spawn sub-agents and grant them capabilities dynamically. The delegation chain can extend beyond what any human explicitly authorized. There is no native equivalent of a delegation depth limit.
Evals	Structured measurement of model behavior across input distributions, producing scored results	Access reviews / certification campaigns	Access reviews produce binary outcomes: certify or revoke. Evals produce score distributions. The relevant question isn't authorization but performance — "is this performing well enough?" — and "well enough" requires a threshold that someone has to set and defend. There is no policy engine for eval thresholds.

If you remember nothing else from this section: the IDAM analogies break at the same place every time — the point where a human decision gets replaced by a model decision. Your governance frameworks were built for the former.

For More Information

Recap Entry	Source Lesson	Section
Direct generation, prompt engineering	Lesson 1: Direct Generation and Prompt Engineering	"When the Model Already Knows"
RAG loop, fine-tuning distinction	Lesson 2: The RAG Loop	"Retrieval at Inference Time"; "Why RAG Isn't Fine-Tuning"
Workflow pattern, deterministic branching	Lesson 3: Workflow Patterns	"Deterministic Orchestration"; "Where Workflows Break"
Agent loop, model-decided branching	Lesson 4: The Agent Loop	"Model-Decided Branching"; "Scope and Audit in Agent Execution"
Function calling mechanism	Lesson 5: Function Calling and Tool Use	"The Mechanism"; "Authorization at the Model Layer"
MCP, dynamic tool discovery	Lesson 6: MCP — The Resource Layer	"Dynamic Tool Discovery"; "MCP vs. API Gateway"
Evals, score distributions	Lesson 7: Evals and Multi-Agent Topologies	"Measuring Behavior, Not Outputs"
Multi-agent topology, delegation depth	Lesson 7: Evals and Multi-Agent Topologies	"Orchestration and Delegation"; "Credential Scope in Multi-Agent Systems"
All IDAM analogy breaks	Chapter Opener: Why Patterns Matter Before Architecture	"The Translation Problem"