Overview
Agent frameworks provide the plumbing that every agent needs, such as the tool-calling loop, state and memory, retries, streaming, tracing, and patterns for multiple agents. They sit on top of model APIs so you can focus on tools and business logic. Frameworks broadly fall into three styles. Graph or state-machine frameworks model the agent as explicit nodes and edges. Role-based multi-agent frameworks model a team of agents with jobs. Visual workflow tools let you connect steps in a UI with AI nodes inside.
Choosing one is a system design decision. Explicit graphs give control and testability, which suits production workflows. Conversational multi-agent frameworks are quick to prototype but harder to predict. Low-code tools are fast for integrations and automation but less flexible for complex logic. Many teams start with the provider's own SDK and adopt a framework only when state management and observability become painful.
You can build a website with raw sockets, but web frameworks give you routing, sessions, and middleware. Agent frameworks do the same for the agent loop, tools, memory, and tracing. Like web frameworks, some are opinionated and batteries-included, others minimal.
When to use it
- Building agents that need durable state, retries, and human approval steps.
- Coordinating multiple agents or long-running workflows.
- Comparing build-vs-buy options for an agent platform.
Where it shows up in interviews
Recognize it when: the interviewer asks what you would use to implement the agent.
- Design AI Agent Platform
- Design a multi-agent system
Where it is used in real software
Libraries such as LangGraph model agents as state machines with checkpoints, so runs can pause for approval and resume.
Frameworks such as CrewAI and AutoGen let you define agents with roles that hand work to each other.
Workflow tools such as n8n connect SaaS apps with AI steps for business automation.
Model vendors ship agent SDKs with tool calling, handoffs, and tracing built in.
Key terms
- State graph
- A workflow of nodes (steps) and edges (transitions), with shared state passed between them.
- Checkpoint
- Saved agent state that allows pause, resume, retry, and time-travel debugging.
- Handoff
- One agent transferring control to another specialized agent.
- Tracing
- Recording every model call, tool call, and state change for debugging.
How it works, step by step
- 1List the requirements
Decide whether you need durable state, human approval, multiple agents, streaming, and which languages.
- 2Model the workflow
Sketch the steps and decisions. If the path is mostly fixed, prefer explicit graphs.
- 3Prototype with the smallest option
Start with the model provider SDK or a thin library; add a framework when complexity justifies it.
- 4Add observability early
Choose a stack that exports traces so every run can be inspected.
- 5Plan for production
Check persistence, concurrency, deployment model, and vendor lock-in.
STEP 1Minimal loop with tools and tracing. Great starting point.
Picking a style
Four team scenarios.
| Scenario | Suggested style | Reason |
|---|---|---|
| Simple assistant with three tools | Provider SDK | Least overhead |
| Loan approval with human sign-off | State graph | Checkpoints and explicit control |
| Research report by several specialists | Role-based team | Natural division of work |
| Ops team automating Slack and CRM tasks | Visual workflow | Non-developers can maintain it |
NOWScenario: Simple assistant with three tools | Suggested style: Provider SDK | Reason: Least overhead
Match the framework to how predictable and long-running the workflow is.
Implementation
# State-graph style: explicit nodes and edges with shared statefrom typing import TypedDictfrom langgraph.graph import StateGraph, END class State(TypedDict): question: str docs: list[str] answer: str def retrieve(state: State): return {"docs": search(state["question"])} def generate(state: State): return {"answer": llm(f"Answer from {state['docs']}: {state['question']}")} graph = StateGraph(State)graph.add_node("retrieve", retrieve)graph.add_node("generate", generate)graph.set_entry_point("retrieve")graph.add_edge("retrieve", "generate")graph.add_edge("generate", END)app = graph.compile()print(app.invoke({"question": "What is our refund window?"})["answer"])Complexity and performance
Model calls dominate runtime.
Abstractions can hide what is sent to the model.
Trade-offs
Frameworks speed development but can obscure prompts and control flow. Make sure you can see and override what is sent to the model.
Deep framework adoption makes switching costly. Keep tools and business logic in plain functions the framework calls.
Variants and related techniques
General engines such as Temporal can run agent steps with retries and persistence.
Expose tools via MCP so any framework or client can use them.
Common mistakes
- Adopting a heavy framework for a single-tool agent.
Fix: Start simple and adopt a framework when state, retries, or multi-agent needs appear.
- Hiding business logic inside framework callbacks.
Fix: Keep tools as plain, tested functions.
Interview questions
How would you choose an agent framework for production?
Based on workflow predictability, need for durable state and human approval, multi-agent needs, language support, observability, and lock-in risk. Explicit graph frameworks suit controlled production flows; simple agents may need only the provider SDK.
Why are checkpoints important for agents?
Agent runs can be long and fail midway or wait for a human. Checkpoints persist state so runs can resume, retry a step, or be inspected after the fact.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Rebuild a simple agent as an explicit state machine | Medium | Nodes, edges, and checkpoints. |
| Write a framework selection matrix for your team | Easy | Requirements-driven choice. |