What Is an AI Agent? A Field Definition and Five Common Patterns

Everyone is building “agents” now. But ask five engineers what an agent actually is and you’ll get six answers.

I’ve spent the last year working on agentic systems — from industrial diagnostic agents to workflow orchestrators — and I keep seeing the same confusion between “chatbot with a system prompt” and “autonomous system that reasons and acts.” These are fundamentally different things.

Here’s the mental model I use, the building blocks that matter, and the five architectural patterns I see most often in production.

What’s Their Purpose?

An agent has four internal components that drive its behavior:

• Goals — What it’s trying to achieve
• Plan Library — The strategies it can draw from
• Beliefs — Its current understanding of the world
• Intentions — What it has committed to doing next

These components interact through a Reasoning core that sits in the center. The agent perceives its environment, reasons over its goals and beliefs, and produces actions.

This isn’t new. This is the BDI (Belief-Desire-Intention) model from the 1980s. What’s new is that we now have LLMs powerful enough to implement the reasoning core without hand-coding every decision path.

Building Blocks of an Agent

Every agent — traditional or GenAI-powered — has three layers:

Perception

How the agent takes in information: text, audio, sensor data, API responses, file contents.

Cognitive

Where reasoning happens. In a traditional AI agent, this includes:

• Memory (short-term and long-term)
• Knowledge base
• Decision making
• Goals and plans

In a GenAI agent, the cognitive layer simplifies dramatically:

• Goals are fed as prompt context
• Plans are generated via chain-of-thought reasoning — the model creates and refines sub-plans dynamically
• Memory is either in-context or stored externally (vector stores, session state)

The LLM replaces the hand-coded decision tree.

Action

What the agent does in the world: calling APIs, executing code, sending messages, invoking tools (search, calculate, execute).

Five Common Agent Patterns

Here are the patterns I see most often in production systems. Each adds a layer of capability.

1. Basic Reasoning Agent

The simplest pattern. A single loop:

1. User sends a query
2. Agent constructs a prompt and sends it to the LLM
3. LLM generates a response
4. Agent returns the response

This is essentially a chatbot with a good system prompt. No tools, no external data. Useful for Q&A over static knowledge baked into the model.

2. Agentic RAG

Adds retrieval to the reasoning loop:

1. User sends a query
2. Agent searches a knowledge source (vector DB, full-text index)
3. Relevant information is retrieved for enhanced context
4. Agent sends prompt + enhanced context to the LLM
5. LLM generates a response grounded in the retrieved data

This is the pattern behind most enterprise “chat with your documents” systems. The agent decides what to search for and how to incorporate the results.

3. Tool-Based Agent

The most common pattern for production agents. The LLM doesn’t just generate text — it decides which tools to invoke:

1. User sends a query
2. Agent searches available tools in its registry
3. LLM receives query + tool descriptions and selects a tool
4. Agent executes the tool and receives the result
5. Agent returns the final response (possibly after multiple tool calls)

Tools can be anything: API calls, database queries, calculations, code execution. The key insight: the LLM is making a decision about what action to take, not just generating text.

4. Coding Agent

A specialized tool-based agent designed for software development:

1. User sends a query through an IDE
2. Agent collects environment context (files, project structure, diagnostics)
3. A reasoning LLM processes the query + context and produces a plan
4. An action LLM translates the plan into concrete IDE operations (edits, terminal commands)

The two-LLM architecture (one for planning, one for execution) is common here because reasoning and code generation benefit from different prompting strategies.

5. Voice Agent

Adds real-time audio processing:

1. User speaks — speech-to-text converts to text
2. Streaming context from telephony or audio pipeline
3. LLM processes query + stream context and generates a response
4. Text-to-speech converts the response back to audio

The challenge here is latency. Every extra millisecond in the pipeline makes the conversation feel unnatural. This is why voice agents often use smaller, faster models.

6. Workflow Agent (Multi-Agent)

The most complex pattern — an orchestrator that delegates to specialized worker agents:

1. User triggers the system via UI, API, or event
2. A system receives the request and forwards it to the orchestrator agent
3. The orchestrator searches worker agent context to understand available capabilities
4. The LLM performs agent selection — choosing which worker agent to invoke
5. The selected worker agent executes its specialized task

This is where you get multi-agent systems. Each worker agent is itself a full agent (possibly with tools, RAG, or its own sub-agents). The orchestrator’s job is routing and coordination.

From Patterns to Platform

These patterns aren’t mutually exclusive. Production agents often combine several:

• A workflow agent orchestrating multiple tool-based agents
• Each tool-based agent using RAG for its domain knowledge
• The whole system fronted by a voice agent for phone interactions

This is exactly the problem that platforms like Amazon Bedrock AgentCore solve — providing the infrastructure (runtime, identity, memory, observability, gateway) so you can focus on the agent logic rather than reinventing session management, tool execution, and security boundaries for every project.

Key Takeaways

• An agent is not a chatbot — it perceives, reasons, and acts
• The BDI model (Beliefs, Desires, Intentions) is 40 years old — LLMs just made it practical
• GenAI agents replace hand-coded decision trees with chain-of-thought reasoning
• Start with the simplest pattern that solves your problem (basic reasoning or RAG)
• Add tools when the agent needs to do things, not just say things
• Multi-agent architectures are for when no single agent can handle the full scope
• The hard part isn’t the LLM — it’s the infrastructure: identity, memory, observability, and security

Any opinions in this article are my own.