Welcome back to The Agentic Shift. Over the past seven installments, we’ve carefully dissected the anatomy of an agent, peered into its different modes of thinking, mapped out its memory systems, examined its toolkit, learned how to guide its behavior, erected necessary safety guardrails, and tackled the challenge of managing its finite attention. We’ve essentially built a conceptual blueprint for an autonomous AI partner.

The ‘Simple Loop’ Fallacy

While some people will say that an agent is nothing more than a model running in a loop and using tools, if you implement your own agent you will find that there are a lot of details missing in that simple statement. Every model has its quirks—handling parallel tool calls, progressive context compression, or input context window management—all come with frustrations, and that’s before you start to deal with the unique features of each model SDK. Each time, you’ll find yourself spending 80% of your time on what one might call “undifferentiated heavy lifting” the complex but repetitive plumbing that every agent needs but that adds no unique value to your specific application.

This brings to mind something François Chollet said recently: to truly understand a concept, you have to “invent” it yourself. Understanding is an “active, high-agency, self-directed process of creating and debugging your own mental models”. And anyone who builds an agent from scratch has definitely been creating and debugging. The hands-on struggle teaches precisely where the real engineering challenges lie: state persistence across sessions, secure tool execution, intelligent context curation, and robust error handling.

The lesson is clear: build from scratch once to truly understand the fundamentals, but use a framework for everything after that. The real decision isn’t if you should use one, but which one to choose. This choice hinges on your specific needs—from single vs. multi-agent architectures to your existing cloud ecosystem, production timeline, and desired level of control. While my personal stack now favors the Google ADK for production and raw code for learning, I’ve learned the framework is just the scaffolding, not the building itself.

What Frameworks Actually Solve

The complexity frameworks address isn’t trivial. Based on my experience and research, they solve four fundamental challenges:

1. The Stateless → Stateful Transformation

LLM APIs are fundamentally stateless—each call has no memory of the previous one. Creating an agent that remembers your preferences, learns from interactions, and maintains context requires sophisticated external memory architecture, as we explored in Part 3. Frameworks provide battle-tested solutions, from simple conversation buffers to complex integrations with vector databases for semantic memory and knowledge graphs for entity relationships.

Take a customer service agent that needs to remember a user’s issue across multiple sessions. Without a framework, you’re writing database schemas, managing session state, implementing conversation history pruning, and building retrieval pipelines. Frameworks like LangGraph, however, handle much of this with just a few lines of configuration.

2. The Tool Orchestration Loop

Giving an agent “hands,” as we discussed in Part 4, means building a robust runtime that can generate machine-readable tool definitions, parse the LLM’s tool-calling decisions, validate and securely execute calls, handle errors gracefully, and feed results back into reasoning. I’ve written this loop several times. Each time, I discovered new edge cases. What happens when a tool times out? When the LLM hallucinates a non-existent function? When it tries to pass a string to an integer parameter? Frameworks have discovered these edge cases already and handle them elegantly.

3. The Context Window Crisis

As I explored in Part 7, context windows are finite and precious. Without active management, they fill with noise: old conversations, verbose tool outputs, redundant information. Frameworks offer automated strategies like recursive summarization and intelligent pruning that maintain signal while discarding noise.

4. The Security Minefield

An agent that can delete files, send emails, or execute code is a loaded weapon. The attack vectors we covered in Part 6 (prompt injection, tool manipulation, data exfiltration) are novel. Frameworks provide architectural patterns for sandboxing, human-in-the-loop approval, and policy enforcement that would take months to build from scratch.

Different Philosophies for Different Problems

The agent framework landscape isn’t just diverse; it’s philosophically fragmented. Each framework embodies a distinct worldview about how agents should be built and managed.

The Enterprise Architects: Google ADK and Microsoft’s Unified Framework

Google’s Agent Development Kit represents the “enterprise-first” philosophy. It treats agents as first-class software artifacts—with proper testing, versioning, and observability. The framework’s hierarchical multi-agent support is invaluable for scaling from a single agent to a team of specialists. The code can be verbose and the learning curve steep, but the production reliability is a key feature.

