"What is CrewAI's defining pattern?"	Role-based sequential crews: define agents with role+goal+backstory; assign tasks; CrewAI orchestrates (sequential output-to-input or concurrent/hierarchical). The crew structure EMERGES from roles, not explicit edges.	harness-engineering::dd12::recall
"What are CrewAI's three primitives?"	(1) Agent — unit of role (system prompt assembled from role+goal+backstory+tools). (2) Task — unit of work (description, assigned agent, expected output, optional context). (3) Crew — unit of orchestration (holds agents, tasks, process strategy, owns the loop).	harness-engineering::dd12::recall
"What does 'role is the system prompt' mean in CrewAI?"	CrewAI does NOT give you a raw system-prompt string. It gives you a templated one whose fields are role, goal, backstory. The template is the framework's opinion. This is Module 12 (Prompt Assembly) applied at agent granularity rather than harness granularity.	harness-engineering::dd12::analysis
"CrewAI vs LangGraph (DD-10) — what is the key tradeoff?"	CrewAI: EMERGENT coordination (define roles, graph emerges from context refs + process type). Simpler, faster setup, less auditable. LangGraph: DECLARED coordination (draw nodes+edges, graph IS code). More ceremony, fully auditable. The multi-agent coordination axis.	harness-engineering::dd12::analysis
"Why is the emergent-vs-declared contrast load-bearing for Course 4 E09?"	CrewAI (emergent) and LangGraph (declared) define the two poles of the multi-agent coordination axis. Every multi-agent framework sits between them. Course 4 E09 takes this axis as its organizing principle: choosing a multi-agent architecture = choosing where to sit on this axis (declaration speed vs auditability).	harness-engineering::dd12::analysis
"What is the diagnostic question for choosing emergent vs declared coordination?"	'Do you need to PROVE PROPERTIES about the coordination graph?' If yes (compliance, security audit, reproducibility) — declared (LangGraph). If no (prototyping, internal tools) — emergent (CrewAI). The choice is a tradeoff between declaration speed and auditability.	harness-engineering::dd12::application
"CrewAI scores 33/60. Where does it win and lose?"	Wins Module 1.3 (Subagents): 4/5 — sequential crews are a textbook multi-agent pattern. Loses Module 5 (Sandbox: 1/5 — none), Module 9 (Verification: 1/5 — none), Module 11 (Security: 1/5 — no security model). Orchestration-first, not production-ready.	harness-engineering::dd12::analysis
"What are CrewAI's two orchestration modes?"	SEQUENTIAL (default): tasks run in list order, output appended to shared context the next agent reads — a linear ReAct chain across roles. CONCURRENT/HIERARCHICAL: a manager agent decomposes the goal, assigns subtasks to workers, synthesizes results — one-level hierarchy (shallower than DD-06).	harness-engineering::dd12::recall
"What is the multi-agent security risk in CrewAI's task-output handoffs?"	Each handoff is an UNTRUSTED-CONTENT boundary (Module 2.4 Vector 1). A compromised upstream agent can inject instructions into its task output that the downstream agent reads and acts on — indirect prompt injection propagating through the crew. Cure: validate task outputs before injection.	harness-engineering::dd12::analysis
"Why is CrewAI's crew-scoped shared memory a security liability?"	All agents in a crew share ONE memory store — no per-agent write isolation (Module 4.3 write-gating UNAVAILABLE by default). A compromised agent writes a poisoned entry every other agent later reads. Same compounding-poisoning argument as Hermes (DD-08), except here across agents within a run, not across sessions.	harness-engineering::dd12::analysis
"What is the 'role-ify everything' anti-pattern?"	Turning every multi-step task into a crew because the role/goal/backstory template is so intuitive. Cost: latency, token cost (each agent re-reads context), new injection surface per handoff. Cure: if one agent with a subtask list could do it, you don't need a crew.	harness-engineering::dd12::application
"When is CrewAI the RIGHT choice?"	Work that genuinely decomposes along role lines — research-then-write, draft-then-review, plan-then-execute. When subtasks have clean handoffs and each benefits from a distinct persona/policy/tool set. Prototyping multi-agent patterns. Teaching orchestration. The role abstraction earns its keep.	harness-engineering::dd12::application
"When is CrewAI the WRONG choice?"	Work that is really a single reasoning thread wearing different hats. 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. A crew adds latency, token cost, and injection surface without adding capability.	harness-engineering::dd12::application
"How does CrewAI's tool attachment model relate to Module 2.4?"	Tools attach to AGENTS (Agent(tools=[...])), not the crew. This is per-agent capability scoping at declaration time — structurally closer to Module 2.4 than most frameworks. BUT: no enforcement that two agents can't share a dangerous tool, and no isolation between agents. Scoping exists by construction; isolation does not.	harness-engineering::dd12::analysis
"What are the three things CrewAI does BETTER?"	(1) Role-based mental model — most accessible multi-agent entry point in the roster. (2) Sequential crews as a clean composable pattern. (3) Per-agent tool attachment — structurally gives per-agent capability scoping (closer to Module 2.4 than most).	harness-engineering::dd12::recall
"What are the three things to FIX about CrewAI?"	(1) Make the dependency graph explicit at scale (past ~5 tasks the emergent graph is invisible). (2) Offer agent-scoped memory (crew-scoped forfeits Module 4.3 write-gating by default). (3) Emit structured per-agent events (run logs are below the observability floor).	harness-engineering::dd12::recall
"How does CrewAI's memory model map to Module 4?"	Three opt-in tiers: short-term (crew-scoped, recent task outputs), long-term (persists across runs), entity memory (keyed by named entities). Maps to Module 4 tiers. NOTABLE: memory is crew-scoped NOT agent-scoped — all agents share one store, eliminating per-agent write isolation (Module 4.3 unavailable).	harness-engineering::dd12::analysis
"Why does CrewAI score only 1/5 on Module 5 (Sandbox)?"	No built-in sandbox — you bring your own (Docker, E2B, etc.). If agents execute tools with side effects, those tools run on the host with no isolation. This is the same 'isolation is not optional' lesson as NemoClaw (DD-09) and the Agents SDK (DD-11), except CrewAI makes it bring-your-own rather than baked in.	harness-engineering::dd12::recall
"How does CrewAI's hierarchical mode compare to DD-06 (oh-my-opencode)?"	Both use a manager/meta-agent that decomposes and dispatches. BUT: CrewAI's manager is implicit and the hierarchy is ONE LEVEL deep. DD-06's Sisyphus/Prometheus/Atlas/Junior is a deliberate MULTI-TIER design. CrewAI's hierarchical is a shallower instance of the same pattern.	harness-engineering::dd12::analysis
"What is the architect's verdict on CrewAI?"	Optimizes for ACCESSIBILITY — the fastest way to stand up a multi-agent crew with role-based task assignment, and the most legible mental model in the category. Sacrifices production-readiness. Build on CrewAI to PROTOTYPE multi-agent patterns and to teach orchestration; move to LangGraph (DD-10) when the graph needs to be explicit, or to the Agents SDK (DD-11) when you need sandboxing.	harness-engineering::dd12::application
"What is the 'describe the team' mental model?"	CrewAI's core value proposition: instead of drawing a graph (LangGraph) or composing primitives (Agents SDK), you describe the team you wish you had — each agent with a role, goal, backstory — assign tasks, and the crew runs. The coordination graph emerges. This is why CrewAI has 45,900+ stars and is the most accessible multi-agent framework.	harness-engineering::dd12::recall
"How does the emergent-vs-declared axis relate to NemoClaw-vs-Tau (DD-09)?"	Parallel structure. NemoClaw-vs-Tau defines the GOVERNANCE axis (governance-beneath-the-agent vs no defenses). CrewAI-vs-LangGraph defines the MULTI-AGENT COORDINATION axis (emergent vs declared). Both are load-bearing axes that organize course modules — C2B (governance) and C4 E09 (multi-agent). Each pair of poles defines the space every other framework sits within.	harness-engineering::dd12::analysis