AI Agents: Concepts, Patterns, and Frameworks

An AI agent is not just an LLM with a longer prompt. It is a software system in which a model can choose actions, observe their results, and continue working toward a goal within boundaries defined by application code.

The useful questions are therefore not only “which model does it use?” They are also:

Who decides the next step: code or the model?
What tools and data can the system access?
Where is state stored?
When must a human approve an action?
What stops the loop?
What happens if the process fails halfway through?

Where The Agent Idea Came From

Software agents existed long before modern LLMs. Classical AI and multi-agent research described agents as systems situated in an environment that can act autonomously to pursue objectives.

The 1995 paper Intelligent Agents: Theory and Practice organized the idea around properties such as:

autonomy: operating without direct intervention at every step
reactivity: responding to changes in the environment
proactiveness: taking initiative toward goals
social ability: interacting with people or other agents

Modern LLM agents use a language model as a flexible decision-making component. The 2022 ReAct paper was an influential bridge: it interleaved reasoning with actions and fed observations from external systems back into the model.

The implementation has changed, but the basic shape remains familiar:

observe the environment -> decide -> act -> observe the result -> continue

What Makes An LLM Application An Agent

An LLM agent normally combines several components.

Component	Responsibility
Model	Interprets the current context and proposes the next action or final answer
Instructions	Define the role, objectives, constraints, and expected behavior
Tools	Let the system retrieve information or affect external systems
State and context	Preserve conversation, task progress, tool results, and application data
Runner or harness	Executes the model-tool loop and enforces limits
Environment	The files, APIs, databases, applications, or sandbox the agent can affect
Policy and permissions	Decide which requested actions are actually allowed
Stop and escalation rules	End the run, request clarification, hand off, or ask for approval

The model is one component inside the agent. It does not securely store credentials, enforce authorization, persist workflow state, or recover from process failure by itself.

The Agentic Loop

The runner sends the current context to the model. The model may return a final answer, request a tool, ask for clarification, or delegate work. Tool results become new observations and the cycle continues.

flowchart TB
    G["Goal or user request"] --> R["Runner / agent harness"]
    R --> M["Model<br/>chooses the next step"]
    M -->|Final output| F["Stop and return result"]
    M -->|Tool request| P["Policy and approval checks"]
    P --> T["Tool or external action"]
    T --> O["Observation<br/>result or error"]
    O --> S["Update state and context"]
    S --> M
    M -->|More information needed| H["Clarify, escalate, or hand off"]

The important split is:

the model chooses among the actions made available to it
the runner executes the loop
trusted application code enforces permissions, budgets, limits, and approvals

Calling a tool is therefore a proposal from the model, not an authorization decision.

Chatbot, Tool Calling, Workflow, Or Agent

These are points on a spectrum rather than perfectly separate product categories.

System	Who controls the process?	Typical behavior
Chat completion	Application	One model request produces one response
Tool-calling application	Mostly application	The model may request a tool within a limited interaction
Workflow	Code	Predefined steps, branches, loops, and failure handling
Agent	Model within code-defined boundaries	The model repeatedly decides what action is needed next
Hybrid agentic workflow	Code and model	Code controls major stages; the model handles ambiguous decisions inside them

Anthropic’s architectural distinction is useful: a workflow follows predefined code paths, while an agent dynamically directs its process and tool use. In practice, production systems often combine both.

A deterministic workflow is usually preferable when the steps are already known. An agent earns its complexity when the route cannot be completely specified in advance.

Common Agent Patterns

“Agent type” usually describes an architecture pattern, not a different underlying technology. Several patterns can appear in the same system.

Pattern	How it works	Useful when
Single tool-using agent	One model chooses among tools until it can answer	The task is open-ended but has a limited action surface
Router or triage agent	Classifies the request and selects a specialist or workflow	Requests span distinct domains
Plan-and-execute agent	Produces or updates a plan, then executes its steps	Work has several dependent stages
Manager with specialists	A manager calls specialist agents as tools and combines their results	One agent should retain user-facing control
Handoff network	One agent transfers control and context to another agent	A specialist should take over the conversation
Evaluator-optimizer loop	One component produces work and another critiques it for revision	Quality can be checked against useful criteria
Durable background agent	The run persists across retries, restarts, waits, or approvals	Tasks last longer than one process or user session

More agents do not automatically produce better results. They also introduce extra model calls, context boundaries, coordination failures, latency, and debugging work. Start with one agent and split it only when specialization, isolation, parallelism, or context limits create a real need.

Code-Directed And Model-Directed Orchestration

There are two main ways to decide the route through an agent system.

Model-directed orchestration

The model chooses which tool, specialist, or handoff target to use. This is flexible, but less predictable. It works well when routing depends on semantic judgment that would be difficult to encode as rules.

Code-directed orchestration

Application code sequences agents, runs them in parallel, loops over results, and decides when to stop. This is easier to audit and test. It works well when the business process is already known.

The two styles can be mixed. Code can own the high-risk or business-critical path while a model makes bounded decisions within each stage.

Manager Versus Handoff

The distinction shown below is easy to miss.

flowchart TB
    R["Incoming request"] --> C{"Orchestration pattern"}
    C --> M["Manager retains control"]
    M --> T["Specialist runs as a tool"]
    T --> M
    M --> MR["Manager returns the result"]
    C --> H["Triage agent hands off control"]
    H --> S["Specialist becomes active agent"]
    S --> SR["Specialist returns the result"]

