What Is an AI Agent? A Builder's View on AWS
A builder's introduction to AI agents on AWS. Learn the agent loop, how agents differ from workflows, how each part maps to Amazon Bedrock and AgentCore services, and the risks to plan for before you build.
Series: Amazon Bedrock (13 articles)
- …
- 8What Is an AI Agent? A Builder's View on AWS This article
An agent is more than a chatbot with a longer prompt. Here's what it really is, how it differs from a workflow, and which AWS pieces map to each part.
"Agent" is one of the most overused words in AI right now. Depending on who's talking, it can mean a chatbot, a script that calls a model, or a system that books your travel while you sleep. That makes it hard to know what you're signing up for when you decide to build one.
This article gives you a working definition, a simple mental model, and a map from each part of an agent to the AWS services you'd use. It's the first in a short series on building agents, so we'll keep it conceptual and practical, with no heavy setup.
[Add a sentence or two here about why you're interested in agents, or a task you'd like one to handle.]
A working definition
Here's the definition I'll use: an agent is a system where a model decides what to do next, uses tools to do it, looks at the result, and repeats until the job is done.
The important part is the model decides. In a plain model call, you send a prompt and get text back. In an agent, the model can choose to look something up, call an API, run some code or ask a follow-up question, then use what it learns to choose its next step.
The agent loop
Almost every agent, whatever framework it's built with, runs the same basic loop:
- Goal. It gets a task, such as "find out why this customer was charged twice and draft a reply."
- Think. The model decides what it needs to do first.
- Act. It calls a tool: look up the order, check the payment record.
- Observe. It reads what came back.
- Repeat or finish. If it needs more, it goes around again. If it has enough, it gives the final answer.
Here's that loop in simplified pseudo-Python. It isn't a real AWS call, just the shape of the idea:
Python
def run_agent(goal, tools, max_steps=8):history = [goal]for step in range(max_steps):decision = model_decide(history, tools) # the model picks a tool or an answerif decision.is_final_answer:return decision.textresult = tools[decision.tool_name](**decision.arguments)history.append(result) # the model sees what happenedreturn "Stopped: too many steps."
Notice the
max_steps limit. Loops need guardrails, and we'll come back to why.The parts of an agent
It helps to break an agent into five parts:
- A model that reasons and decides.
- Instructions that set its role, rules and boundaries.
- Tools it can call: APIs, databases, search, code execution.
- Memory so it can keep track of the conversation, and sometimes remember things across sessions.
- Limits and oversight: permissions, guardrails, step limits and logging.
If an "agent" is missing tools and a loop, it's really just a model call with a nice name.
Agent or workflow?
This is the question that saves the most time and money. In the Flows article we built a workflow: a fixed path where we decided the steps in advance. An agent is different, because the model chooses the path as it goes.
| Workflow | Agent |
|---|---|---|
Who picks the steps? | You, in advance | The model, as it goes |
Predictability | High | Lower |
Cost and speed | Easier to estimate | Varies with how many steps it takes |
Best for | Known, repeatable processes | Open-ended tasks where the steps depend on what turns up |
Easier to test? | Yes | Harder |
My rule of thumb: if you can draw the steps on a whiteboard in advance, use a workflow. Use an agent when the path really can't be known ahead of time. Many successful systems are workflows with one small agentic step inside.
How it maps to AWS
Amazon Bedrock AgentCore describes itself as a platform for building, deploying and operating agents securely at scale, using any framework and foundation model. It's made of modular services you can use together or on their own. Here's how the parts of an agent line up:
Part of an agent | AWS option | What it does |
|---|---|---|
The model | Amazon Bedrock | Hosts the foundation models that do the reasoning |
The agent code and hosting | AgentCore Runtime | Runs your agent in a managed, serverless environment with isolated sessions |
Tools | AgentCore Gateway, AWS Lambda | Connects the agent to APIs and functions it can call |
Memory | AgentCore Memory | Keeps short-term context for a session and, optionally, longer-term memory |
Who the agent acts as | AgentCore Identity | Handles authentication and access for the agent |
Seeing what it did | AgentCore Observability, CloudWatch | Traces, logs and metrics for each run |
Built-in abilities | AgentCore Code Interpreter and Browser | Run code or browse the web in a managed sandbox |
Safety limits | Bedrock Guardrails, IAM | Filter inputs and outputs, and restrict what the agent is allowed to do |
You don't have to use all of it. Many first agents use only the model, a framework such as Strands Agents or LangGraph, and a couple of Lambda functions as tools. The AgentCore services matter more once you need to run agents in production, with real users, memory and security.
The list of AgentCore capabilities has been growing, so check the current documentation for what's available in your Region and what it costs.
What can go wrong
Agents are powerful because they act on their own, and that's also why they need more care than a single model call.
- Runaway loops. An agent can keep calling tools without making progress. Always set a step limit and a time limit.
- Costs that vary. Each step is another model call, so a task that takes ten steps costs ten times as much as one that takes one.
- Wrong tool, wrong input. The model can pick the wrong tool or give it bad arguments. Validate what tools receive.
- Too much power. An agent with broad permissions can do broad damage. Give it only the access the task needs.
- Hard to predict. The same request can take different paths. Log every step so you can see what happened afterwards.
- Prompt attacks. Text the agent reads, such as a web page or an email, can contain instructions meant to hijack it. Treat outside content as untrusted.
The tools-and-permissions point is the most important. If your agent can send email, delete files or spend money, decide up front which of those actions need a person to approve.
When not to build an agent
Skip the agent if a simple prompt does the job, if a fixed workflow would be more reliable, or if a mistake would be costly and you can't put a person in the loop. Agents are impressive in demos, but boring, predictable systems are often what the business actually needs.
A starter checklist
- Describe the task in one sentence. Could a workflow do it?
- List the tools it would need, and the minimum permission for each.
- Decide the step limit, time limit and budget.
- Decide which actions need human approval.
- Plan how you'll see what it did: logs and traces.
- Write ten test tasks, including a few it should refuse.
Where we go next
In the next article we'll build a first agent with Amazon Bedrock AgentCore: a minimal agent that runs locally and then gets deployed, with a tool and a safe set of permissions.
AgentCore services, features, Regions and pricing change often. Check the current Amazon Bedrock AgentCore documentation before you follow any step here.
Series: Amazon Bedrock (13 articles)
- …
- 8What Is an AI Agent? A Builder's View on AWS This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article