Stack Selection Field Guide
Turning the curriculum into choices: when to use an SDK, graph runtime, durable workflow engine, protocol, or local control plane.
- Before any framework, ask: who should decide the next step? Code, model, graph, scheduler, or human.
- Pick the layer that owns the failure mode: SDK → graph → durable engine → protocol.
- Graphs for state, not aesthetics. Durable engines for time and failure, not prompt quality.
- Every layer has a job, and every run should leave evidence.
The Missing Decision Layer
The earlier chapters explain the pieces. The decision you still need is where each piece belongs.
A good AI system usually has layers:
agent or workflow instructions
-> model/tool SDK
-> graph or workflow runtime
-> durable execution layer
-> protocols and integrations
-> artifacts, traces, evals, and human review
You do not need every layer for every task. You add a layer when a real failure mode appears.
Start With The Control Question
Before choosing a framework ask:
Who should decide the next step?
Use this shorthand:
| next-step owner | use when | examples |
|---|---|---|
| Code | Steps are known and correctness matters | validations, release checks, report generation |
| Model | The next step depends on semantic judgment | research, triage, summarization, planning |
| Graph | State, branches, loops, or interrupts matter | multi-step investigations, approval gates, retries |
| Scheduler | Time, queues, or background execution matter | recurring monitors, delayed follow-ups, batch work |
| Human | Risk or ambiguity is high | deletes, sends, purchases, policy calls, merge gates |
The framework follows from that answer.
What Each Layer Is For
Agent SDK
Use an agent SDK when you need:
- model calls
- tools
- structured outputs
- handoffs
- tracing
- guardrails
Graph Or Workflow Runtime
Use a graph or workflow runtime when the shape of the work matters as much as the prompt.
Durable Execution Engine
Use a durable execution engine when failure recovery is part of the product.
Protocols
Use protocols to connect systems. Do not use them to replace orchestration.
Local Workflow Control Plane
Use a local control plane when your real problem is consistency across tools.
A control-plane repo like this should stay focused on:
- authored workflow contracts
- MCP manifests
- generated installs
- validation
- artifacts
If it grows the clean next layer is a narrow bridge to a runner for the few workflows that truly need scheduling or retries or resumability.
A Practical Selection Matrix
| situation | default choice | why |
|---|---|---|
| The task is one interactive agent with tools | Agent SDK | Smallest useful abstraction |
| The task needs branches, loops, or human interrupts | Graph runtime | Control flow and state are first-class |
| The task must survive crashes or delayed approvals | Durable engine under the agent logic | Reliability belongs below the reasoning layer |
| The task is mostly tool access across clients | MCP | Protocol solves portability |
| The task delegates to remote agents owned by other systems | A2A | Agent interoperability boundary |
| The task is a repeatable local operating procedure | An authored local workflow | Authored procedure and artifacts matter more than runtime autonomy |
| The task is expensive or risky | Workflow plus eval plus human gate | Control beats autonomy |
| The task is exploratory research | Agent or graph depending on depth | Let the model plan, but preserve evidence |
Promotion Ladder
A workflow should graduate only when the lower level hurts.
Level 1: checklist or prompt
Level 2: authored workflow with artifact contract
Level 3: deterministic script or runner
Level 4: graph with state and checkpoints
Level 5: durable scheduled service
Level 6: eval-driven improvement loop
- the same steps are repeated manually
- results are hard to audit
- failures are hard to reproduce
- retries are common
- humans need to approve later
- runs take too long for a chat session
- cost or latency needs measurement
- model choice needs routing data
- improvements need an eval bank
Do not move up because a framework is popular.
Recommended Default Stack
For a serious but still practical system:
OpenAI Agents SDK or provider SDK
+ LangGraph when stateful control flow appears
+ Temporal or Inngest when durability appears
+ MCP for tool/context interoperability
+ artifacts, traces, evals, and human gates from day one
If the organization is Microsoft-heavy use Microsoft Agent Framework earlier.
If the organization is Google/Gemini-heavy use Google ADK earlier.
If the system is RAG-heavy LlamaIndex Workflows may deserve an earlier slot.
If the goal is local cross-client operating discipline keep the authored workflow definitions as the source of truth and add runtime execution only where it pays for itself.
Practical Additions For A Local Control Plane
Not a huge runtime rewrite. A few thin and inspectable bridges go a long way.
- model
- tool
- artifact
- cost
- latency
- eval
- failure data
A promotion checklist says when a workflow becomes a script or a graph or a scheduled runner. A tool fitness bench covers MCP servers and local tools. A failure corpus turns bad runs into eval cases. And a tiny durable-runner experiment covers one workflow that currently suffers from retries or waits or scheduled follow-up.
That gives real leverage without turning the control plane into a tangled execution engine.
Taste To Develop
Pick the layer that owns the failure mode. Keep deterministic control around probabilistic calls. Use protocols at boundaries. Not as brains. Use graphs for state. Not aesthetics. Use durable engines for time and failure. Not for prompt quality. Use evals before self-improvement. Keep humans in the path where consequences matter.
The best stack is not the one with the most agents. It is the one where every layer has a job and every run leaves enough evidence to make the next run better.