With agents as tools, a manager starts a nested specialist run, receives its output, and remains responsible for the final response.

With a handoff, the active agent changes. In the OpenAI Agents SDK, the specialist receives the conversation history and takes over the conversation. A handoff is not automatically a new service, process, or durable workflow.

How Current Frameworks Differ

Framework categories overlap, and their capabilities change quickly. The useful comparison is their primary abstraction and the amount of control they expect application code to own.

Framework	Primary abstraction	Main strength	Good fit
OpenAI Agents SDK	`Agent` plus `Runner`	Lightweight model-tool loops, guardrails, agents-as-tools, and handoffs	Straightforward single-agent and multi-agent applications
PydanticAI	Typed agents, dependencies, tools, and outputs	Python type safety, validation, dependency injection, and structured results	Python services with strongly typed application boundaries
Google ADK	Agents plus graph and multi-agent workflows	Combines model-driven agents with deterministic workflow structures	Agent teams and applications using the ADK runtime and deployment ecosystem
LangGraph	Stateful graph orchestration runtime	Explicit state, graph control, persistence, durable execution, and human intervention	Long-running or complex workflows that need inspectable state transitions
CrewAI	Crews plus Flows	Role-based agent teams combined with event-driven workflow control	Applications naturally modeled as collaborating roles and tasks
Microsoft Agent Framework	Agents plus graph workflows	Python and .NET agents, typed routing, sessions, middleware, telemetry, and human input	Microsoft-oriented enterprise applications needing agents and explicit workflows

Important current details:

LangChain provides higher-level agent abstractions; LangGraph is the lower-level stateful orchestration runtime underneath them.
CrewAI distinguishes autonomous agent teams called Crews from structured, event-driven Flows.
Microsoft Agent Framework is the direct successor to AutoGen and Semantic Kernel for agent development. Its official documentation still labels it public preview as of July 2026.
Google ADK supports simple agents, graph workflows, and multi-agent workflows. Its deterministic workflow structures are different from asking an LLM to choose every route.

Do not choose a framework from its number of built-in patterns. Choose it from the control, state, deployment, observability, and failure model your application needs.

Framework, Runtime, And Protocol Are Different Layers

Several products discussed alongside agents solve different problems.

Layer	What it provides	Examples
Model API	Inference and native tool calling	OpenAI, Anthropic, Google, and other model providers
Agent framework or harness	Agent definitions, loops, tools, handoffs, guardrails	OpenAI Agents SDK, PydanticAI, Google ADK, CrewAI, Microsoft Agent Framework
Stateful orchestration	Explicit state transitions, graphs, checkpoints, intervention	LangGraph and graph features in several agent frameworks
Durable execution runtime	Recovery across failures, retries, long waits, and restarts	Temporal, Dapr, Restate, DBOS
Interoperability protocol	Standard communication or capability contracts	MCP for tools/context; A2A for agent-to-agent communication

These layers can be combined. For example, an OpenAI agent can consume MCP tools and run inside a Temporal workflow. Temporal does not decide which tool the model should call, and MCP does not provide the agent loop.

Choosing An Approach

Requirement	Start with
One predictable transformation	A normal function or one model call
Known sequence of steps	Application code or a workflow engine
A bounded set of tools with flexible routing	A single-agent SDK
Explicit state, branching, pause, and resume	A graph-based orchestration framework
Distinct specialist roles or isolated contexts	Manager-and-specialist or handoff patterns
Work must survive process failure or long approval waits	A durable execution runtime
Tools must work across multiple agent hosts	MCP
Independent agents must communicate across services	A2A or an application-specific service contract

Use the simplest architecture that can meet the reliability requirement. A function is easier to test than a workflow, a workflow is easier to reason about than an open-ended agent, and one agent is easier to operate than a team of agents.

Production Boundaries

Before deploying an agent, define:

a limited tool and permission surface
trusted authorization outside the prompt
maximum turns, model calls, tokens, time, and spend
structured tool inputs and outputs
retryable versus permanent failures
idempotency for tools with side effects
approval points for destructive or externally visible actions
persisted state and recovery behavior
traces that record model, tool, handoff, and approval events
evaluations for both final outcomes and intermediate behavior

The agent concept predates LLMs; modern frameworks place an LLM inside an observe-decide-act loop.
The model is not the whole agent. The runner, tools, state, policy, environment, and stop conditions matter just as much.
Workflows let code control the route; agents let the model control some decisions. Hybrid systems are often the practical choice.
Manager, handoff, planning, routing, and evaluation are architecture patterns that can be combined.
Agent frameworks, durable runtimes, MCP, and A2A solve different layers of the system.
Framework choice should follow control and reliability requirements, not feature-list size.

Resources

Background

Official Framework Documentation And Repositories

Framework	Official documentation	Official repository
OpenAI Agents SDK	Documentation	openai/openai-agents-python
PydanticAI	Documentation	pydantic/pydantic-ai
Google ADK	Documentation	google/adk-python
LangGraph	Documentation	langchain-ai/langgraph
CrewAI	Documentation	crewAIInc/crewAI
Microsoft Agent Framework	Documentation	microsoft/agent-framework