Pattern 4: Agentic Workflows

In one line: An agent is an LLM that picks a tool, observes the result, picks the next tool, and keeps going until it decides the task is done — multi-step reasoning over a sandbox of capabilities.

In plain English

Function calling lets the model call one tool. An agent lets it loop: call a tool, see the output, decide whether to call another, and so on. This is what powers Claude Code, Cursor, customer-support agents, and research assistants. The cost: many LLM calls per task, longer latency, and a much higher need for careful guardrails because the agent is autonomously taking actions.

The LLM plans a sequence of steps, executes them, and adjusts based on results. "Agents."

Simple agent loop

In words:

1. LLM receives task + available tools.
2. LLM decides next action (call a tool, or finish).
3. Tool is executed; result returned.
4. LLM sees the result, decides next action.
5. Repeat until LLM signals completion.

Jargon: This is what people mean by agentic — the model is in a loop, picking its own next step instead of being driven by a fixed script. Tool calls are the agent's only way to affect the outside world (read a file, call an API, write to a DB).

Example use cases

• Coding agents. Read code, edit files, run tests, iterate (Claude Code, Cursor compose, Devin).
• Research agents. Search the web, read pages, synthesize findings.
• Customer support agents. Look up account, check policy, take action, draft response.
• Sales/CRM agents. Update records based on email content.
• Operations agents. Diagnose incidents, run runbooks.

Implementation tools

• Vercel AI SDK with tool calling — sufficient for simple agents.
• LangChain.js — More elaborate agent patterns.
• LangGraph — State-machine-based agent orchestration.
• Inngest / Trigger.dev — Durable execution (agents that survive crashes).
• Temporal — Heavy-duty workflow orchestration.

MCP (Model Context Protocol)

An agent is only as useful as the tools it can reach. Early on, every team hand-wrote those tools — a searchTwitter function here, a lookupInvoice function there — and re-wrote them for every framework. MCP (Model Context Protocol) is the standard that fixes that: a single open protocol for handing a model tools, data, and prompts, so a capability you expose once works with any MCP-aware client (Claude, Claude Code, Cursor, and — as of mid-2026 — the AI SDK).

In plain English

Think of MCP as USB for AI tools. Before USB, every device had its own connector; after it, one port fits everything. Before MCP, every "give the model access to my database / Slack / files" integration was bespoke per app. With MCP, you run (or install) an MCP server that exposes those capabilities in a standard shape, and any MCP-aware agent can plug into it. Introduced by Anthropic in late 2024; by 2026 it's a widely adopted standard (OpenAI, Google, and Microsoft support it too).

An MCP server exposes three kinds of things — this distinction is the durable part:

