The Anatomy of an Agent
Six parts make up every agent — model, instructions, tools, knowledge, memory and guardrails — and knowing which part a requirement belongs to is half the exam.
Whatever framework you use, an agent is assembled from the same six components. Most production problems are a component confusion: someone put knowledge in the prompt, or policy in the instructions, or state in the context window.
1. Model
The reasoning engine that plans and chooses tools. Agentic work is harder than single-shot generation, so a model that is fine for summarising can be poor at multi-step tool selection. Choose on tool-calling accuracy and instruction adherence first, then on cost. Keep temperature low for orchestration.
2. Instructions
The system prompt: role, scope, tone, and the rules for choosing tools. Good instructions are specific about boundaries ("never quote a price you have not retrieved") and about when to give up and hand off. Instructions shape behaviour but do not enforce it — anything that must hold even under adversarial input belongs in guardrails or IAM.
3. Tools
The verbs. Functions with a name, a description and a JSON Schema for their inputs, backed by Lambda functions, APIs, databases, or Model Context Protocol servers. In Amazon Bedrock Agents these are action groups, defined either with an OpenAPI schema or a simpler function schema. The description is not documentation, it is the selection signal — the model picks tools by reading it, so vague descriptions cause wrong calls more often than weak models do.
4. Knowledge
The nouns: facts the agent can look up but must not invent. On AWS this is typically a Bedrock knowledge base over a vector store, associated with the agent so retrieval happens as part of orchestration. Tool versus knowledge base is a favourite distinction: a knowledge base answers "what is true?" from documents; a tool answers "what is the current state?" or performs an action. Refund policy goes in a knowledge base; the customer's actual balance comes from a tool.
5. Memory
State that survives beyond the current context window. Short-term memory is the running conversation, held in a session. Long-term memory is what persists across sessions: summaries of previous conversations, user preferences, extracted facts. Bedrock Agents can retain session summaries across sessions when memory is enabled, and Amazon Bedrock AgentCore Memory provides both short-term and long-term memory as a managed service for agents built with any framework. The exam distinction to hold: context is what you send on this call; memory is the store you retrieve from to build that context.
6. Guardrails
The enforcement layer that does not trust the model. Amazon Bedrock Guardrails apply content filters, denied topics, word filters, sensitive-information filters for PII, and contextual grounding checks to block ungrounded or irrelevant responses. A guardrail can be attached to an agent, and the ApplyGuardrail API lets you evaluate arbitrary text independently. Alongside these sit the non-model controls: a least-privilege execution role, input validation in the tool executor, and rate and spend limits.
Assemble deliberately. When an agent misbehaves, diagnose by component: wrong tool chosen is instructions or tool descriptions; wrong facts is knowledge; forgot the user is memory; said something it should not is guardrails.
Example
import boto3
ctrl = boto3.client("bedrock-agent")
agent = ctrl.create_agent(
agentName="billing-support",
agentResourceRoleArn="arn:aws:iam::111122223333:role/AmazonBedrockExecutionRoleForAgents_billing",
foundationModel="anthropic.claude-3-5-sonnet-20240620-v1:0", # 1. model
instruction=( # 2. instructions
"You are a UK billing support agent. Look up real data before answering. "
"Never quote a figure you have not retrieved. Escalate anything over 100 GBP."
),
guardrailConfiguration={ # 6. guardrails
"guardrailIdentifier": "gr-abc123",
"guardrailVersion": "3",
},
memoryConfiguration={ # 5. memory
"enabledMemoryTypes": ["SESSION_SUMMARY"],
"storageDays": 30,
},
idleSessionTTLInSeconds=900,
)["agent"]
ctrl.create_agent_action_group( # 3. tools
agentId=agent["agentId"],
agentVersion="DRAFT",
actionGroupName="billing-actions",
actionGroupExecutor={"lambda": "arn:aws:lambda:eu-west-2:111122223333:function:billing-tools"},
apiSchema={"s3": {"s3BucketName": "my-schemas", "s3ObjectKey": "billing-openapi.json"}},
)
ctrl.associate_agent_knowledge_base( # 4. knowledge
agentId=agent["agentId"],
agentVersion="DRAFT",
knowledgeBaseId="KB1234567",
description="Refund and billing policy documents. Search this for policy questions.",
)
ctrl.prepare_agent(agentId=agent["agentId"]) # required before the changes take effectWhen to use it
- A billing agent retrieves refund policy from a knowledge base but always fetches the live balance through a tool, so it can never quote a stale figure.
- A travel assistant stores seat and meal preferences in long-term memory so a returning customer does not have to repeat them.
- A public-facing agent uses a guardrail with contextual grounding checks to block answers that are not supported by the retrieved documents.
Discussion