What does LangChain's AgentExecutor actually do?

AgentExecutor is a while loop that calls the LLM, checks if the response contains tool_calls, executes matching tools from a registry, appends results to the messages array, and repeats until the LLM returns a final answer with no tool requests.

Can I build an AI agent without LangChain?

Yes. The core agent pattern is about 60 lines of Python: an HTTP POST to the LLM API, a dict of tool functions, and a while loop that dispatches tool calls. LangChain wraps these patterns in classes, but the underlying logic is simple enough to write directly.

When should I use LangChain vs plain Python?

Use LangChain when you need multiple LLM provider integrations, production vector store retrieval (RAG), or LangSmith observability. Use plain Python when your agent is straightforward, you want full debugging control, or you're learning how agents work.

What makes Pydantic AI different from LangChain?

Pydantic AI focuses on type safety — typed tool parameters, structured outputs via Pydantic models, and compile-time checking. LangChain focuses on integration breadth — hundreds of connectors for vector stores, document loaders, and LLM providers. Pydantic AI is narrower but catches more bugs at write-time.

Do I need to know Pydantic to use Pydantic AI?

Basic Pydantic knowledge helps — defining models with typed fields and understanding validation. But the agent API is straightforward: define an Agent with a result type, decorate tool functions, and call agent.run(). If you know Python type hints, you can learn the Pydantic parts as you go.

Can Pydantic AI work with any LLM provider?

Yes. Pydantic AI supports 25+ model providers through a unified interface. You specify the model as a string like 'openai:gpt-4o' or 'anthropic:claude-sonnet' and the framework handles the API differences. Switching providers is a one-line change.

Comparisons / LangChain vs Pydantic AI

LangChain vs Pydantic AI: Which Agent Framework to Use?

LangChain langchain is the most popular agent framework. Pydantic AI pydantic ai is a type-safe agent framework built by the pydantic team. Here is how they compare — and what the same patterns look like in plain Python.

By the numbers

LangChain

GitHub Stars

132.3k

Forks

21.8k

Language

Python

License

MIT

Created

2022-10-17

Created by

Harrison Chase

Backed by

Sequoia Capital, Benchmark

Funding

$25M Series A (2023), $25M Series B (2024)

Weekly downloads

3.5M

Cloud/SaaS

LangSmith (observability), LangServe (deployment)

Production ready

Yes

Used by: Notion, Elastic, Instacart

github.com/langchain-ai/langchain →

Pydantic AI

GitHub Stars

16.1k

Forks

1.9k

Language

Python

License

MIT

Created

2024-06-21

Created by

Pydantic (Samuel Colvin)

github.com/pydantic/pydantic-ai →

GitHub stats as of April 2026. Stars indicate community interest, not necessarily quality or fit for your use case.

Concept	LangChain	Pydantic AI	Plain Python
Agent	AgentExecutor with LLMChain, PromptTemplate, OutputParser	Agent() class with typed result_type, system prompt, and model parameter	A function that POSTs to /chat/completions and returns the response
Tools	@tool decorator, StructuredTool, BaseTool class hierarchy	@agent.tool decorator with typed parameters and Pydantic validation	A dict of callables: tools = {"add": lambda a, b: a + b}
Agent Loop	AgentExecutor.invoke() with internal iteration	agent.run() handles the tool-call loop internally with typed dispatch	A while loop: call LLM, check for tool_calls, execute, repeat
Conversation	ConversationBufferMemory, ConversationSummaryMemory	—	A messages list that persists outside the function
State	LangGraph state channels with typed reducers	—	A dict updated inside the loop: state["turns"] += 1
Memory	VectorStoreRetrieverMemory, ConversationEntityMemory	—	A dict injected into the system prompt, saved via a remember() tool
Guardrails	OutputParser, PydanticOutputParser, custom validators	—	Two lists of lambda rules checked before and after the LLM call
Structured Output	—	result_type=MyModel enforces Pydantic model on final LLM response	Parse the LLM response as JSON, pass to a validation function, retry on failure
Model Switching	—	Swap model='openai:gpt-4o' to model='anthropic:claude-sonnet' in one line	Change the API endpoint URL and adjust the request/response format mapping
Dependencies	—	RunContext[DepsType] injects typed dependencies into tools at runtime	Pass a deps dict to your agent function, tools access it via closure or argument

