Choosing an agent framework

A framework should make your state, permissions, and failures easier to understand. Start from requirements, not a popularity list.

Evaluate the abstractions you will depend on

Frameworks may offer tool adapters, graph execution, checkpoints, tracing, or human approval flows. Those features have different operational semantics. Ask what is persisted, how retries work, what happens during an upgrade, and whether you can inspect every decision boundary.

How it works

Build a thin vertical slice of the support assistant in a candidate framework: one policy lookup, one validated response, one injected failure, and one resume. Measure implementation complexity alongside runtime outcomes. Pin package versions and use current official documentation for SDK syntax; conceptual pseudocode should not masquerade as a runnable provider integration.

A concrete example

A graph abstraction may be valuable when you need durable branching execution. A small read-only pipeline might be clearer with ordinary functions. Switching frameworks will not repair a weak evaluation dataset or missing authorization checks.

Apply it to your assistant

Add an approval requirement and see whether the candidate meets all required capabilities. Before running the exercise, predict the result. Afterward, explain which assumption changed and add one case where the system should refuse, ask for clarification, or escalate.

All exercise inputs and outputs are deterministic teaching examples. No language model is called. Run the same idea against a versioned dataset before making a production claim.

Key takeaway

Choose abstractions based on tested operational requirements and keep domain logic portable.

JavaScript exercise: Choosing an agent framework · code experiment

Add an approval requirement and see whether the candidate meets all required capabilities.

const required = ['checkpoint', 'trace', 'cancel'];
const candidate = new Set(['checkpoint', 'trace']);
const missing = required.filter(capability => !candidate.has(capability));
console.log({ suitable: missing.length === 0, missing });
console.log('Illustrative capability checklist, not a real framework comparison.');

Knowledge check

What is a useful framework proof of concept?

1. A happy-path demo only
2. A small real workflow including failure, recovery, and inspection
3. The framework with the most logos

Sources

• LangGraph overview — LangChain, Living documentation. Graph-based orchestration, state, persistence, and long-running workflows.

Read this lesson as Markdown

Continue learning

• On-device agents — Local inference can change privacy, connectivity, and latency tradeoffs, but it brings device limits and model-distribution costs.
• Choosing an agent framework — A framework should make your state, permissions, and failures easier to understand. Start from requirements, not a popularity list.
• Capstone: a support assistant — Connect the architecture to an evaluation plan. Your finished project should explain not only how it works, but why it is ready—or not ready—to ship.
• Reading agent case studies critically — A case study is evidence about a particular system under particular conditions. Learn to separate transferable ideas from headline claims.