{
  "id": "dd-12-exam",
  "title": "DD-12 CrewAI — Role-Based Multi-Agent (Emergent Coordination)",
  "deep_dive": "dd-12-crewai",
  "course": "master-course",
  "duration_minutes": 30,
  "pass_threshold": 0.70,
  "question_count": 15,
  "bloom_distribution": {"recall": 3, "application": 6, "analysis": 6},
  "questions": [
    {
      "id": "q01",
      "bloom": "recall",
      "type": "multiple_choice",
      "prompt": "What are CrewAI's three core primitives?",
      "options": [
        "Graph, Node, Edge",
        "Crew (unit of orchestration), Agent (unit of role), Task (unit of work)",
        "Harness, Sandbox, Provider",
        "Loop, Tool, Memory"
      ],
      "answer_index": 1,
      "rationale": "CrewAI's three primitives: Agent (unit of role — system prompt assembled from role+goal+backstory+tools), Task (unit of work — description, assigned agent, expected output, optional context), Crew (unit of orchestration — holds agents, tasks, process strategy, owns the loop). Graph/Node/Edge is LangGraph's model. Harness/Sandbox/Provider is the Agents SDK's model."
    },
    {
      "id": "q02",
      "bloom": "recall",
      "type": "multiple_choice",
      "prompt": "What does 'role is the system prompt' mean in CrewAI, and which course module does this connect to?",
      "options": [
        "The role field is logged to the prompt audit trail — Module 11 (Observability).",
        "CrewAI does not give you a raw system-prompt string; it gives you a templated one whose fields are role, goal, backstory. This is Module 12 (Prompt Assembly) applied at agent granularity rather than harness granularity.",
        "The role field determines which tools the agent can call — Module 2 (Tools).",
        "The role field sets the agent's memory tier — Module 4 (Memory)."
      ],
      "answer_index": 1,
      "rationale": "CrewAI's load-bearing insight: role IS the system prompt. The framework does not give you a raw system-prompt string; it gives you a templated one whose fields are role, goal, backstory (plus tools). The template is the framework's opinion. This is Module 12 (Prompt Assembly) applied at the agent granularity rather than the harness granularity. The value: you never hand-author a system prompt. The risk: when the template is wrong, you fight the framework's opinion."
    },
    {
      "id": "q03",
      "bloom": "recall",
      "type": "multiple_choice",
      "prompt": "What are CrewAI's two orchestration modes (process types)?",
      "options": [
        "Synchronous and asynchronous",
        "Sequential (tasks run in list order, output chains forward) and concurrent/hierarchical (a manager agent decomposes, dispatches to workers, synthesizes)",
        "Declared and emergent",
        "Single-agent and multi-agent"
      ],
      "answer_index": 1,
      "rationale": "Sequential is the default — tasks run in list order, each output appended to shared context the next agent reads (a linear ReAct chain across roles). Concurrent/hierarchical adds a manager agent that decomposes the goal, assigns subtasks to workers, runs them, and synthesizes — a one-level hierarchy (shallower than DD-06's multi-tier design). Sequential composes well for research-then-write; hierarchical adds a manager's synthesis."
    },
    {
      "id": "q04",
      "bloom": "application",
      "type": "multiple_choice",
      "prompt": "You have a task: research a topic, write a blog post, then edit it for publication. Each step benefits from a distinct persona (researcher, writer, editor). Should you use a CrewAI crew, and why?",
      "options": [
        "No — use a single agent with a subtask list. The work is really one reasoning thread wearing different hats.",
        "Yes — the work genuinely decomposes along role lines with clean handoffs (research output feeds the writer, draft feeds the editor). Each role benefits from a distinct persona. This is the textbook case where the role abstraction earns its keep.",
        "No — CrewAI cannot handle sequential dependencies between tasks.",
        "Yes — but only if you use the concurrent/hierarchical mode with a manager agent."
      ],
      "answer_index": 1,
      "rationale": "This is the textbook right case for CrewAI. Research-then-write, draft-then-review, plan-then-execute — work that genuinely decomposes along role lines with clean handoffs. Each step benefits from a distinct persona, policy, or skill profile. The role abstraction earns its overhead. The diagnostic question: could one agent with one system prompt and a subtask list do this? Here, the roles genuinely carry different profiles, so the crew earns its keep. Sequential mode is the right process type."
    },
    {
      "id": "q05",
      "bloom": "application",
      "type": "multiple_choice",
      "prompt": "You are building a crew where Task 2 needs everything Task 1 produced plus the ability to revise it iteratively. Should you use two agents, and why?",
      "options": [
        "Yes — always use separate agents for separate tasks in CrewAI.",
        "No — if Task 2 needs everything Task 1 produced plus the ability to revise it, you don't have two agents. You have one agent with a checkpoint. Spinning it into a crew adds latency, token cost, and a new injection surface without adding capability.",
        "Yes — two agents with a handoff between them is the cleanest pattern.",
        "No — CrewAI does not support iterative revision within a single crew."
      ],
      "answer_index": 1,
      "rationale": "This is the 'role-ify everything' anti-pattern in disguise. The diagnostic question: could one agent with one system prompt and a subtask list do this? If Task 2 needs everything from Task 1 plus revision capability, it's really one agent with a checkpoint — not two agents with a handoff. A crew adds latency (each agent re-reads context), token cost, and a new injection surface (the task-output handoff) without adding capability. Reserve multi-agent for work where roles genuinely carry different policies, tool sets, or verification duties."
    },
    {
      "id": "q06",
      "bloom": "application",
      "type": "multiple_choice",
      "prompt": "You are deploying a CrewAI crew to production where agents execute tools with side effects (file writes, API calls). The crew has no sandbox configured. What is the risk and the cure?",
      "options": [
        "No risk — CrewAI's role-based model prevents dangerous tool calls.",
        "Risk: tools run on the host with no isolation (Module 5: 1/5 — no built-in sandbox). A buggy or compromised tool can modify or destroy host files. Cure: bring your own sandbox (Docker, E2B) and route tool execution through it. Same lesson as NemoClaw (DD-09) and the Agents SDK (DD-11), except CrewAI makes it bring-your-own.",
        "Risk: the crew will fail to run because CrewAI requires a sandbox provider.",
        "No risk — the task-output handoffs are trusted by default."
      ],
      "answer_index": 1,
      "rationale": "CrewAI has no built-in sandbox (Module 5: 1/5). Tools with side effects run on the host with no isolation. A buggy or compromised tool can modify or destroy host files, escalate privileges, or pivot to network resources. The cure is to bring your own sandbox (Docker, E2B) and route tool execution through it. This is the same 'isolation is not optional in production' lesson as NemoClaw (DD-09) and the Agents SDK (DD-11), except CrewAI makes it bring-your-own rather than baking it in."
    },
    {
      "id": "q07",
      "bloom": "application",
      "type": "multiple_choice",
      "prompt": "You need to build a multi-agent system for a regulated industry where you must prove (for compliance) that the coordination graph executes in a specific auditable order. Which framework should you choose, and why?",
      "options": [
        "CrewAI — the role-based model is more intuitive for compliance teams.",
        "LangGraph (DD-10) — declared coordination. The graph is a first-class object you can visualize, checkpoint, and prove properties about. You can interrupt at any node, resume from any checkpoint, and audit the exact flow. Emergent coordination (CrewAI) cannot provide this guarantee because the graph is invisible.",
        "Either — both frameworks produce equivalent audit trails.",
        "The OpenAI Agents SDK (DD-11) — the 2-layer split provides the compliance guarantee."
      ],
      "answer_index": 1,
      "rationale": "The diagnostic question: do you need to prove properties about the coordination graph? For compliance, the answer is yes. LangGraph's declared coordination makes the graph a first-class, auditable object — you can visualize it, checkpoint at any node, and prove the flow executes in a specific order. CrewAI's emergent coordination cannot provide this guarantee because the graph emerges implicitly from task context references and is invisible past ~5 tasks. This is the load-bearing contrast that defines the multi-agent coordination axis (Course 4 E09)."
    },
    {
      "id": "q08",
      "bloom": "application",
      "type": "multiple_choice",
      "prompt": "A compromised upstream agent in your CrewAI crew writes a poisoned entry into the crew-scoped shared memory. What happens, and what is the structural cause?",
      "options": [
        "Only the compromised agent reads the poisoned entry — each agent's memory is isolated.",
        "Every other agent in the crew later reads the poisoned entry. The structural cause: memory is crew-scoped, not agent-scoped — all agents share one store with no per-agent write isolation (Module 4.3 write-gating unavailable by default).",
        "The crew crashes immediately — CrewAI detects poisoned memory entries.",
        "The poisoned entry is quarantined by CrewAI's built-in security model."
      ],
      "answer_index": 1,
      "rationale": "Crew-scoped shared memory means all agents read and write the same store. A poisoned entry written by one agent is read by every other agent in the crew. The structural cause: memory is crew-scoped, not agent-scoped, so Module 4.3's write-gating defense (per-agent write isolation) is unavailable by default. This is the same compounding-poisoning argument as Hermes (DD-08), except here the compounding is across agents within a single crew run, not across sessions. One of the three things to fix: offer agent-scoped memory as an option."
    },
    {
      "id": "q09",
      "bloom": "application",
      "type": "multiple_choice",
      "prompt": "You are treating every task-output handoff in your CrewAI crew as trusted — the upstream agent's output is injected directly into the downstream agent's prompt without validation. What attack are you vulnerable to, and what is the cure?",
      "options": [
        "Credential leak — the cure is to add a sandbox provider.",
        "Indirect prompt injection across the handoff boundary. A compromised upstream agent injects instructions into its task output that the downstream agent reads and acts on (Module 2.4 Vector 1). Cure: treat every handoff as an untrusted-content boundary — validate task outputs before injecting them into the next agent's prompt.",
        "Memory poisoning — the cure is to disable shared memory.",
        "No attack — CrewAI validates task outputs automatically."
      ],
      "answer_index": 1,
      "rationale": "Each task-output handoff is an untrusted-content boundary (Module 2.4 Vector 1). If you inject the upstream agent's output into the downstream agent's prompt without validation, you are vulnerable to indirect prompt injection — a compromised upstream agent embeds instructions in its output that the downstream agent reads and executes. The cure is to treat every handoff as untrusted input: validate task outputs before injection. Do not assume the upstream agent's output is benign just because the upstream agent was declared with a benign role."
    },
    {
      "id": "q10",
      "bloom": "analysis",
      "type": "multiple_choice",
      "prompt": "CrewAI (emergent coordination) and LangGraph (DD-10, declared coordination) define the multi-agent coordination axis. What is the diagnostic question for choosing between them, and why does it matter?",
      "options": [
        "'Which framework has more GitHub stars?' — popularity indicates quality.",
        "'Do you need to prove properties about the coordination graph?' If yes (compliance, security audit, reproducibility), declared coordination (LangGraph) earns its ceremony. If no (prototyping, internal tools, exploratory work), emergent coordination (CrewAI) earns its speed. The choice is a tradeoff between declaration speed and auditability.",
        "'Which framework is faster at runtime?' — latency is the deciding factor.",
        "'Which framework has a built-in sandbox?' — sandboxing determines the choice."
      ],
      "answer_index": 1,
      "rationale": "The diagnostic question is: do you need to prove properties about the coordination graph? If yes (compliance, security audit, reproducibility), LangGraph's declared coordination earns its ceremony — the graph is a first-class object you can audit and checkpoint. If no (prototyping, internal tools, exploratory work), CrewAI's emergent coordination earns its speed — you describe the team and it runs. This axis is the organizing principle of Course 4's E09 module. Every multi-agent framework sits between these two poles."
    },
    {
      "id": "q11",
      "bloom": "analysis",
      "type": "multiple_choice",
      "prompt": "Why does CrewAI score 4/5 on Module 1.3 (Subagents) but only 1/5 on Module 5 (Sandbox), Module 9 (Verification), and Module 11 (Security)? What single design decision explains this profile?",
      "options": [
        "CrewAI's team lacks expertise in sandboxing and security.",
        "CrewAI optimizes for orchestration accessibility (the role-based mental model, sequential crews — hence 4/5 on Module 1.3) and treats production-readiness (sandboxing, verification, security) as bring-your-own (hence 1/5 on Modules 5/9/11). The high and low scores are the same design decision read from two sides: accessible orchestration in, production operations out.",
        "The 4/5 on Module 1.3 is a scoring error — CrewAI should score lower.",
        "CrewAI's Python implementation limits its sandboxing capabilities."
      ],
      "answer_index": 1,
      "rationale": "Read the score as a profile, not a ranking. The 4/5 on Module 1.3 and the 1/5 on Modules 5, 9, and 11 are the same design decision: CrewAI optimizes for orchestration accessibility (the role-based mental model is the most accessible in the category, and sequential crews are a textbook multi-agent pattern) and treats production-readiness as bring-your-own. This is the orchestration-first shape. You build on CrewAI to prototype and teach; you move to LangGraph or the Agents SDK for production. The high and low scores are two sides of one decision."
    },
    {
      "id": "q12",
      "bloom": "analysis",
      "type": "multiple_choice",
      "prompt": "Compare CrewAI's crew-scoped shared memory to Hermes's (DD-08) self-evolving skill store. What is the shared security argument, and what differs?",
      "options": [
        "Both are secure — neither has a poisoning surface.",
        "Both have a compounding-poisoning surface caused by shared writable memory with no write gate. The difference: Hermes's skill store compounds poisoning across SESSIONS (a poisoned skill activates on every future similar task), while CrewAI's crew-scoped memory compounds poisoning across AGENTS within a single crew run (a poisoned entry is read by every other agent in the crew). Same argument, different timescale.",
        "Hermes has a poisoning surface; CrewAI does not because its memory is read-only.",
        "CrewAI has a poisoning surface; Hermes does not because its skills are isolated per agent."
      ],
      "answer_index": 1,
      "rationale": "Both have a compounding-poisoning surface caused by shared writable memory with no write gate (Module 4.3 unavailable). The shared argument: the compounding that makes shared memory convenient (skills that compound, crew collaboration) is the same compounding that makes poisoning dangerous. The difference is the timescale: Hermes compounds poisoning across sessions (a poisoned skill activates on every future similar task with no natural decay), while CrewAI compounds poisoning across agents within a single crew run (a poisoned entry is read by every other agent in the crew). Same architectural argument, different scope."
    },
    {
      "id": "q13",
      "bloom": "analysis",
      "type": "multiple_choice",
      "prompt": "The course draws a parallel between NemoClaw-vs-Tau (DD-09) and CrewAI-vs-LangGraph (DD-10). What is the structural parallel, and why is it load-bearing?",
      "options": [
        "Both pairs are ranked by GitHub stars.",
        "Both pairs define a load-bearing AXIS that organizes a course module. NemoClaw-vs-Tau defines the GOVERNANCE axis (governance-beneath-the-agent vs no defenses — load-bearing for C2B). CrewAI-vs-LangGraph defines the MULTI-AGENT COORDINATION axis (emergent vs declared — load-bearing for C4 E09). In each case, the pair of poles defines the space every other framework sits within.",
        "Both pairs are about sandboxing — the parallel is Module 5.",
        "Both pairs are about memory — the parallel is Module 4."
      ],
      "answer_index": 1,
      "rationale": "The structural parallel: both pairs define a load-bearing axis that organizes a course module. NemoClaw (governance-beneath-the-agent) vs Tau (no defenses) defines the GOVERNANCE axis — load-bearing for Course 2B. CrewAI (emergent coordination) vs LangGraph (declared coordination) defines the MULTI-AGENT COORDINATION axis — load-bearing for Course 4 E09. In each case, the pair of poles defines the conceptual space every other framework sits within. This parallel structure — load-bearing axes defined by pole pairs — is the architectural pattern the course uses to organize the roster."
    },
    {
      "id": "q14",
      "bloom": "analysis",
      "type": "multiple_choice",
      "prompt": "CrewAI's tools attach to agents (Agent(tools=[...])), not to the crew. How does this relate to Module 2.4 (per-agent capability scoping), and what is the limitation?",
      "options": [
        "It fully implements Module 2.4 — each agent's capability surface is isolated from every other agent.",
        "It is structurally a form of Module 2.4 per-agent capability scoping (each agent's tools are scoped at declaration time), BUT there is no enforcement that two agents can't share the same dangerous tool, and no mechanism to prevent an agent from passing instructions to a downstream agent that would cause it to call a tool the upstream agent doesn't have. Scoping exists by construction; isolation does not.",
        "It has no relationship to Module 2.4 — tool attachment is a CrewUI concern.",
        "It violates Module 2.4 — tools should attach to the crew, not to agents."
      ],
      "answer_index": 1,
      "rationale": "Tools attaching to agents is structurally a form of Module 2.4 per-agent capability scoping — each agent's capability surface is scoped at declaration time. This is closer to Module 2.4 than most frameworks that attach tools at the harness level. The limitation: there is no enforcement that two agents can't share the same dangerous tool, and no built-in mechanism to prevent an agent from passing instructions (via task output) to a downstream agent that would cause it to call a tool the upstream agent doesn't have. Per-agent scoping exists by construction; per-agent capability isolation does not."
    },
    {
      "id": "q15",
      "bloom": "analysis",
      "type": "multiple_choice",
      "prompt": "A team is choosing between CrewAI and the OpenAI Agents SDK (DD-11) for a production multi-agent system that needs sandboxing. How should they decide, and what is the key distinction?",
      "options": [
        "Choose CrewAI — it is more popular and has better documentation.",
        "Choose the Agents SDK (DD-11) for production — it provides the 2-layer harness/compute split with the 7-provider sandbox abstraction (Module 5: 5/5) and handoffs + agents-as-tools as first-class primitives. CrewAI (Module 5: 1/5, no sandbox) is optimized for prototyping and teaching, not production. The key distinction: CrewAI is orchestration-accessible but bring-your-own-production; the SDK is the architectural foundation with production primitives baked in.",
        "Choose CrewAI — its role-based model is more production-ready than the SDK's primitives.",
        "They are equivalent for production — choose based on team preference."
      ],
      "answer_index": 1,
      "rationale": "For a production system that needs sandboxing, the OpenAI Agents SDK (DD-11) is the right choice. It provides the 2-layer harness/compute split with the 7-provider sandbox abstraction (Module 5: 5/5 — the highest in the roster) and handoffs + agents-as-tools as first-class primitives. CrewAI (Module 5: 1/5, no built-in sandbox) is optimized for orchestration accessibility — prototyping multi-agent patterns and teaching. The key distinction: CrewAI is orchestration-accessible but treats production-readiness as bring-your-own; the SDK is the architectural foundation with the hardest production decisions (credential isolation, sandbox portability, subagent delegation) baked in as defaults."
    }
  ]
}