What both do in plain Python

Every concept in the table above — agent, tools, loop, memory, state — maps to a handful of Python primitives: a function, a dict, a list, and a while loop. Both LangChain and Pydantic AI wrap these primitives in their own class hierarchies and APIs. The underlying pattern is the same ~60 lines of code. The difference is how much ceremony each framework adds on top.

When to use LangChain

LangChain adds value when you need production integrations (vector stores, specific LLM providers, deployment tooling). But if you want to understand what's happening — or your use case is straightforward — the plain Python version is easier to debug, modify, and reason about.

What LangChain does

LangChain provides a unifying interface across LLM providers, a class hierarchy for tools and memory, and orchestration via AgentExecutor and LangGraph. The core value proposition is interchangeable components: swap OpenAI for Anthropic by changing one class, plug in a vector store for retrieval, add memory without rewriting your loop. It also ships with dozens of integrations — document loaders, text splitters, embedding models, vector stores — that save you from writing boilerplate HTTP calls. For teams that need to compose many integrations quickly, this catalog is genuinely useful. The tradeoff is that you inherit a large dependency tree and a set of abstractions that sit between you and the actual API calls.

The plain Python equivalent

Every LangChain abstraction maps to a small piece of plain Python. AgentExecutor is a while loop that calls the LLM, checks for tool_calls in the response, executes the matching function from a tools dict, appends the result to a messages array, and repeats. Memory is a dict you inject into the system prompt. Output parsing is a function that validates the LLM's response before returning it. The entire agent — tool dispatch, conversation history, state tracking, guardrails — fits in about 60 lines of Python. No base classes, no decorators, no chain composition. Just a function, a dict, a list, and a loop. When something breaks, you read your 60 lines instead of navigating a class hierarchy.

Full LangChain comparison →

When to use Pydantic AI

Pydantic AI adds genuine value if you want compile-time type checking across your agent's tools, outputs, and dependencies. If you already use Pydantic in your stack, it fits naturally. But the core agent logic — loop, dispatch, validate — is still ~60 lines of Python you can own entirely.

What Pydantic AI does

Pydantic AI wraps the agent pattern in Pydantic's type system. You define an Agent with a result_type (a Pydantic model), register tools with typed parameters via decorators, and call agent.run() to execute the tool-call loop. The framework validates tool arguments against their type hints, validates the final response against your result model, and retries on validation failures. It supports 25+ model providers through a unified interface, so switching from OpenAI to Anthropic is a one-line change. Dependencies are injected via typed RunContext, giving your tools access to databases, API clients, or configuration without global state. The real value is that your IDE catches type errors before runtime.

The plain Python equivalent

Type-safe tool dispatch in plain Python means validating tool arguments before calling the function. Parse the LLM's tool_call arguments as JSON, check types with isinstance or a simple schema, and raise on mismatch. Structured output is the same: parse the final response as JSON, validate against expected keys and types, retry if it fails. Model switching means swapping the API URL and adjusting the request format — a dict mapping provider names to endpoint configs. Dependency injection is passing a deps dict to your agent function that tools access via closure. The full typed agent is about 60 lines, plus maybe 20 for validation helpers. No decorators, no base classes — just functions with type checks.

Full Pydantic AI comparison →

Or build your own in 60 lines

Both LangChain and Pydantic AI implement the same 8 patterns. An agent is a function. Tools are a dict. The loop is a while loop. The whole thing composes in ~60 lines of Python.

No framework. No dependencies. No opinions. Just the code.

Build it from scratch →