Agentic AI & Generative AI

TL;DR

• An agent is a system that reasons and takes action via tools — unlike a read-only chatbot, it can modify data, trigger workflows, or send communications, so it needs the same design rigor as any other system that can change production state.
• Core controls: least-privilege tool scoping, human-in-the-loop approval on high-impact/irreversible actions, guardrails on both input and output, and full orchestration-trace logging.
• Bedrock Agents = orchestration loop; Bedrock Guardrails = content/action filtering; Knowledge Bases = managed RAG; MCP = standardized tool connectivity.
• Biggest gotcha: an unscoped tool surface turns a single bad reasoning step (or a successful prompt injection) into an outsized, hard-to-contain blast radius — the agentic-AI equivalent of an AdministratorAccess role “for convenience.”
• AI governance is an organizational practice (approval workflows, audit review, default-deny tool access), not just “we turned on Guardrails.”

Core Concepts

Bedrock Agents — orchestration mechanism

Bedrock Agents run the loop of reasoning → tool call → incorporate result → continue reasoning. This loop is the mechanism that turns a foundation model from “answers questions” into “completes multi-step tasks using external capabilities.” The architecture decision with the highest leverage is not which agent framework is used — it’s how tightly the agent’s tool set is scoped.

An agent decides which tool to call and with what parameters based on model reasoning. That reasoning can be manipulated via prompt injection, or it can simply be wrong (hallucinated plan, misread instruction). A narrowly scoped tool set bounds the blast radius of either failure mode, functioning exactly like least-privilege IAM bounds the blast radius of a compromised credential. A broad, unscoped tool surface granted “for flexibility” carries the same risk profile as a role granted AdministratorAccess “for convenience.”

Bedrock Guardrails — applied to agents

Guardrails (content filtering, denied topics, PII redaction, grounding checks) apply to agentic systems with higher stakes than to a plain chatbot: weak or absent guardrails on an agent don’t just risk bad text output, they risk a bad action actually executing. Guardrails must be applied to both the agent’s reasoning inputs and its tool-call outputs — filtering only the final chat-facing text misses the intermediate step where a tool actually gets invoked.

MCP (Model Context Protocol) — standardized tool connectivity

Without a common protocol for how a model/agent connects to external tools and data sources, every integration is a one-off, non-portable, point-to-point connection that must be rebuilt per agent framework. MCP standardizes that connection: a tool or data source implementing MCP can be reused across different agent implementations, the same way a well-designed REST API serves many client applications instead of being hand-built per consumer.

RAG and Knowledge Bases

RAG (Retrieval-Augmented Generation) is the pattern: retrieve relevant context from an external store and inject it into the model’s prompt to ground generation in real data. Knowledge Bases is Bedrock’s managed implementation of that pattern — it handles ingestion, chunking, embedding generation, and vector store integration, removing the need to build and operate that pipeline manually. Default to Knowledge Bases for grounded agents/assistants; reach for a fully custom RAG pipeline only when there’s a specific, concrete gap Knowledge Bases doesn’t cover.

Agent orchestration traces

Orchestration traces log every step of an agent’s reasoning, tool calls, and intermediate decisions. This is the agentic equivalent of CloudTrail for IAM actions: without a trace, an agent’s surprising action is nearly impossible to root-cause after the fact. Trace logging should be a non-negotiable prerequisite before any agent with real tool access reaches production — not something bolted on reactively after the first incident.

AI governance

Governance is the organizational layer tying the above together: who approves which agents get deployed, what tool access is granted by default versus requiring explicit sign-off, and how incidents involving agent behavior get reviewed and fed back into tightening controls. “We added Guardrails” is not governance-complete — the human-approval and audit-trail layers are the parts that actually matter once an agent is taking real actions in production.

Common Pitfalls

• Pitfall: Agents given broad, unscoped tool access “for flexibility.” Why: a single bad reasoning step (or successful prompt injection) then has an outsized, hard-to-contain blast radius. Fix: scope tools to the minimum required for the agent’s actual task, same discipline as IAM least privilege.
• Pitfall: High-impact actions (deletions, financial transactions, external communications) executed autonomously with no approval gate. Why: the failure is only discovered after it has already happened. Fix: require human-in-the-loop approval for any high-impact, hard-to-reverse action; reserve autonomous execution for low-risk, easily-reversible actions.
• Pitfall: No orchestration trace logging. Why: makes post-incident investigation into “why did the agent do that” effectively impossible. Fix: log every reasoning step, tool call, and decision before the agent reaches production with real tool access.
• Pitfall: Custom-built RAG pipelines that reinvent what Knowledge Bases already provides. Why: absorbs unnecessary infrastructure build and maintenance cost. Fix: default to Knowledge Bases; build custom only for a concrete, identified gap.
• Pitfall: Treating “Guardrails are configured” as governance-complete. Why: misses the human-approval and audit-trail layers that actually govern agent behavior in production. Fix: define an explicit governance practice covering deployment approval, default tool-access policy, and incident review feedback loops.

Interview Questions

• “Design an agent that can process customer refund requests, including deciding when a refund should actually be issued.” — tests whether human-in-the-loop approval is built into the money-moving action, not left autonomous.
• “An agent took an unexpected, harmful action in production. Walk through the incident investigation.” — tests whether orchestration-trace logging is understood as a prerequisite, not an afterthought.
• “Explain why tool scoping for an agent is architecturally similar to least-privilege IAM design.” — tests whether the security parallel is genuinely understood, not just recited.
• “What does Knowledge Bases add on top of a hand-rolled RAG pipeline?” — tests understanding of managed ingestion/chunking/embedding/vector-store integration versus custom build cost.
• “What problem does MCP solve that a bespoke, per-integration tool API doesn’t?” — tests understanding of standardization and portability across agent frameworks.