→You need exactly one shared resource — like a logger, config manager, or connection pool.

→The object is expensive to create and you want to reuse it across the application.

→You don't know at compile time which class you need to instantiate.

→You want to centralise and control object creation logic in one place.

→You need to create families of related objects that must be used together

→Your system needs to be independent of how its products are created

→Creating objects with many optional parameters or configurations

→Building complex objects with a multi-step construction process

→Object creation is expensive (database queries, API calls, heavy computation)

→You need multiple similar objects with slight variations

→Integrating with third-party libraries that have incompatible interfaces

→Working with legacy code that you cannot or should not modify

→Separating abstraction from implementation when both should be extensible independently

→Avoiding permanent binding between abstraction and implementation

→Building hierarchical tree structures (file systems, organizational charts, UI components)

→When you need to treat individual objects and groups of objects identically

→Adding features to objects without modifying their original class

→Creating flexible combinations of behaviors (coffee with milk, sugar, and chocolate)

→A subsystem is complex and most callers only need a simple subset of its functionality.

→You want to layer your architecture — expose a clean API while hiding implementation details.

→Creating many similar objects where memory is a concern

→Objects have much shareable (intrinsic) state vs. unique (extrinsic) state

→Lazy loading: delay expensive object creation until actually needed

→Access control: restrict who can use an object or what they can do

→Multiple objects can handle a request and the handler isn't known in advance

→Request handlers should be determined dynamically at runtime

→You need to queue requests and execute them later

→Implementing undo/redo functionality

→You need to access collection elements without exposing the internal structure

→You want to support multiple simultaneous traversals of the same collection

→Objects have many interdependencies creating complex communication

→You want to decouple objects from directly knowing each other

→You need undo/redo functionality

→You want to save and restore object state

→You need to notify multiple objects when state changes occur

→Objects interested in updates don't know each other in advance

→Object behavior depends on state and changes at runtime

→You have many conditional statements (if/else or switch) based on state

→You have multiple ways to solve a problem and need to select at runtime

→You want to avoid conditional statements (if/else or switch) scattered throughout code

→Multiple classes implement similar algorithms with slight variations

→You want to avoid code duplication of common algorithm structure

→You have a complex object structure with many different element types

→You need many different, unrelated operations on the structure

→A general agent needs to route to a specialist who will own the entire conversation going forward

→Different topics within one product need different system prompts, tools, or model tiers

→You need up-to-date information beyond the LLM's training data

→Domain-specific or proprietary knowledge is critical

→Problems require multi-step reasoning or mathematical calculations

→Questions involve logic, planning, or causal reasoning

→Tasks require gathering information from external sources

→Actions must be taken based on intermediate reasoning

→Tasks require real-time data the LLM can't know (weather, stock prices, live search)

→You need deterministic, testable execution — e.g. exact database queries, calculations

→Tasks require diverse expertise (research, coding, design, review)

→Different subtasks would benefit from specialized agents

→Quality is more important than speed (creative writing, analysis)

→Complex tasks benefit from revision (code generation, essays)

→Multi-turn conversations longer than context window

→Agents need to learn from interactions across sessions

→Safety and content moderation are critical

→Regulatory compliance is required (HIPAA, GDPR)

→You need to extract specific fields from unstructured text

→Downstream code must act on LLM output programmatically

→The agent is about to perform an irreversible action (delete, send, charge, deploy)

→Confidence score falls below a safe threshold

→You have multiple models with different cost/capability trade-offs

→Different request types benefit from specialized agents or prompts

→The same prompt structure is reused with different inputs across the codebase

→You need to version, A/B test, or iterate on prompts without touching application code

→Conversations or agentic loops that run longer than a few exchanges

→Document Q&A where the source is larger than the context window

→Tasks decompose into independent subtasks with no data dependencies between them

→You need information from multiple sources simultaneously (search, databases, APIs)

→Your AI feature must stay available even during provider outages

→You're calling external tools or APIs that can fail

→Tasks decompose cleanly into independent, parallelizable subtasks

→Different subtasks require different tools, expertise, or model tiers

→Any user-facing AI feature where the response takes more than 1–2 seconds

→Chat interfaces, writing assistants, code generation — anywhere the user reads while the model writes

→Multiple models sharing overlapping feature sets

→Strict SLA on serving latency (need pre-computed online features)

→Multiple models in production (need to track which is deployed)

→Regulatory compliance requires audit trail of model decisions

→Regular retraining needed (daily/weekly as new data arrives)

→Multiple models being trained independently (consolidate into one pipeline)

→Real-time predictions needed (< 100ms SLA)

→High QPS (queries per second) requiring horizontal scaling

→Models require reproducibility (audit trail, regulatory compliance)

→Frequently retraining with new data versions

→Models in production serving real users

→Need to detect silent failures (accuracy degradation without labels)

→Deploying a new model to production with business impact

→Want to prove statistical significance before promoting

→You have 50–1000+ high-quality labeled examples for a specific task

→Prompt engineering isn't achieving the quality or consistency you need