Frameworks
in the Wild
You'll hear these five names constantly the moment you start reading about agents.
None of them are magic. Each one is an opinion about how to organize the same loop from Chapter 01: task, tools, memory, repeat.
What each one
actually is.
OpenAI Agents SDK
Agents, tools, and "handoffs" between agents as first-class building blocks, with guardrails and tracing baked in. The reference implementation for the vocabulary everyone now uses.
Google ADK
The Agent Development Kit: Google's toolkit for building and orchestrating multi-agent systems, with deep hooks into Gemini and Vertex AI for enterprise deployments.
CrewAI
Organises agents into a "crew," each with a role, a goal, and a task, collaborating like a small team with a manager splitting up the work.
OpenClaw
A self-hosted agent runtime that doesn't wait for a prompt. It runs on a "heartbeat," checking files and messages on its own, and plugs straight into WhatsApp, Telegram, Slack, and Discord.
Inside a Crew.
CrewAI's whole idea fits in three nouns: Agents do the work, Tasks describe the work, and a Crew runs the Tasks in order.
Agent
A role ("Researcher"), a goal (what it's trying to achieve), and a backstory (how it should behave). Add tools and an LLM, and that's the whole recipe.
Task
One job for one agent: a description of what to do, an expected_output so it knows when it's done, and optionally context, another task's output, fed in for free.
Crew
The list of agents plus the list of tasks, run under a process. Process.sequential runs them in order; Process.hierarchical adds a manager agent to decide the order itself.
One task feeds
the next.
This is the exact shape of today's notebook: a Researcher's task result becomes the Writer's context, no copy-pasting between prompts by hand.
A Crew With
a Manager.
Process.hierarchical swaps the fixed order above for a Head Chef: one agent who looks at the tickets, sizes up the kitchen, and calls the shots, the way a real line actually runs.
manager_llm. Sous Chef and the Short Order Cooks are regular agents with no task pre-assigned. The manager reads each ticket, picks whoever's free and right for it, and can send a plate back if it's not ready, nothing here is wired by hand like the fixed order above.And then there's
Groq.
Groq shows up twice on this page: once as the hosted API Chapter 03 builds on, and once as its own agentic system.
Groq
Groq Compound plans, searches the web, and runs code on its own, no extra framework required. The plain Groq API underneath it, just a model with no agentic layer, is what Chapter 03 builds on by hand.
Same 3 ideas.
Different outfit.
Why we won't wire
one up today.
Frameworks earn their keep once you have many agents, many tools, and a real need for orchestration, guardrails, and observability across a team.
For your first agent, a framework is often more surface area to learn than the concept itself.
What we'll do instead
Just Groq's API directly
One tool. One handoff condition.
Nothing hidden behind an SDK abstraction
the frameworks above will read like shortcuts, not magic
Enough landscape.
Let's build the loop.
Next: why Groq is the easiest place to feel tool calling and handoffs happen in real time.
← Chapter 01Chapter 03: Groq Handoffs & Tools →