AgentX: 26 AI Agent Patterns

I think about tool use as the moment a language model stops being a text generator and starts being something you can actually give work to. The model outputs structured JSON. Your code reads that JSON and does something real: calls an API, writes a file, queries a database. That is the whole trick. MCP, computer use, all of it sits on top of this one primitive. If you understand this, you understand why agents can do things at all.

ReAct is the loop that most agents are actually running, even when the framework does not call it that. The model reasons about what to do, calls a tool, reads the result, then reasons again. That cycle repeats until the task is done or something breaks. Once I understood this I stopped debugging agent failures as mysteries and started treating them as broken steps in a sequence. That shift matters a lot.

An agent without a plan is just pattern-matching its way forward, one tool call at a time. Planning means breaking a complex goal into an ordered set of subtasks, working out what depends on what, and building that structure before anything actually runs. The plan does not need to be perfect. It needs to exist. Agents that skip this fail quietly on tasks with three or more moving parts, and the failure is hard to diagnose because no single step looks wrong.

Reflection is the agent stopping to look at what it just produced before moving forward. Did the code actually compile? Does the answer address what was asked, or a slightly different question the model found easier? Self-correction loops catch a real percentage of errors before they reach anyone. The tradeoff is extra latency and cost, which is a real engineering decision you have to make deliberately rather than defaulting to either extreme.

Before MCP, every agent application built its own integrations. You wanted your tool to work in Claude Code and also Cursor? Write it twice. MCP is the standard that changed that: one server, any compatible client. It is now under the Linux Foundation, which means it is no longer Anthropic's spec to change unilaterally. The ecosystem is real: 5,800+ community servers and 97 million monthly SDK downloads.

Most software in the world does not have an API. Computer use is the pattern that solves that. The model takes a screenshot, figures out what it is looking at, then outputs clicks and keystrokes like a human would. Anthropic launched it in October 2024. OpenAI followed in January 2025. It is slower and less reliable than API-based tool use, but for legacy systems and anything behind a GUI it is often the only option you have.

A skill is a reusable bundle of instructions, tools, and domain knowledge that an agent loads at runtime based on what it is being asked to do. Instead of one giant system prompt that tries to cover every situation, you compose focused capability modules. The SKILL.md convention gives each skill a discoverable interface that lives in the filesystem alongside your code. Versioned, reviewable, shareable.

AGENTS.md is a Markdown file you put at the root of a repository to tell AI coding agents how to behave in your project. What it is, how it is structured, what the agent should and should not touch. OpenAI adopted it for Codex, Anthropic uses it as CLAUDE.md for Claude Code, Google adopted it for Gemini CLI. Over 60,000 repos have one. The Linux Foundation now maintains the spec.

Some tasks are too large to fit cleanly in one agent pass. Multi-agent orchestration splits the work: a planner that breaks down the goal, a researcher that gathers information, a coder that implements, a reviewer that checks the output. Each agent has its own narrow scope, tools, and instructions. The orchestrator coordinates them. The complexity is in the coordination layer, not in any individual agent.

Not every request deserves the same model or the same agent. Routing classifies incoming requests and sends each one to the right handler. Simple queries go to a fast cheap model. Complex ones go to the expensive powerful one. Domain-specific requests go to the specialized agent. The goal is matching cost and capability to actual difficulty, rather than treating every request identically.

An autonomous loop wraps an agent in a persistent execution cycle. Give it a task list and exit conditions, then let it run for hours without waiting for human input at every step. Claude Code has /loop, Devin has long-running tasks, Cursor has Cloud Agents. The concept is the same across all of them. You need three things to do this safely in production: circuit breakers, rate limiting, and sandboxed execution. Without those, it is not a feature.

By default, agents start each session with no idea what happened last time. Memory patterns are how you fix that. They give the agent a way to store and retrieve past interactions, learned preferences, and accumulated facts. The tricky part is not storing things. It is deciding what to keep, what to discard, and whether you can actually retrieve the right thing when you need it.