Microsoft’s newly unified Agent Framework (merging AutoGen’s innovation with Semantic Kernel’s enterprise features) takes a different approach: “conversation as computation.” Instead of explicit orchestration, agents collaborate through structured dialogue. It’s fascinating to watch, almost like a Slack channel where AI team members actually get work done.

The Developer Experience Champions: LangChain’s Evolution

LangChain’s journey mirrors the entire field’s maturation. It started with “chains”, linear sequences of operations that were intuitive but limited. The introduction of LangChain Expression Language (LCEL) formalized this into a powerful pipe syntax: prompt | model | parser.

But then came LangGraph, acknowledging what many developers learned the hard way: agents need cycles, not just chains. This directly relates to the cognitive patterns we discussed in Part 2, where simple linear “Plan-and-Execute” patterns give way to more complex, graph-based reasoning. LangGraph models workflows as stateful graphs where nodes are functions and edges are conditional logic. It’s more complex but infinitely more powerful, and has become a popular choice for developers who need fine-grained control over agent behavior.

The Minimalist’s Choice: OpenAI Agents SDK

OpenAI’s official open-source, lightweight framework takes a refreshingly minimal approach. It’s model-agnostic and provides just enough structure to be helpful without being prescriptive. Perfect for developers who want to build custom, multi-agent logic from the ground up without fighting framework opinions.

The Intuitive Collaborators: CrewAI’s Role-Playing Revolution

CrewAI took a radically different approach: what if we just described agents like job postings? You define a “Senior Research Analyst” with a goal and backstory, a “Technical Writer” with their own expertise, and let them collaborate naturally.

This model has proven to be remarkably effective for content creation pipelines, such as having a Researcher, Writer, and Editor collaborate on a blog post. The framework is designed to handle delegation, task management, and inter-agent communication transparently. In effect, you write what feels like HR documentation and get a functioning multi-agent system.

The Pythonic Pragmatists: Phidata

Phidata embodies “AI assistants as code”—clean, object-oriented Python with minimal magic. It’s a “batteries included” framework where an Assistant can be instantiated, configured with tools and a knowledge base, and deployed with a built-in UI.

For Retrieval-Augmented Generation (RAG) applications, Phidata is particularly well-suited. It is designed to handle vector database complexity, provides pre-built knowledge base classes, and manages the retrieval pipeline transparently.

Visual and Node-Based Builders: Democratizing Development

Platforms like Voiceflow, Botpress, and MindStudio represent a philosophy of visual programming for AI agents. They’re not just no-code—they’re thoughtfully designed for non-programmers to build sophisticated conversational agents, offering visual canvases, drag-and-drop logic, and built-in integrations. While you can hit walls when you need custom logic, many use cases don’t need it.

A powerful middle ground between these conversational builders and pure code exists with node-based automation platforms like n8n. These tools also use a visual, graph-based canvas, but are designed for complex data workflows, integrations, and backend logic, allowing developers to visually stitch together APIs, databases, and AI models in a way that is more robust than no-code and more accessible than a pure framework.

The Trade-offs: What You Give Up for Convenience

While frameworks accelerate development, they aren’t a free lunch, and it’s important to consider what you’re trading away. You are, in effect, trading the complexity of building from scratch for the complexity of learning a framework’s specific abstractions, such as internalizing LangGraph’s graph-based mental model or ADK’s enterprise patterns. There’s also the matter of framework overhead; these layers of abstraction can introduce performance hits or higher token usage. You might see simple tasks consume two to three times more tokens through a framework than in a hand-rolled implementation, depending on the approach. You also risk the “leaky abstraction” problem, where you eventually hit a wall that the framework’s design simply doesn’t fit. For instance, a developer might spend a week fighting a framework’s complex delegation logic when a simple round-robin task assignment is all that’s needed. Finally, in this breakneck-speed field, you’re betting on maturity and stability. APIs change, frameworks pivot, and what works today might be deprecated tomorrow—a phenomenon seen in LangChain’s multiple major architectural shifts over just two years.

Choosing Your Framework: A Practical Guide

