Building Agents: Frameworks and Patterns

The framework landscape in 2026

A year ago, frameworks differed a lot in what they could do. Today most of them can run a tool loop, call MCP servers, hand off to sub-agents and pause for a human. The real differences are now who runs the infrastructure, which models are first-class, and how much structure the framework imposes (a free-running loop versus an explicit graph).

How to choose

There is no best framework, only a best fit for your constraints. Work through these questions in order. The early answers usually narrow the field to two or three options.

1. 1

   Which models must you support?

   If you are committed to one provider, its own SDK gets new features first (Claude Agent SDK, OpenAI Agents SDK, ADK for Gemini). If you need to swap models or run open-weight ones, favor model-agnostic options like LangGraph, Pydantic AI, Strands or CrewAI.

2. 2

   Who runs the infrastructure?

   If you want state, scheduling and sandboxes handled for you, look at a managed platform (Claude Managed Agents, OpenAI Agents API, Bedrock AgentCore). If data must stay in your environment, use a library and host it yourself.

3. 3

   Free loop or explicit graph?

   Open-ended tasks such as research, coding or triage suit a model-driven loop. Regulated or multi-step business processes suit an explicit graph (LangGraph, ADK 2.0 workflows, Microsoft Agent Framework workflows, CrewAI Flows), where you can see and test every path.

4. 4

   What does your stack already use?

   .NET shops tend to pick Microsoft Agent Framework. AWS-heavy teams tend to pick Strands and AgentCore. Google Cloud teams tend to pick ADK. Fighting your platform costs more than any framework feature saves.

5. 5

   Does it speak the protocols?

   Make sure it can consume MCP servers and can expose or call agents over A2A. Then your tools and agents can outlive the framework choice.

Hands-on: a minimal agent with the Claude Agent SDK

The Claude Agent SDK gives you the Claude Code harness as a library. You call query() with a prompt and options, and it streams back messages while the agent works. Custom tools are plain async functions wrapped with @tool and served through an in-process MCP server. The SDK uses MCP even for local tools, so the same tools can later move to a remote server without changing the agent.

import asyncio
from typing import Any
from claude_agent_sdk import (
    query, ClaudeAgentOptions, ResultMessage, tool, create_sdk_mcp_server,
)

# 1. A tool is an async function plus a name, description and input schema.
@tool("lookup_order", "Look up an order's status by its ID", {"order_id": str})
async def lookup_order(args: dict[str, Any]) -> dict[str, Any]:
    status = {"A100": "shipped", "A101": "delayed"}.get(args["order_id"], "unknown")
    return {"content": [{"type": "text", "text": f"Order {args['order_id']}: {status}"}]}

# 2. Serve the tool from an in-process MCP server.
orders = create_sdk_mcp_server(name="orders", version="1.0.0", tools=[lookup_order])

async def main():
    options = ClaudeAgentOptions(
        system_prompt="You are a concise support agent. Use tools; never guess order status.",
        mcp_servers={"orders": orders},
        allowed_tools=["mcp__orders__lookup_order"],  # auto-approve only this tool
        max_turns=6,          # stop runaway loops
        max_budget_usd=0.50,  # stop runaway spend
    )
    # 3. The SDK runs the loop: model -> tool call -> result -> model ...
    async for message in query(prompt="Where is order A101?", options=options):
        if isinstance(message, ResultMessage):
            print(message.result)
            print("cost:", message.total_cost_usd)

asyncio.run(main())

• You never write the loop. The SDK decides when to call tools and when to stop. You shape that through the system prompt, the tools and the limits.
• allowed_tools is an approval list, not a sandbox. It auto-approves the tools you name. Use disallowed_tools to block a tool entirely, and a can_use_tool callback (with ClaudeSDKClient) for custom approval logic.
• Limits are part of the design. max_turns and max_budget_usd turn a possible runaway into a clean error you can handle.
• Built-in tools come for free. Tools such as Read, Grep and Bash are available, which makes this SDK a strong fit for agents that work with files and code.

The same idea in the OpenAI Agents SDK

Here is the same support agent in OpenAI's Agents SDK. The vocabulary changes, but the shape does not: an agent is instructions plus tools, and a runner drives the loop. The SDK builds the tool schema from the Python type hints and docstring.

