Agents & GenAI Application Architecture
Bedrock Agents, tool use, and how the pieces — models, knowledge bases, guardrails — assemble into applications.
LLMs generate text — but real tasks need *actions*: look up an order, book a meeting, call an API. Agents wrap an LLM in a loop that can plan multi-step tasks, call tools/APIs, observe results, and continue until the goal is done.
Amazon Bedrock Agents
- You define the agent's instructions, available action groups (APIs/Lambda functions), and optional knowledge bases.
- The agent breaks a request into steps, calls the right actions with the right parameters, and synthesizes the final answer.
- Example: "Cancel my order and email me confirmation" → look up order → call cancel API → trigger email → confirm to user.
- Guardrails and IAM permissions constrain what the agent can see and do.
A plain LLM is a brilliant advisor behind glass — it can only talk. An agent hands that advisor a phone, a company directory, and permission to make calls on your behalf (with limits you set).
A reference GenAI architecture
- Frontend calls your backend (API Gateway + Lambda, or an app on ECS).
- Guardrails screen the user input (and later, the output).
- Knowledge Base retrieval fetches relevant company context (RAG).
- Bedrock model (or Agent, if actions are needed) generates the response.
- Observability: prompts, outputs, and API calls logged via CloudWatch and CloudTrail.
Keyword map: "multi-step task / call APIs / take actions" → Bedrock Agents. "answer from documents" → Knowledge Bases (RAG). "block harmful topics or PII in prompts/responses" → Bedrock Guardrails.
A travel app needs its AI assistant to check flight availability via an API, book the flight, and email an itinerary — all from one user request. Which Bedrock capability enables this?