The AI Learning Hub Journal

Orchestration Frameworks

Orchestrator Agentfull tool access · goal decompositionTriage SubagentTools granted:alert-read · enrich-ipIsolated context · no parent scopeInvestigate SubagentTools granted:siem-query · edr-queryIsolated context · no parent scopeReport SubagentTools granted:write-case · notifyIsolated context · no parent scopeLeast-privilege principle applied per subagent — lateral movement requires explicit re-grant, not inheritance
Subagents get scoped goals and explicit tool grants — never inherited privileges from the orchestrator

The Landscape, Honestly

The agent-framework market is crowded, fast-moving, and loud, so it helps to sort it into three schools rather than memorise brand names. Graph-based orchestrators — LangGraph is the most established — model an agent as an explicit state machine: nodes, edges, checkpoints, and replay. Vendor agent SDKs from the model labs — OpenAI's Agents SDK, Anthropic's Claude Agent SDK, Google's ADK — package the loop, tool handling, and often MCP support into an opinionated harness tuned for that vendor's models. And the raw-API school skips frameworks entirely, writing the loop directly against model APIs. All three ship real production systems. The differences are about where control lives and what you are coupled to — not about which one is "winning" this quarter.

  • Graph orchestrators: explicit state machines with checkpointing and replay — control flow you can inspect
  • Vendor SDKs: batteries-included loops from the model labs, increasingly the default entry point
  • Raw APIs: your own loop, your own state — maximum transparency, maximum responsibility
  • Multi-agent coordination layers (CrewAI and similar) sit atop these — evaluate the base loop first

The Case for Vendor SDKs — and Its Price

Vendor agent SDKs earn their popularity honestly: the lab that trains the model also tunes the harness, so tool-calling formats, prompt-caching behaviour, context management, and built-in tools work well together out of the box. Sub-agent spawning, permission hooks, and MCP client support arrive as configuration rather than engineering. For teams standardised on one model family, this is the fastest route to a competent agent. The price is coupling. An SDK's abstractions encode one vendor's opinions about how agents should work, and its roadmap follows that vendor's product strategy, not yours. Cross-provider portability ranges from partial to nonexistent. The pragmatic stance: take the SDK's leverage, but keep your tool definitions, prompts, and eval suite in your own code so the harness stays swappable.

  • The harness is tuned for the vendor's models — real quality gains, not just convenience
  • Coupling is the cost: switching providers can mean rewriting the orchestration layer
  • Own your tools, prompts, and evals as plain code — treat the SDK as a replaceable shell
  • If you need heterogeneous models in one system, a neutral layer or your own loop fits better

The Raw-API School

A serious contingent of experienced teams builds agents directly on model APIs, and their argument deserves attention: the agent loop is small — call the model, execute the returned tool calls, append results, repeat — while a framework's value concentrates in the parts around the loop that you eventually need to control anyway. When behaviour goes wrong, a framework means debugging through layers of someone else's abstraction to find which prompt actually went to the model; your own loop means reading your own code. Frameworks front-load convenience and back-load opacity. The honest trade: raw APIs cost you upfront engineering for retries, streaming, state persistence, and provider quirks — everything a framework gives you for free until the day its abstraction fights your requirements.

  • The core loop is a modest amount of code; the hard parts are tools, prompts, context, and evals — which frameworks don't solve for you
  • Every abstraction between you and the prompt is a place where debugging gets harder
  • You pay upfront for plumbing: retries, streaming, persistence, rate limits, provider drift
  • A strong middle path: raw loop plus MCP for tool integrations — standardised edges, transparent core

Framework Churn and Selection Criteria

Framework churn is a real line item, not a meme. This ecosystem has already seen major frameworks rewrite their core abstractions, deprecate flagship APIs, and fall from default choice to legacy in short order — and each swing sends teams on migrations that deliver zero user-facing value. So select on criteria that survive the churn rather than on this quarter's leaderboard. Can you see and log the exact prompt sent to the model? Can you eject — drop to raw API calls for one node — without leaving the framework? Is state explicit and persistable, so runs can be checkpointed and replayed? How deep is the abstraction stack when you debug? And is the surface area small enough to migrate off within weeks, not quarters? A framework that fails the escape-hatch test is a bet that its roadmap will match yours indefinitely. None has earned that bet.

  • Transparency: full visibility into prompts and tool schemas as actually sent
  • Escape hatches: mixing raw calls into framework flows must be possible, not heroic
  • Explicit state: checkpoint, replay, and resume are what production debugging runs on
  • Exit cost: measure it before adopting — thin harnesses over your own primitives age best
  • Agent Engineering skips the framework survey and builds the harness itself: tool design, retries and idempotency, verification, delegation cost

Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.