Section: Patterns & Practice | Slot: Recap
The Four-Question Decision Tree
Answer in order. Stop at the first branch that resolves your problem. The pattern that resolves earliest is the right pattern.
Q1: Is the knowledge already in the model?
└─ YES → Prompt-only inference. No retrieval, no fine-tuning, no pipeline.
Stop here.
└─ NO → Continue to Q2.
Q2: Is the path from input to output predictable?
└─ YES → Workflow pattern. Deterministic sequence, possibly with tool calls
at fixed steps. Stop here.
└─ NO → Continue to Q3.
Q3: Does the task require external tools or live data?
└─ NO → Fine-tuning candidate. The knowledge gap is structural;
bake it in. Stop here.
└─ YES → Continue to Q4.
Q4: Does the task require adapting mid-execution based on intermediate results?
└─ NO → RAG + tool-augmented workflow. Retrieval at request time,
deterministic execution. Stop here.
└─ YES → Agent pattern. Autonomous reasoning loop, dynamic tool selection,
human-in-the-loop checkpoints as warranted.If you remember nothing else: Pick the least complex pattern that solves the problem. Every step down this tree adds latency, failure surface, and cost. Stop when it's solved.
Vocabulary Mapping: AI Patterns to IDAM Analogies
The analogies hold until they don't. The right column is where they stop holding. That's where the buyer conversation gets interesting.
| AI Pattern | What It Means in AI | IDAM Equivalent | Key Divergence |
|---|---|---|---|
| Workflow | Deterministic sequence of model calls and tool invocations, triggered by an event | Lifecycle automation (Joiner/Mover/Leaver) | Lifecycle automation has a defined terminal state. AI workflows can loop, branch on probabilistic model output, and "done" is a judgment call, not a system event. |
| Agent | Autonomous reasoning loop that selects tools, evaluates intermediate results, and replans | Privileged service account | Service accounts have static, admin-defined permissions. Agents select tools dynamically at inference time — the effective "scope" isn't known until the model decides what to call. |
| RAG | Retrieval of relevant document chunks at request time, injected into context before generation | Federated attribute lookup (SAML attribute release, SCIM provisioning) | Federated lookup returns authoritative, structured data from a known source with a defined trust relationship. RAG returns probabilistically relevant chunks — relevance is not authority, and the retrieval source may not be auditable. |
| Fine-tuning | Embedding knowledge or behavior into model weights through additional training | Baking claims into a certificate at issuance | Certificate claims are binary and authoritative. Fine-tuned knowledge is probabilistic, can be overridden by context, and doesn't expire — there's no revocation mechanism for a weight update. |
| Tool use / function calling | Model selects and invokes an external API or function based on reasoning | Service-to-service OAuth call with a scoped token | OAuth scopes are pre-defined and admin-approved before the call. The agent's tool selection is model-driven — which tool gets called, with what parameters, isn't determined until inference time. The "authorization" happened before the model knew what it would ask for. |
| Multi-agent coordination | Multiple specialized agents passing context and delegating subtasks | Identity federation across trust domains | Federation has explicit trust agreements, defined attribute release policies, and auditable assertion chains. Multi-agent coordination typically has implicit inter-agent trust, no formal trust negotiation, and delegation chains that aren't visible to the authorizing system. |
| System prompt | Instructions prepended to every conversation that define model behavior and constraints | Access policy / authorization rule | Policies are enforced by infrastructure. System prompts are advisory — a sufficiently crafted user input can override them. There is no equivalent of policy enforcement point in a prompt. |
| Context window | The bounded memory available to the model during a single inference | Session | Sessions have defined timeouts, revocation mechanisms, and audit trails. Context windows are a technical constraint, not a security boundary. Nothing in the context window is "revoked" — it simply falls out of scope when the window fills. |
| Evaluation / observability | Systematic measurement of model output quality across a test set or in production | Audit logging | Audit logs capture what was authorized and executed. LLM evaluation captures what was generated — a probabilistic output that isn't directly tied to an authorization decision. You can log every inference and still not know whether the output was correct. |
If you remember nothing else: Every IDAM analogy in this section breaks at the same place: where human-defined policy meets model-driven behavior. The infrastructure your buyers already have governs deterministic systems. AI patterns require a different governance layer on top of that infrastructure, not instead of it.
Pattern Quick Reference
Prompt-only inference When it comes up: Buyer describes a use case where the model answers from general knowledge — policy summarization, draft generation, classification of well-defined categories. Don't confuse with: RAG. If the buyer says "but it needs to know our specific policies," that's a retrieval problem, not a prompting problem.
Workflow pattern When it comes up: Buyer describes a multi-step process with predictable branching — intake triage, document routing, approval chain automation. Don't confuse with: Agent pattern. If every step is known in advance and the model isn't replanning based on intermediate results, it's a workflow. Calling it an agent oversells complexity and undersells reliability.
RAG (Retrieval-Augmented Generation) When it comes up: Buyer needs the model to answer questions about internal documents, policies, or data that postdates the model's training cutoff. Don't confuse with: Fine-tuning. RAG retrieves at request time; fine-tuning bakes knowledge into weights. RAG is updatable without retraining. Fine-tuning is not.
Fine-tuning When it comes up: Buyer needs consistent tone, format, or domain-specific behavior that prompting alone can't reliably produce. Don't confuse with: RAG. Fine-tuning changes how the model behaves; RAG changes what the model knows at inference time. Most buyers who say "fine-tuning" mean RAG.
Tool-augmented workflow When it comes up: Buyer's workflow requires live data — current case status, real-time inventory, external API calls — but the sequence of steps is fixed. Don't confuse with: Agent pattern. Tool calls at predetermined steps in a deterministic pipeline are not agency. The model isn't deciding which tool to call based on reasoning; the workflow is.
Agent pattern When it comes up: Buyer describes a task where the right next step depends on what the previous step returned — research tasks, multi-source synthesis, anything where "it depends" is the honest answer to "what happens next?" Don't confuse with: Workflow with branching. Agents replan. Workflows branch. The distinction matters for governance: agent actions need runtime authorization checks that workflow steps don't.
Multi-agent coordination When it comes up: Buyer's problem requires parallel specialization — one agent for retrieval, one for analysis, one for drafting — with a coordinating layer. Don't confuse with: A single agent with multiple tools. Multi-agent adds inter-agent trust surface. If the buyer doesn't need parallel specialization, a single agent with well-scoped tools is simpler and more auditable.
If you remember nothing else: When a buyer describes their problem, listen for whether the next step is known before execution starts. Known steps are workflows. Unknown steps are agents. Most problems that get pitched as agents are workflows.
Governing Principle
Use the simplest pattern that solves the problem. Add complexity only when you can measure what you're getting for it.
In public sector procurement, this is an operational requirement. Every step down the complexity ladder adds latency, failure surface, cost, and audit burden. A CAIO who asks "why did you choose an agent pattern here?" deserves a specific answer about what the workflow pattern couldn't do. "Agents are more powerful" is not that answer.
Complexity you can't justify is complexity you can't defend. In a FedRAMP environment, that conversation happens before contract award, not after.
Source Index
| Topic | Source Lesson |
|---|---|
| Prompt-only inference; when base model knowledge is sufficient | Lesson 1: Inference-Only Patterns |
| Workflow pattern; deterministic pipelines in production | Lesson 2: Workflow Patterns |
| RAG architecture; retrieval as a design decision | Lesson 3: RAG Architecture |
| Tool use and function calling; runtime API invocation | Lesson 4: Tool Use and Function Calling |
| Agent pattern; autonomy, replanning, governance costs | Lesson 5: Agent Patterns |
| Fine-tuning vs. prompting; the knowledge baking decision | Lesson 6: Fine-Tuning vs. Prompting |
| Multi-agent coordination; inter-agent trust surface | Lesson 7: Multi-Agent Coordination |
| Evaluation and observability; measuring probabilistic output | Lesson 8: Evaluation and Observability |
| Hybrid patterns; composing patterns for complex problems | Lesson 9: Hybrid Patterns and Pattern Composition |
Tooling examples cited across the section (LangSmith, Braintrust, Langfuse, Arize, LoRA) are representative of the category at time of writing. Verify current capabilities before customer conversations.