"What is the OpenAI Agents SDK's category, and why does the category matter?"	An SDK / primitives library — NOT a finished harness. You BUILD the harness with it. The value is the architectural decisions it bakes in as defaults, not what it does out of the box (it does little). You add the operational layers (memory, observability, verification) yourself.	harness-engineering::dd11::recall
"What is the SDK's defining architectural contribution?"	The 2-layer harness/compute split. The harness layer (loop, model calls, credentials) runs on your backend; the compute layer (tool execution) runs in a sandbox. Credentials NEVER enter the compute layer — the SDK architecture PREVENTS it.	harness-engineering::dd11::recall
"Name the 7 sandbox providers."	Local bash · Docker · E2B · Modal · Daytona · Cloudflare · Vercel. Behind a uniform abstraction; swap by CONFIG, not code change. The harness code is provider-agnostic.	harness-engineering::dd11::recall
"Why does the 2-layer split make credential isolation 'architectural, not optional'?"	The SDK PREVENTS credentials from entering the compute layer — there is no code path for it. You cannot accidentally put creds in the sandbox because the architecture doesn't allow it. Not a policy; a structural impossibility.	harness-engineering::dd11::analysis
"What is the architectural payoff of the 7-provider abstraction?"	The harness code is provider-agnostic. You write the tool ONCE; you target the provider by config. A tool in local bash during dev runs in E2B in production by changing a config value. This is why the SDK scores 5/5 on Module 5.	harness-engineering::dd11::analysis
"Handoffs vs agents-as-tools — what's the difference?"	Agents-as-TOOLS: parent calls subagent like a tool, sync, RETAINS control, gets structured result, continues (delegation by query). HANDOFFS: parent TRANSFERS control, terminal, subagent owns task to completion (delegation by transfer).	harness-engineering::dd11::recall
"Why is the SDK the only framework that 'formalizes both' Module 1.3 patterns?"	Most harnesses implement one or neither subagent pattern. The SDK offers BOTH handoffs and agents-as-tools as first-class primitives — you declare the relationship in agent definition; the SDK handles routing, context passing, result return. This is the 4/5 on Module 10.	harness-engineering::dd11::analysis
"The SDK scores 38/60 — highest on which module, and why?"	Module 5 (Sandboxing): 5/5. The 7-provider abstraction is the most architecturally thoughtful sandboxing in the roster. Also strong on Module 10 (Subagents): 4/5 — handoffs + agents-as-tools as first-class primitives.	harness-engineering::dd11::recall
"Why is the SDK described as 'not a finished harness'?"	It's PRIMITIVES — loop, tool, sandbox, handoff, agents-as-tools. You BUILD the harness with it. No built-in memory, observability, or verification. You bring those. The SDK gives you the architectural foundation; you add the operational layers.	harness-engineering::dd11::application
"What is the NemoClaw (DD-09) connection, and why is it load-bearing?"	SAME principle, DIFFERENT layer. NemoClaw: governance gate OUTSIDE the agent's reach (agent proposes, harness enforces). SDK: credentials OUTSIDE the sandbox's reach (sandbox executes, harness holds creds). Both convert a discipline into a structural property.	harness-engineering::dd11::analysis
"How does the SDK compare to OpenCode (DD-03) on sandboxing?"	OpenCode's client/server split enables sandboxing — but it's Docker-or-nothing. The SDK's 7-provider abstraction means one harness runs in 7 isolation regimes without code change. A misconfigured weak regime (local bash in prod) is a CONFIG error, not an architectural mistake.	harness-engineering::dd11::analysis
"What is 'declarative-by-composition' and where does the SDK sit on the orchestration spectrum?"	You define agents (model, instructions, tools, handoff targets); the SDK runtime drives the loop, routes handoffs, dispatches sandboxes. Middle of the spectrum: LangGraph (DD-10) declares the whole graph; Pi (DD-01) hand-writes the loop. Structure without every edge.	harness-engineering::dd11::analysis
"Why does the SDK score only 2/5 on Module 11 (Observability)?"	No built-in tracing — you bring your own. This is the first thing to add before deploying a harness built on the SDK. A harness without observability is un-debuggable on long runs. The low score reflects that this is an SDK, not a finished product.	harness-engineering::dd11::recall
"What is the anti-pattern of 'treating the SDK as a finished harness'?"	Deploying it as-is gives you a loop and a sandbox but no memory, observability, or verification gates. Cure: treat as foundation; add bring-your-own layers BEFORE deploying (memory from M4, tracing from M11, gates from M9).	harness-engineering::dd11::application
"What is the 'choose a sandbox provider without matching isolation regime' anti-pattern?"	Picking local bash for dev and forgetting to switch to E2B/Docker for production — the Module 5 footgun (agent runs tools on host with no isolation). Cure: gate provider by environment; treat as deployment-time decision.	harness-engineering::dd11::application
"When should you use handoffs vs agents-as-tools?"	Agents-as-tools for query-style delegation where the parent should retain visibility (ask the DB agent a question, continue). Handoffs for genuine transfer (the DB agent owns the task to completion). Default to agents-as-tools; reserve handoffs for transfer.	harness-engineering::dd11::application
"What does the SDK score on Module 1 (Loop) and Module 6 (Permission), and why?"	Both 4/5. Loop: SDK-driven and composable — the runtime drives, you compose. Permission: approvals as first-class, integrated with handoffs. Strong architecture on the control axes.	harness-engineering::dd11::recall
"What is the three things the SDK does BETTER?"	(1) 7-provider sandbox abstraction — most architecturally thoughtful sandboxing (5/5 Module 5). (2) Handoffs + agents-as-tools as first-class patterns (only framework that does both). (3) 2-layer split baked in — credential isolation architectural, not optional.	harness-engineering::dd11::recall
"What is the three things to FIX about the SDK?"	(1) It's an SDK — bring your own tools, memory, observability, verification. (2) The 7-provider abstraction adds a learning curve (which provider for which use case?). (3) No built-in observability — add tracing first.	harness-engineering::dd11::recall
"What is the cross-cutting architectural pattern NemoClaw and the Agents SDK both demonstrate?"	Enforcement OUTSIDE the principal's reach. The principal (agent or sandbox) cannot bypass the enforcement (governance gate or credential boundary) because the enforcement lives in a different address space. Structural, not policy-based.	harness-engineering::dd11::analysis
"How does the SDK's 7-provider model change the security posture vs a single-provider harness?"	Isolation becomes a config-time decision, not a deployment-time architectural commitment. You cannot 'forget to add sandboxing' — you pick the regime at config, and a weak regime in production is a reviewable config error, not an architectural incident.	harness-engineering::dd11::analysis
"Why would you choose the Agents SDK over a finished harness like Pi (DD-01)?"	When you want the strongest architectural FOUNDATION for a custom harness (2-layer split, 7-provider sandbox, both subagent patterns) and you're willing to add the operational layers yourself. Especially for multi-tenant or multi-sandbox deployments where swapping isolation regimes matters.	harness-engineering::dd11::application