Most things called "agents" right now are not agents. They're a model call, maybe two, wrapped in a while loop and branded with a good demo. I've built enough of them, in healthcare AI, in golf AI, in enterprise ops tooling, to know the difference between a system that actually reasons and acts autonomously and one that's just an API with extra steps.

The distinction matters because they fail differently, require different design decisions, and solve different problems. If you're building the wrong thing for your problem, you'll hit a wall and blame the model when the real issue was architecture.

The Precise Definition

The cleanest framing I've found: an AI agent is an autonomous system that uses a foundation model as its reasoning engine. The key word is autonomous. The system perceives a state, decides what to do, takes action, observes the result, and iterates. It doesn't just answer a question and hand the output back to you.

What that looks like in practice: the agent has a goal, a set of tools it can invoke, and a planning loop that runs until the goal is satisfied or it determines the goal is unreachable. It decides when to call which tool, what to pass it, and how to interpret the result, all without you specifying the sequence ahead of time.

A chatbot that calls a function to look up a customer record is not an agent. It's a function-calling interface. An agent would look up the record, notice something anomalous, decide to cross-reference another system, form a hypothesis about the anomaly, and surface a finding with reasoning attached, without being told to do any of those intermediate steps.

What Actually Determines Agent Capability

There are two levers: tool availability and planning strategy. Most people obsess about the model and ignore both.

Tool Design Is the Dominant Variable

Your agent can only do what its tools let it do. This sounds obvious. It isn't, because people design tools too narrowly.

The failure mode I've seen most often: an agent with a "search" tool that takes a query string and returns a flat list of results. That works for simple lookups. It breaks down when the agent needs to explore: to understand what else is in the space beyond the top five results, to filter by facets, to know when it's hit the edge of what's available. A better tool returns structured results metadata about the result space. Counts, categories, a signal about coverage. It gives the agent peripheral vision.

Related Articles

Your Support Team Is Claude Code on a Timer

An L2 support engineer that's just Claude Code on a /loop, with all its state living in Slack reactions. No app, no database, no deploy — and it only pings you when it's real.

What an AI Audit Actually Finds

Most teams asking for AI don't have a model problem. They have a "which problem is even worth it" problem. Here's what a real AI audit surfaces — and why "don't build this" is often the most valuable line in the report.

Inside a Production Voice Agent: How the Stack Actually Ships

Production voice-AI has converged on a pattern: graph-based conversations, separated decision and response prompts, synthetic-call regression testing, and per-component latency budgets. Why the stack looks the way it does — and what most teams are still missing.