Build one small agent without a framework first: the tool-calling loop is about fifty lines and every framework wraps it. Then learn one framework deeply, chosen by what your project needs: LangGraph for explicit state and approvals, the OpenAI Agents SDK for quick assistants with handoffs, the Claude Agent SDK for agents that work on files.
What people tell me
I can call an LLM API and I have built a small chatbot. Now every post I see is about AI agents, and every tutorial uses a different framework: LangGraph, CrewAI, the OpenAI Agents SDK, the Claude Agent SDK, AutoGen. I started two of them and got lost in the abstractions, and the code from older tutorials does not even run anymore. I do not know whether to pick the most popular framework and go deep, try them all, or skip frameworks entirely. I want to build something I can actually explain.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Write the agent loop once by hand before touching any framework; it takes an afternoon and makes every framework readable.
- Then learn one framework deeply rather than five shallowly; the concepts transfer.
- Choose by what your project needs: explicit control flow, quick multi-agent assistants, or an agent that works on files and commands.
- Check the version and date of every tutorial, because agent SDKs change several times a year.
- Keep your tools, schemas and rules in plain code so switching frameworks later is cheap.
Short answer: loop first, then one framework
Build one small agent with no framework at all. Then pick one framework and learn it properly. Skipping the first step is why the abstractions feel confusing, and skipping the second means you reinvent persistence, tracing and approvals badly.
Why the loop first
Every agent, whatever framework it uses, runs the same loop: send the conversation and a list of tools to the model, run any tool calls it asks for, send the results back, repeat until it answers in plain text or hits a limit. With one provider's official SDK this is roughly fifty lines of Python or TypeScript.
Writing it yourself teaches you the things frameworks hide:
- what a tool definition really is (a name, a description and a JSON Schema)
- how tool calls and results are matched by id
- why cost grows with every step
- what happens when a tool fails or the model loops
After that, when a framework does something odd, you can read its traces and understand them. Stages two and three of the AI agents and MCP roadmap walk you through exactly this, and the AI agents cheat sheet has the loop in both languages.
Then choose one framework by the job
Do not choose by GitHub stars. Choose by what your project needs:
| If your agent needs... | Start with |
|---|---|
| Explicit steps, approvals, pausing for days, resuming after crashes | LangGraph |
| A customer-facing assistant with handoffs between agents and built-in tracing | OpenAI Agents SDK |
| To read and edit files, run commands and work on a codebase | Claude Agent SDK |
CrewAI, Google's Agent Development Kit, Pydantic AI, Mastra and the Vercel AI SDK are all reasonable too. The concepts carry across, which is exactly why depth in one beats a tour of five.
Good starting points: the LangGraph Documentation and the free Introduction to LangGraph course, the OpenAI Agents SDK Documentation, or the Claude Agent SDK Documentation.
The best way to learn a framework
Port the agent you built by hand. Same tools, same schemas, same test cases. Then write down what the framework gave you for free, what it hid, and how many lines changed. That comparison is also a far better portfolio piece than a framework tutorial clone, because it shows you understand what is happening underneath.
Watch out for old tutorials
Agent SDKs move fast. LangGraph reached version 1 in late 2025 and some imports moved. The MCP SDKs released version 2 in 2026 with renamed classes and packages. Before copying code, check the date and the version, and prefer the official docs.
Keep the framework thin
Put your tools, schemas, prompts and business rules in plain modules with their own tests, and let the framework only wire them together. Then an upgrade, or a switch, touches one layer instead of your whole project.
What I would do this month
- Week one: build a manual tool-calling agent with three real tools and a step limit.
- Week two: add validation with Pydantic or Zod and a few tests.
- Weeks three and four: port it to one framework and write the comparison.
If you want a project to build it around, the FYP ideas include several agent projects, and more answers like this one are in career questions.
If you would like help choosing a framework for your specific project, create a free account and book a session with me.
Was this answer helpful?
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.