My decision-making process for choosing a framework has evolved into a practical decision tree.

Start with Architecture: Single Agent or Multi-Agent?

For single, complex agents, your choice depends on your needs. LangGraph is ideal if you need explicit control over reasoning patterns, while the OpenAI Agents SDK is perfect if you want minimal abstractions. If your application is built around RAG, Phidata is a strong contender. For multi-agent systems, the options are philosophically different. CrewAI excels at intuitive, role-based teams, while the Microsoft Agent Framework is built for conversation-driven collaboration. For hierarchical, production-grade systems, Google ADK is the most robust choice.

Consider Your Constraints

Your production timeline is a major factor. If you’re prototyping this week, the rapid setup of CrewAI or LangChain is invaluable. If you’re building for a production launch next quarter, the enterprise-grade architecture of Google ADK or the Microsoft Agent Framework is a safer bet. For timelines somewhere in between, LangGraph or Phidata offer a balance of power and speed.

Team expertise also matters. Deep Python experience is a good fit for any code-first framework, but CrewAI’s natural language approach can be easier for mixed technical teams. For non-technical stakeholders, no-code platforms are the most accessible.

Finally, your choice depends heavily on your ecosystem and specific goals. If you’re building for production scale within Google Cloud, the Google ADK is the clear choice for its built-in Vertex AI integration and enterprise observability. Similarly, if your organization is built on Azure, the Microsoft Agent Framework provides native service integration and AutoGen’s powerful multi-agent patterns. For those needing rapid prototyping, LangChain and LangGraph offer a massive component library. If your goal is intuitive multi-agent collaboration, CrewAI’s role-based design is

remarkably effective, while the OpenAI Agents SDK is perfect for those who want minimal, clean abstractions. For visual, no-code workflow design, platforms like Voiceflow and Botpress democratize deployment; for node-based visual automation, platforms like n8n bridge the gap; and for a Python-native, full-stack experience, Phidata’s object-oriented approach is excellent.

My Personal Stack

For personal projects where I want complete control—like my Gemini Scribe agent for Obsidian, I still build from scratch. The entire agent is ~500 lines of typescript, perfectly tailored to my workflow. You can see exactly what’s happening at every step, and there’s no framework magic to debug when things go wrong.

But for more complex systems, Google ADK has become my go-to. My recent adh-cli TUI for Gemini is built with ADK, allowing me to spend more time thinking about the unique concepts I want to explore and less time on boilerplate of agent development.

The choice ultimately depends on your specific context and is a strategic decision that reflects and reinforces your approach to AI development.

Beyond The Scaffolding

Here’s what I’ve come to believe: the choice between frameworks isn’t about features—it’s about philosophy. Each framework embodies assumptions about how agents should think, collaborate, and evolve.

Adopting any framework provides immediate benefits: velocity to skip the boilerplate and focus on your unique logic; reliability from leveraging battle-tested patterns and error handling; community to tap into collective knowledge and shared solutions; and governance by enforcing architectural best practices automatically. The open-source nature of many of these frameworks means that even if you encounter a novel edge case, it’s likely you’re not alone, and a solution may already be in progress within the community.

But the real value is subtler. Frameworks don’t just accelerate development—they shape how you think about agents. LangGraph teaches you to model cognition as state machines. CrewAI makes you consider role-based decomposition. ADK asks you to think about production from day one.

The frameworks are the scaffolding necessary to build the next generation of intelligent applications. They’re transforming agent development from an artisanal craft into a systematic engineering discipline.

When One Agent Isn’t Enough

But what happens when a single agent, even one built on a sophisticated framework, hits its limits? Complex problems often require multiple perspectives, specialized expertise, and collaborative problem-solving.

In Part 9: Building an Agentic Team, we’ll explore the fascinating world of multi-agent systems. We’ll dive into orchestration patterns, examine how agents negotiate and delegate, and uncover the emergent behaviors that arise when AI agents work in teams.

If you thought managing one agent’s context window was challenging, wait until you see five agents trying to agree on a shared goal while maintaining their own specialized knowledge and constraints.

The future isn’t just agentic, it’s collaborative. And it’s already here.