Agentic development explained: the loop behind AI coding agents

Agentic development is building software with AI that doesn't answer once and stop — it runs a loop. An agent takes a goal, gathers context, takes an action through a tool, observes what happened, and repeats until the work is done or it hits a limit. That loop — plus the tools, skills and plugins wrapped around the model — is what separates an agent from a chatbot.

The model is the smallest part of the story. What makes an agent useful is the harness around it: what it can see, what it can do, and how tightly its actions are governed. This is a practical tour of that harness — the agent loop itself, and the building blocks (tools, MCP, subagents, skills, plugins and hooks) that turn a language model into something that ships work.

From a single call to a loop

A plain language-model call is stateless: prompt in, response out, done. It can't run your tests, read the next file, or react to what it finds. An agent closes that gap with iteration. Most agent loops follow the ReAct pattern — reason, act, observe — where each action returns real feedback that informs the next decision. Instead of guessing the whole answer up front, the agent works the problem the way a person would: try something, look at the result, adjust.

Anatomy of the loop

Concretely, one trip around the loop — a “turn” — looks like this. The model receives the goal along with its system prompt, the available tool definitions and the conversation so far. It decides how to proceed: reply with text, call one or more tools, or both. The harness runs those tools, feeds the results back, and the model evaluates again. Turns continue until the model responds with no tool calls — that's the signal the task is finished.

Two things keep this from running forever. The first is the natural stop: no more tool calls. The second is a budget — a cap on turns or spend — so an open-ended prompt like “improve this codebase” can't loop indefinitely. Setting a budget is much of the difference between a demo and a production agent.

What turns a model into an agent

A model on its own can only produce text. Everything else is the harness — and it's where most of the engineering actually lives.

Tools

Tools are the agent's hands: read and write files, run commands, search code, query an API, fetch a page. Without them an agent can describe a fix; with them it can apply one and check that it worked. Good tool design — clear names, tight scopes, read-only where possible — does more for reliability than a bigger model.

MCP — connecting to the outside world

The Model Context Protocol (MCP) is an open standard for connecting agents to external systems: databases, APIs and content platforms. Rather than hard-coding an integration, you point the agent at an MCP server and it discovers the available tools. We use it daily — the Sanity MCP lets an agent read and write our content directly, with full schema awareness, instead of us hand-feeding it context.

Subagents

A subagent is a separate agent the lead spawns for a focused subtask. It starts with a clean context, does its job, and returns only a summary — so the main agent's context stays lean while several subagents work in parallel. This is how you scale to work no single context window could hold.

Skills

Skills are packaged, reusable instructions an agent loads on demand. Only short descriptions sit in context by default; the full content loads when a skill is actually invoked. A skill captures “how we do X here” — a workflow, a house style, a set of guardrails — once, so every run follows it instead of improvising.

Plugins

Plugins are the distribution layer: a bundle that ships skills, subagents, MCP servers and hooks together. They're how a team packages its agent capabilities and shares them across projects, so a new repository inherits the same tools and conventions on day one.

Hooks

Hooks are deterministic callbacks that fire at fixed points in the loop — before a tool runs, after it returns, when the agent finishes. They run as ordinary code, not model output, which makes them the right place for hard rules: validate inputs, block a dangerous command, or stop a write to the wrong environment. They are the seatbelt for an autonomous loop.

Context is the budget

Everything the agent has seen — the system prompt, tool definitions, every file read and every command output — accumulates in one context window, and it doesn't reset between turns. Long sessions get expensive and lossy. Mature agent systems manage this deliberately: they compact older history into summaries, push subtasks to subagents with fresh context, and keep persistent rules in a project file that's re-injected every turn rather than buried in a first prompt that may be summarised away.

Why this matters for product teams

Agentic development is quietly changing both how software gets built and what software can do. As a practice, it's how a small team moves faster: agents handle the mechanical eighty per cent — scaffolding, migrations, tests — under human review. As a product capability, the same loop powers features your users touch: assistants that take actions, not just answer questions. Our AI development and integration work is mostly this — wiring the loop, the tools and the guardrails into real product engineering, on stacks like Claude and the AI SDK.

It also reframes the build-versus-ship question. AI can carry a prototype a long way, but taking an AI-built prototype to production still needs the unglamorous engineering — and the same is true of agents: the loop is easy to demo and hard to make safe.

Where it goes wrong — and how to keep it safe

The failure modes are predictable, which means they're avoidable:

1. Runaway loops. Without a turn or budget cap, an open-ended task can spiral. Set limits.
2. Unverified actions. An agent that edits but never checks its work ships bugs confidently. Make verification a step in the loop, not an afterthought.
3. Over-broad permissions. Give an agent only the tools and scopes it needs; gate the dangerous ones behind hooks and approvals.
4. Prompt injection. Tool results — web pages, files, tickets — are data, not instructions. An agent must never execute commands it finds in the content it reads.

The lesson of agentic development is counter-intuitive: the model matters less than the loop around it. The teams getting real value aren't the ones with the cleverest prompts — they're the ones who designed the loop carefully, gave the agent the right tools, and wrapped it in guardrails strong enough to trust. Build the loop well, and the model takes care of the rest.