The Decision Tree
Four questions. Work through them in order. Stop at the first one that resolves your situation — that's your pattern. Every question you skip past is a layer of complexity you're choosing to add.
Q1: Is the knowledge already in the model?
If the domain is general — common business reasoning, public knowledge, standard professional tasks — the model already knows enough. You're shaping output, not supplying facts. → Prompt engineering, few-shot prompting. Stop here.
If the model doesn't know what it needs to know, the next question is whether that knowledge is stable or live. → Stable, proprietary domain knowledge: Fine-tuning. → Knowledge that changes, or that varies by user/context: RAG.
Q2: Is the path predictable?
If you can specify the steps in advance — input A triggers step 1, step 1 output feeds step 2, and so on — you have a workflow problem, not an agent problem. → Chain / Workflow pattern. The sequence is fixed; the model fills in the reasoning at each node.
If the path depends on what the model discovers along the way, you need something that can decide what to do next. → Continue to Q3.
Q3: Does it need tools?
If the task requires reaching outside the model — querying a system, writing to a database, calling an API — tool access is required regardless of whether the path is fixed or adaptive. → Add tool-calling to whatever pattern Q1 and Q2 selected. → If the path is fixed: Tool-augmented workflow. → If the path is adaptive: Tool-augmented agent.
Q4: Does it need to adapt mid-task?
If the model needs to evaluate its own output, decide whether to continue or change course, and loop until a condition is met — that's the agent loop. → Single task, one model: Single agent. → Parallel subtasks or specialized roles: Multi-agent.
If you remember nothing else: Complexity is a governance liability. Every layer you add past what the task requires is a failure mode you're choosing to own.
Pattern-to-IDAM Analogy Map
The analogies held up long enough to be useful. Each one breaks at a specific point.
| AI Pattern | What It Does | IDAM Equivalent | Key Divergence |
|---|---|---|---|
| Prompt Engineering | Shapes model output through instruction | Attribute-based access control policy | ABAC policies are enforced by a policy engine; prompt instructions are suggestions the model can ignore or misinterpret |
| RAG | Retrieves external documents at inference time | Just-in-time attribute lookup (LDAP query at auth) | The retrieval isn't governed by a policy engine — any document in the corpus is reachable regardless of the user's entitlements |
| Fine-tuning | Bakes domain knowledge into model weights | Claims baked into a token at issuance | You can't revoke what's in the weights; there's no equivalent of token expiry for trained knowledge |
| Workflow / Chain | Executes a fixed sequence of LLM calls | SCIM provisioning workflow or approval chain | No session to revoke mid-execution; if step 4 of 7 produces a bad output, there's no standard rollback |
| Single Agent | Autonomous observe-plan-act loop | Privileged service account (NHI) | The agent decides its own next action; a service account executes a fixed protocol and doesn't reason about what to do next |
| Multi-Agent | Multiple agents coordinate on a task | Federated identity mesh | Trust delegation between agents isn't governed by a central authority; one agent can grant another agent scope it doesn't hold |
If you remember nothing else: Every IDAM analogy for AI patterns breaks at the same place — there's no revocation. No session to terminate, no token to expire, no policy engine enforcing the boundary in real time.
Vocabulary Collision Map
These terms exist in both your world and the AI world. They don't mean the same thing. The collision happens in buyer conversations, usually at the worst moment.
| AI Term | What It Means in AI | IDAM Equivalent | Key Divergence |
|---|---|---|---|
| Token | Subword unit — the model's atomic chunk of text | Bearer token (OAuth) | An LLM token carries no claims, no subject, no expiry — it's a character fragment, not an assertion |
| Context | The full input buffer the model can see at inference time | Request context (device, location, session state) | LLM context is a flat text window; IDAM context is structured, typed, and policy-evaluated |
| Scope | The task or domain an agent is working within | OAuth scope (registered permission boundary) | Agent scope is informal and self-described; OAuth scope is declared, registered, and enforced at the authorization server |
| Agent | Autonomous system that reasons and takes actions | Directory sync agent (software executing a fixed protocol) | An AI agent decides what to do next; an IDAM agent doesn't decide anything |
| Session | A conversation thread with an LLM | Authenticated session (with expiry and revocation) | LLM sessions have no standard expiry or revocation mechanism — they end when the user closes the tab |
| Identity | The model's role or persona, set by system prompt | Verified identity (cryptographically bound principal) | Model "identity" is a text instruction; it's not authenticated, not bound to a credential, and not revocable |
If you remember nothing else: When a buyer uses an IDAM term in an AI conversation, they probably mean the AI thing. When you use an AI term, they probably hear the IDAM thing. Name the collision before it names you.
Chapter Governing Principle
Simple pattern, measured complexity. The decision tree is a stopping rule. The right pattern is the one where you stopped, not the most sophisticated one you could justify.
Buyers who've read the same AI strategy documents you have will ask for agents when they need RAG, ask for fine-tuning when they need a system prompt, and ask for multi-agent orchestration when they need a workflow. Map what they described to the pattern that actually solves it, and explain the difference in terms they'll recognize.
The IDAM analogy gets you into the conversation. The divergence column is what makes you credible once you're in it.
For More Information
| Topic | Source Lesson |
|---|---|
| Zero-shot and few-shot prompting | Lesson 1: The Single Prompt |
| RAG architecture and retrieval mechanics | Lesson 2: Grounding the Model |
| Fine-tuning vs. prompting tradeoffs | Lesson 3: Teaching vs. Telling |
| Chain and workflow patterns | Lesson 4: Chains and Workflows |
| Tool-calling and function use | Lesson 5: Tool Use |
| The agent observe-plan-act loop | Lesson 6: The Agent Loop |
| Multi-agent coordination and trust | Lesson 7: When Agents Spawn Agents |
| Guardrails, termination, and failure modes | Lesson 8: Knowing When to Stop |
| This decision tree and analogy maps | Lesson 9: Choosing Your Pattern (this lesson) |
Vocabulary collision entries (token, context, scope, agent, session, identity) surface across Lessons 2, 5, 6, and 7. The collision map above consolidates them.