import asyncio
from agents import Agent, Runner
from agents.decorators import tool

@tool
def lookup_order(order_id: str) -> str:
    """Look up an order's status by its ID."""
    status = {"A100": "shipped", "A101": "delayed"}.get(order_id, "unknown")
    return f"Order {order_id}: {status}"

agent = Agent(
    name="Support Agent",
    instructions="You are a concise support agent. Use tools; never guess order status.",
    tools=[lookup_order],
)

async def main():
    result = await Runner.run(agent, "Where is order A101?")
    print(result.final_output)

asyncio.run(main())

Wiring up: tools over MCP, agents over A2A

Real agents rarely live alone. A useful mental model from 2026: MCP is vertical (an agent reaching down to tools and data) and A2A is horizontal (an agent delegating to another, opaque agent that has its own reasoning and state). Both are now governed under the Linux Foundation's Agentic AI Foundation.

Consuming tools over MCP. Instead of writing every tool yourself, connect to an MCP server. Here the OpenAI Agents SDK connects to a remote server over Streamable HTTP and passes along a bearer token:

import asyncio, os
from agents import Agent, Runner
from agents.mcp import MCPServerStreamableHttp

async def main():
    async with MCPServerStreamableHttp(
        name="orders-mcp",
        params={
            "url": "https://mcp.example.com/mcp",
            "headers": {"Authorization": f"Bearer {os.environ['MCP_TOKEN']}"},
        },
        cache_tools_list=True,
    ) as server:
        agent = Agent(
            name="Support Agent",
            instructions="Answer order questions using the MCP tools.",
            mcp_servers=[server],
        )
        result = await Runner.run(agent, "Where is order A101?")
        print(result.final_output)

asyncio.run(main())

Exposing your agent over A2A. To let other agents call yours, publish it as an A2A server. A2A will then advertise an Agent Card (its name, skills, endpoint and auth requirements) at a well-known URL. Google's ADK can do this in one line with to_a2a(), which builds the card from your agent's definition:

# server: agent.py
from google.adk.agents.llm_agent import Agent
from google.adk.a2a.utils.agent_to_a2a import to_a2a

def lookup_order(order_id: str) -> dict:
    """Look up an order's status by its ID."""
    return {"order_id": order_id, "status": "delayed"}

root_agent = Agent(
    model="gemini-flash-latest",
    name="order_agent",
    description="Answers questions about order status.",
    instruction="Use lookup_order to answer order questions.",
    tools=[lookup_order],
)

a2a_app = to_a2a(root_agent, port=8001)
# run with: uvicorn agent:a2a_app --host localhost --port 8001

# client: another agent that delegates to it
from google.adk.agents.remote_a2a_agent import RemoteA2aAgent, AGENT_CARD_WELL_KNOWN_PATH

order_agent = RemoteA2aAgent(
    name="order_agent",
    agent_card=f"http://localhost:8001{AGENT_CARD_WELL_KNOWN_PATH}",
)

Architecture patterns

Anthropic's "Building effective agents" guidance still holds: prefer simple, predictable workflows, and reach for autonomous agents only when the task truly needs open-ended decisions. Most production systems combine a few of these patterns.

Production concerns

A demo agent runs once on your laptop. A production agent runs thousands of times, for hours, against real systems and untrusted input. Five concerns separate the two.

A "start simple" checklist

Most failed agent projects did not fail because the model was too weak. They failed because the system was too complex too early. Use this checklist on your first build.

1. Write down the task and what "done" looks like. If you cannot check success, you cannot improve the agent.
2. Try a single prompt or fixed workflow first. Only add a loop if the steps genuinely vary per request.
3. Start with one agent and three to five well-described tools. Clear tool names and descriptions matter more than clever prompts.
4. Set hard limits on turns, spend and wall-clock time from day one.
5. Run tools in a sandbox with least-privilege credentials scoped to this agent.
6. Require approval for irreversible actions until the eval data shows you can relax it.
7. Turn on tracing and read the transcripts of real runs every week.
8. Build 20 to 50 eval cases from real requests and rerun them on every change.
9. Only then consider sub-agents, graphs or A2A, when you can name the specific limit you are hitting.