• Tools — functions the model can call to take an action or fetch live data (query a DB, search the web, file a ticket). This is the agent's hands.
• Resources — data the model can read for context (a file's contents, a record, a doc). This is the agent's reference material.
• Prompts — reusable, parameterized prompt templates the server offers to guide a workflow.

// AI SDK 6: connect to an MCP server and let an agent use its tools
// as if they were defined locally. (@ai-sdk/mcp is stable as of mid-2026.)
import { experimental_createMCPClient as createMCPClient } from 'ai';

const mcp = await createMCPClient({
  transport: { type: 'http', url: 'https://example.com/mcp' },
});

const tools = await mcp.tools();   // the server's tools, ready for the model

// Pass `tools` into your agent / streamText call — the loop from this page,
// but the tool definitions came from the MCP server, not your codebase.

In English: Instead of defining each tool by hand, you connect to an MCP server and ask it for its tools. The agent loop is unchanged — it still calls a tool, observes, and decides the next step — but the catalog of tools is now a standard, swappable thing. Switch providers or add a new data source by pointing at a different MCP server.

Version stamp — as of mid-2026

The idea (a standard protocol for model↔tools/data) is durable. The dated specifics: MCP is stable and broadly adopted, the AI SDK ships a stable @ai-sdk/mcp package (v6), remote MCP servers authenticate with OAuth 2.1, and the transport moved from the old SSE style to Streamable HTTP. Hundreds of public MCP servers exist (Postgres, Slack, Google Drive, GitHub, …). Expect the transport and auth details to keep evolving; the tools/resources/prompts model is the stable core.

Agent challenges

Cost. Agents make many LLM calls. A complex task might cost $5–50.

Latency. A 10-step agent can take 1–5 minutes. Users need to see progress.

Reliability. Each step has failure modes. Errors compound.

Safety. Agents that take real actions (send emails, modify databases) need careful sandboxing.

Debugging. When an agent fails, you need traces of every step and decision.

When agents make sense

• The task is genuinely multi-step.
• Each step requires reasoning about prior results.
• Manual completion is expensive enough to justify agent cost.

When they don't:

• Single-step tasks (just call the LLM once).
• Tasks with deterministic answers (use a script).
• Latency-critical user interactions.

In 2026, agentic workflows are increasingly viable but still require careful engineering. The best are heavily scaffolded — strict tool definitions, validation at every step, clear success criteria, monitoring.

Worked example: a research agent in action

A user asks a research agent: "What's the current sentiment about our latest product launch on social media?"

The agent's actual trace:

1. Tool call: searchTwitter({ query: "Acme Launch 2026" }) → 50 tweets.
2. Tool call: searchReddit({ query: "Acme Launch 2026" }) → 12 posts.
3. Tool call: searchHackerNews({ query: "Acme Launch 2026" }) → 3 threads.
4. Reasoning step: Group by source, summarize tone.
5. Tool call: classifySentiment(...) on a sample.
6. Final answer: "Mostly positive (~70%), with criticism focused on the pricing of the Pro tier."

Total: 6 LLM calls, ~$0.15 in API costs, ~45 seconds of wall-clock time. A human doing the same task: ~45 minutes. Costs justify themselves at any scale — but you needed to measure both sides to know that.

Highlight: every agent needs a kill switch

Agents that take real-world actions (sending emails, modifying databases, spending money) can compound errors quickly. A bug that causes the agent to retry the same action 50 times can produce 50 duplicate charges, 50 wrong emails, or 50 corrupted records.

Non-negotiable guardrails:

• Hard limit on tool-call count per task (e.g., 25).
• Spending limit per task (cancel if it exceeds budget).
• Human approval for high-impact actions (sending external emails, payments, deletions).
• Full audit trace of every step for debugging.
• Easy kill switch to stop the agent mid-run.

Without these, an agent that worked in dev can cost real money in production.

Common mistakes

Where people commonly trip up

• No hard cap on the loop. An agent stuck in a "search → didn't find it → search again" cycle will happily burn 200 LLM calls before you notice. Enforce a max-step counter and a max-spend counter in the loop itself — not just a timeout — and fail loudly when either trips.
• Shipping the agent straight to prod with no traces. When the agent does something weird on step 12, you need the full sequence of prompts, tool calls, and observations to debug it. Wire Langfuse (or your tracer of choice) on day one — debugging an untraced agent is essentially guesswork.
• Letting the agent's tools touch production directly in dev. An agent prototype that can sendEmail or chargeCard against the live system will eventually do something embarrassing during a test run. Run agents against a sandbox or a dryRun: true mode until guardrails and evals are in place.
• Confusing "agentic" with "good fit." A lot of "agents" in 2026 are really a fixed 3-step pipeline dressed up in a loop. If the steps are knowable in advance, write a deterministic workflow — it's cheaper, faster, and easier to debug. Reserve real agents for tasks where the next step genuinely depends on prior results.
• No human-in-the-loop for high-impact actions. "The model is smart enough" is not a guardrail. Any external email, payment, deletion, or production write should require explicit user confirmation — implemented in regular code, not by asking the model nicely.

Page checkpoint

Checkpoint Quiz

Did agentic workflows stick?

Required

What's next

→ Continue to Pattern 5: Embeddings for Semantic Search — embeddings power more than just RAG.