Agent anatomy: loops, tools, and frameworks
Lesson 1 of 4 in Agentic Systems on AWS.
Strip the hype and an agent is a loop: a foundation model receives a goal and a catalog of tools, reasons about what to do, and either answers or asks for a tool call. Something outside the model — the framework — executes that call, feeds the observation back into the context window, and the loop runs again until the model decides it is done. The model never executes anything itself; it only requests. Everything the exam asks about agents hangs off that one fact: the loop is where reasoning lives, the tools are where capability lives, and the framework is where control lives.
On AWS the named framework is Strands Agents — the open-source SDK the AIP-C01 guide calls out for building "intelligent autonomous systems". Strands is model-driven: instead of hand-coding a flowchart of steps, you give the agent a model, a system prompt, and tools, and in each pass of the loop the SDK hands the model the conversation plus tool descriptions and lets it plan, reflect, and select tools natively. Strands executes whatever the model selects and returns the result into the next pass.
One pass of the agent loop
- Goal + tool catalog
The user request, the system prompt, conversation state, and a description of every tool the agent may call — all assembled into model context by the framework.
- Model reasons
The FM plans and reflects — chain-of-thought happens here. In Strands this is native to each loop pass; in a Step Functions ReAct build it is an explicit state.
- Answer or act?
- Framework executes tool
The model emits a structured tool request; the framework (not the model) runs it — often a Lambda function that validates parameters and handles errors before touching anything real.
- Observation returns
The tool result rides back into the context window as an observation. The next loop pass sees it and re-plans.
- Final answer
The model stops requesting tools and responds. Production loops also stop on iteration caps, timeouts, and cost budgets — the safety-rails lesson covers those.
Tools are the agent's hands, and the guide's phrase for them is precise: standardized function definitions. A tool is a name, typed parameters, and a description — and the description is not documentation, it is prompt material: the model reads it to decide when and how to call the tool. In Strands you register custom behaviors through the Strands API (in Python, a decorated function becomes a tool; its docstring becomes the model-facing description). The execution side belongs to ordinary engineering: a Lambda function per tool that validates parameters, enforces types and ranges, and converts failures into structured error observations the model can recover from — a bad tool call should come back as "error: date out of range", not as a stack trace or a silent timeout.
Key terms: Strands Agents, ReAct (reason + act), MCP, Bedrock AgentCore
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.