CSE Roadmap

Common tier · about 3 hours · 6 parts

Part 4 of 6 · 6 min read

Interview questions and limits

Covers: Interview questions, with the follow-ups; Common mistakes; What the example does not do.

Interview questions, with the follow-ups

How do you choose an agent framework?

"I start from the requirements the framework must meet and compare on capabilities that are stable: state and persistence, pause and resume, multi-agent control, tracing, provider portability and deployment. Brand comes last. I begin with a thin loop on the provider API if the task is small, and I put the framework behind my own interface so that it can be replaced." Follow-up: "Which would you pick for a long-running approval workflow?" One with a documented durable checkpoint store and a pause primitive, such as LangGraph's checkpointers with human-in-the-loop; I would verify the current docs and test a crash-and-resume before committing.

What does checkpointing give you, and what does it not?

"It lets a run resume from the last saved step, so fewer repeated model calls and more completed runs. In my simulation at 30 percent crashes per step, calls fell from 11.6 to 8.0 and completion rose from 67.5 to 94.5 percent. It does not make side effects exactly-once: a crash between the effect and the checkpoint repeats the step, so I add idempotency keys; with them duplicates went from 0.34 to 0 at 15 percent." Follow-up: "Why not just checkpoint after every effect?" Still a gap between the effect and the write; only an idempotent receiver closes it.

Handoff or agent-as-tool?

"Handoff transfers control, so the specialist talks to the user and sees the history; agent-as-tool keeps a manager in charge and passes a brief. Handoff is simpler for two agents; agent-as-tool avoids carrying a long history, and in my token model it was cheaper from three specialists up, 17,250 against 19,500 at five. The numbers depend on brief and summary sizes." Follow-up: "Which is easier to debug?" OpenAI's guide lists trace legibility as a reason to split at all; I would pick the one whose trace I can read.

Why not use a framework for everything?

"A framework hides the loop, and when an agent misbehaves I must know the exact prompts, tool results and stop reasons. It can also add a dependency that changes quickly. I use one when it provides something I would otherwise build and maintain, like durable state or tracing." Follow-up: "What do you lose by building directly?" Integrations, community patterns and, often, durable execution that is hard to get right.

Common mistakes

  • Choosing by popularity instead of by capability.
  • Believing that a checkpoint makes side effects exactly-once.
  • Treating a vendor's framework comparison table as neutral.
  • Passing the whole history on every handoff without measuring the cost.
  • Comparing frameworks on a toy task that none of them is stressed by.
  • Depending on framework types throughout the codebase, so switching is a rewrite.
  • Not pinning versions, so a change in the framework changes behaviour.

What the example does not do

  • No framework code. It shows paradigms, not LangGraph, the Claude Agent SDK or the OpenAI Agents SDK.
  • Crashes are only at one point, after the work and before the record. Real failures also happen mid-call and in the store.
  • A scripted model. There are no model errors and no variation in the number of steps.
  • No storage cost. A checkpoint is free here; in practice it has latency and size.
  • Token sizes are assumed and the handoff model ignores caching (module 1 of this level shows that caching changes the comparison).
  • Optional real experiment (I did not run this): implement the same two-tool task in two frameworks, kill the process halfway, resume, and count repeated tool calls and tokens.

Check yourself

A framework offers a graph, a loop and handoffs. How do you choose between them? (By the hardest requirement: durable multi-day runs with approvals suggest a graph with a store; a tool-using coding agent suggests an SDK built around its loop; several specialists suggest handoffs or agents as tools.)

For the curious What this module cannot tell you

It measured no real framework. The simulation shows only the shape: a plain loop that restarts after a crash repeats work, a graph that resumes from a checkpoint does not, and an idempotency key stops a repeated side effect. The documented facts about named frameworks were read on 31 October 2026 and will drift.

What you will use daily at work

Practice What it looks like
Put the framework behind your own interface Model calls, tools and state, so switching means rewriting an adapter.
Compare capabilities Persistence, deployment, guardrails, tracing.
Re-check on a schedule Treat any comparison table as dated.

Draft: confirm which framework and version your team uses and read its current documentation.

What you must be able to say (one page)

  • A framework is a bundle of paradigms plus plumbing. The paradigms are a loop (model, tool, model, until no tool call), a graph with checkpoints (named steps, typed state saved per step), and handoffs or agents-as-tools (who holds control and what context they see). The plumbing is tool schemas, tracing, guardrails, sessions, and integrations.
  • Compare on stable capabilities, not on names, because frameworks change fast. What production needs: workflow persistence, deployment, guardrails and observability. Frameworks are not necessary, and many teams build directly on provider APIs.
  • Documented facts as of 31 October 2026 (read from official docs that day; they will drift):
  • LangGraph saves per-thread state as checkpoints keyed by a thread_id, which the docs say enables short-term memory, human-in-the-loop, time travel and fault tolerance. In-memory saver is not for production; SQLite is for development; Postgres is the production option. Checkpoints accumulate and need pruning.
  • Claude Agent SDK is Claude Code's agent loop, built-in tools and context management as a Python and TypeScript library. It stops when the model returns no tool call, or at max_turns or max_budget_usd. The result message carries a subtype (success, error_max_turns, error_max_budget_usd, and others), cost, usage, turn count and a session id for resume or fork. Hooks (PreToolUse, PostToolUse, Stop, SubagentStart) intercept the loop.
  • OpenAI Agents SDK has agents, handoffs, agents-as-tools, guardrails, sessions, human in the loop and tracing. OpenAI's own guide says to start with one agent and split only for capability isolation, policy isolation, prompt clarity or trace legibility.
  • My simulation (scripted model, no framework): with a 15 percent chance of crashing at each step, a plain loop that restarts used 9.1 model calls per run against 6.9 for a checkpointed graph; at 30 percent, 11.6 against 8.0 and it finished only 67.5 percent of runs against 94.5 percent. But checkpointing alone still repeated side effects (0.34 duplicates per run at 15 percent); only an idempotency key brought that to 0.00.
  • Handoff versus agent-as-tool is a context-cost question. With assumed token sizes, handoff (each agent sees the full history) was cheaper for 1 to 2 specialists and agent-as-tool (each sees a brief) cheaper from 3 up: 19,500 against 17,250 tokens at 5, and 36,000 against 28,200 at 8.
  • What you cannot say from this module: which framework is faster, cheaper or more accurate. I measured none of them.