Context windows are finite and agentic tasks burn through them fast. Every tool result, every retrieved document, every piece of intermediate reasoning takes up space. Context management is the practice of deciding what the agent actually needs to see right now, and getting rid of everything else. It sounds simple. In a multi-step agent running dozens of tool calls, it is one of the most consequential decisions you will make.

Agents do not just talk. They call functions, fill schemas, and return JSON that other systems consume. Structured output is the pattern of making that reliable. When the model returns malformed JSON, everything downstream breaks. The two main approaches are constrained decoding, which makes invalid output impossible at the token level, and validation with retry, which catches failures and tries again with the error attached.

The more autonomy you give an agent, the more damage it can do when something goes wrong. Guardrails are the controls that prevent that. They validate inputs and outputs, enforce cost limits, scope what the agent is allowed to touch, and detect prompt injection from untrusted content in the environment. The failure modes they address are varied and some of them are genuinely nasty.

If an agent can write and execute code on your machine, it can do essentially anything your machine can do. Sandboxes solve this by giving the agent a fully isolated environment: its own filesystem, its own network, its own process space. It can run arbitrary code, browse the web, modify files, and crash itself repeatedly. Your production systems stay untouched. The MicroVM spins up in 150 milliseconds and disappears when the task finishes.

A harness is the scaffolding that sits between a raw model call and a working agent in production. It handles the tool-call loop, retry logic, timeout handling, state checkpointing, and crash recovery. Without it, a 2% per-call failure rate compounds across 50 calls into something that fails constantly. With it, you have a system that can survive network errors, resume interrupted runs, and actually be trusted in production.

Most agent UIs pre-build every possible component and then try to figure out which one to show. Generative UI flips that. The model decides what to render based on what the data actually calls for. A table, a form, a chart, a custom component. The AG-UI protocol from CopilotKit gives this a concrete event-stream model you can actually build on top of.

Cursor, Windsurf, Copilot, Cline, and Zed all have agents that live inside the editor with access to your open files, language server data, git history, and terminal output. They already know your project. The range runs from tab completion all the way to autonomous agent mode. This is where most developers get their first real exposure to agents doing actual work.

Claude Code, Aider, OpenCode, Gemini CLI, and Goose live in the terminal and work directly with the shell, filesystem, and dev tools. No GUI. No browser tab. They compose with pipes and scripts and can run headlessly in CI without any modification. This is where the power-user workflow lives, and also where automation starts.

ChatGPT, Claude.ai, Gemini, and DeepSeek are where most people first encounter what agents can do. The format looks simple because the interface is simple. The engineering underneath is not: streaming responses, progressive rendering, multi-turn context management, rich output formats. Chat is the lowest-friction entry point and also the most constrained one.

Multiple agents working on a shared project is powerful and, without a workspace, almost impossible to follow. Multi-agent workspaces give each agent persistent identity, shared state, and a visible interface so the human in the loop can actually see what is happening. VS Code called itself a multi-agent platform in January 2026. That framing was not accidental.

Agents running in CI pipelines, cron jobs, and background processes with no human watching. Code review bots, automated refactoring, dependency updates, test generation. They run on every PR, every commit, around the clock. This is where agents stop being tools and start being infrastructure, and the operational requirements change to match.

I have run agents that behaved perfectly in staging and did something alarming in production. Human-in-the-loop patterns are checkpoints where the agent stops and waits, rather than deciding unilaterally. The question is not whether to have checkpoints, it is where to put them. That depends on how reversible the action is, and how much you have actually tested the agent, not how confident you feel about it.

An agent ran 14 steps, returned the wrong answer, and I had no idea where it went wrong. That is the problem observability solves. Traces capture every tool call, reasoning step, and decision point so you can replay exactly what happened. Without that, debugging is just reading the final output and guessing at the middle.

I upgraded a model once and a capability I relied on quietly got worse. I did not find out for a week. Evals are what prevent that. Agent evals are harder than benchmark accuracy because you need to test tool selection, step ordering, failure recovery, and end-to-end outcomes across multi-step tasks. A simple right or wrong score does not capture any of that.