Ship and observe

Four serious options above raw Python, each with a distinct mental model:

• Claude Agent SDK - Python and TypeScript only, and it bundles the Claude Code binary: you inherit a full agent harness rather than assembling one. Its primitives are built-in tools, hooks, subagents, MCP, permissions, sessions, skills, and plugins. Entry point is query() plus ClaudeAgentOptions; permission modes include plan, acceptEdits, and bypassPermissions. It was renamed from "Claude Code SDK" in late 2025 - older tutorials use the old name for the same thing.
• OpenAI Agents SDK - five primitives, and you have met most of them: Agents, Handoffs, Guardrails, Sessions, Tracing. The b6 shapes and b7 guardrails map 1:1; tracing is the new gift, covered in Part 2.
• LangGraph - your agent as a StateGraph of nodes and edges over a MessagesState. What it buys you: checkpointing and persistence, human-in-the-loop interrupts, subgraphs, a long-term memory Store, and a deployment story. Docs now live at docs.langchain.com/oss/python/langgraph - older links are stale.
• crewAI - you describe a crew of role-based agents (researcher, writer, reviewer) and the framework runs the collaboration. Fastest path from idea to multi-agent demo; the two b6 shapes are still what runs underneath.
• AutoGen - agents as conversation participants; the DLAI "Agentic Design Patterns" course teaches the four-pattern canon (Reflection · Tool Use · Planning · Multi-Agent) in it. Strong for research-style back-and-forth between agents.

Every framework above ships the same four levers under different names - tools, memory, planning, guardrails. You learned the levers on a loop you can read in one screen; a framework is just someone else's opinionated packaging of them. So the productive question is never "which framework is best" - it is "which lever do I need packaged that I do not want to maintain myself". Checkpointing is a memory lever. Interrupts are a guardrail lever. Handoffs are b6's decentralized shape. Read any quickstart with the lever map in hand and it stops being magic in about ten minutes - that is your homework tonight.

The OpenAI Agents SDK ships tracing built in - it is one of the five primitives. LangSmith does trajectory-level traces for LangGraph and friends. On raw Python, this wrapper around your b2 loop covers 80% of what those give you:

# trace.py - one JSONL line per loop step
import json, time, hashlib

def trace(kind: str, name: str = "", args=None, tokens: int = 0):
    line = {
        "ts": time.time(),
        "kind": kind,          # "model" | "tool_call" | "tool_result" | "guardrail"
        "name": name,          # e.g. query_sales
        "args_hash": hashlib.sha256(
            json.dumps(args or {}, sort_keys=True).encode()).hexdigest()[:12],
        "tokens": tokens,
    }
    with open("trace.jsonl", "a") as f:
        f.write(json.dumps(line) + "\n")

# inside the b2 loop, one call per step:
r = client.messages.create(model="claude-opus-5", max_tokens=2048,
                           tools=DAYBREAK_TOOLS, messages=messages)
trace("model", tokens=r.usage.output_tokens)
for b in r.content:
    if b.type == "tool_use":
        trace("tool_call", b.name, b.input)
        result = TOOLBOX[b.name](**b.input)
        trace("tool_result", b.name)

Hash the arguments instead of storing them raw - customer emails and ticket text do not belong in a log file, but you still want to know whether two runs made the same call. Token counts per step are your cost meter for Part 3.

What you just wrote by hand is what LangSmith calls a trajectory: the ordered sequence of steps an agent took, not just its final answer. b8's trajectory match modes - strict, unordered, subset, superset - grade exactly this object. That is the payoff of using one vocabulary across b8 and b9: your golden set graded transcripts offline; production grades the same shape of data live. When a trace platform demo looks impressive, check it against your JSONL fields - ts, kind, name, args_hash, tokens - and ask what it adds beyond search and pretty rendering. (Often plenty. But now you can name it.)

State first. In production, "memory" (b4) becomes a storage decision: server-side session state (the OpenAI SDK's Sessions primitive, or your own store keyed by conversation id) versus LangGraph-style checkpointing, where every step is durably saved and a run can resume - or be interrupted for approval - mid-task. If your b7 approval gates need a human who answers hours later, checkpointing is the shape you want.

Then cost. Three levers that do not touch quality where it matters:

• Model tier per step - the planner runs on a big model (claude-opus-5 in our path); the tool-result summarizer runs on a small one. Most steps in a long run are small-model steps.
• Prompt caching - the system prompt and tool schemas are identical every turn; cache them and stop paying full price to resend your own instructions.
• Budgets from b7, promoted to config - max turns and spend ceilings stop being demo code and become deploy-time settings someone can audit.

• MCP - write the Daybreak server once, and any MCP-speaking host can use it: your raw loop, Claude Code, an Agent SDK app. Tools stop being framework-locked. You have lived this since the MCP course; b2 made it your agent's toolbox.
• A2A - the same idea one level up: a standard way for one agent to discover another's capabilities and delegate to it, regardless of which framework either was built on. b6's manager and handoff shapes, but across organizational and framework boundaries.
• One sentence to keep: MCP is how an agent talks to its tools; A2A is how an agent talks to other agents.

A2A here is positioning only - implementing an A2A server is out of this course's scope, by design. If you want the hands-on version, the DLAI "A2A Protocol" short course (Google + IBM, ~1.5h) builds one. Take the lever map and the two-protocol sentence with you; they make that course a fast read.