ExamFinch.com My Study

Study guide

5.2 Agent Frameworks, MCP & Lifecycle Management

Practice this exam

AWS Certified Generative AI Developer - Professional AIP-C01

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam Overview & Foundation Model Fundamentals

1.1 AIP-C01 Exam Structure, Logistics & Passing Strategy 1.2 AIP-C01 Scoring & Professional Decision Strategy 1.3 Foundation Model Landscape & Model Selection on Amazon Bedrock 1.4 Model Abstraction, Controlled Switching & Resilience 1.5 Customization Spectrum: Prompting vs RAG vs Fine-Tuning vs Continued Pre-training 1.6 Custom Model Deployment & Lifecycle Management

2 Chapter 2: Bedrock Knowledge Bases & RAG Architectures

2.1 Managed RAG Architecture with Bedrock Knowledge Bases 2.2 Knowledge Source Integration, Synchronization & Freshness 2.3 Data Ingestion, Parsing & Chunking Strategies 2.4 Embedding Models & Vector Representations 2.5 Vector Index Scale, Migration & Retrieval Evaluation 2.6 Vector Database Selection: OpenSearch Serverless vs Aurora pgvector vs Managed Stores 2.7 Vector Store Security, Multi-Tenancy & Connectivity

3 Chapter 3: Advanced Vector Search, Indexing & Data Compliance

3.1 Hybrid Search, Metadata Filtering & Semantic Reranking 3.2 Metadata Filtering, Reranking & Query Transformation 3.3 Fine-Tuning & Continued Pre-Training Data Pipeline Engineering 3.4 Data Validation, Multimodal Processing & Model Formatting 3.5 Data Privacy, Data Residency & Compliance Governance 3.6 Privacy Preservation, Source Lineage & Audit Evidence

4 Chapter 4: Prompt Engineering & Bedrock Runtime APIs

4.1 Advanced Prompt Engineering Techniques & Inference Parameters 4.2 Inference Parameters, Prompt Governance & Regression 4.3 Converse API vs InvokeModel API & Message Formatting 4.4 Tool Calling, FM API Resilience & Model Routing 4.5 Streaming Architectures & Asynchronous Event Processing 4.6 Resilient Streaming, Deployment & Asynchronous Processing

5 Chapter 5: Amazon Bedrock Agents & Tool Integration

5.1 Agentic Architecture, ReAct Reasoning Loops & Orchestration 5.2 Agent Frameworks, MCP & Lifecycle Management 5.3 Action Groups, OpenAPI Schemas & AWS Lambda Integration 5.4 Agent Memory, Session State & Multi-Agent Collaboration Patterns 5.5 Persistent State & Multi-Agent Coordination 5.6 Advanced Agent Prompt Templates & Flow Customization 5.7 Agent Safeguards, Tool Reliability & Cost Control

6 Chapter 6: Workflow Orchestration & Application Integration

6.1 Amazon Bedrock Prompt Flows & Visual Orchestration 6.2 Step Functions Orchestration & Human-in-the-Loop Workflows 6.3 Enterprise Integration: API Gateway, AppSync, and EventBridge 6.4 Hybrid Integration, GenAI Gateways & CI/CD Tooling

7 Chapter 7: AI Safety & Guardrails for Amazon Bedrock

7.1 Guardrails Architecture, Denied Topics & Content Filters 7.2 Content Safety, Defense in Depth & Threat Detection 7.3 Sensitive Information Filters & PII Redaction/Masking 7.4 Contextual Grounding Checks & Hallucination Prevention

8 Chapter 8: Security, Access Control & Network Architecture

8.1 IAM Least Privilege & Resource Policies for Bedrock 8.2 PrivateLink VPC Endpoints & Network Isolation 8.3 Encryption with AWS KMS & Cross-Account Access Patterns

9 Chapter 9: Governance, Auditing & Operational Logging

9.1 SageMaker Model Cards & AI Governance Frameworks 9.2 Lineage, Fairness, Transparency & Continuous Governance 9.3 Invocation Logging, CloudTrail Auditing & Observability 9.4 Responsible AI, Bias Mitigation & Red Teaming Methodologies

10 Chapter 10: Performance, Throughput & Cost Optimization

10.1 On-Demand vs Provisioned Throughput & Capacity Planning 10.2 Capacity Measurement, Scaling Patterns & Resilience 10.3 Batch Inference & Bedrock Intelligent Prompt Routing 10.4 Intelligent Prompt Routing & Application Eligibility 10.5 Prompt Caching, Token Optimization & Latency Reduction

11 Chapter 11: Testing, Evaluation & Troubleshooting GenAI Solutions

11.1 Amazon Bedrock Model Evaluation (Automatic & Human Workflows) 11.2 Human, RAG & Continuous Evaluation 11.3 Evaluation Metrics & RAG Quality Benchmarking (Ragas, ROUGE, BLEU) 11.4 RAG and Agent Performance Evaluation 11.5 CloudWatch Metrics, Throttling & Operational Observability 11.6 Quota Diagnosis, Retry Control & Operational Troubleshooting 11.7 Troubleshooting Common GenAI Failure Modes & Agent Traces 11.8 Prompt Maintenance, Content Handling & Deployment Validation

5.2 Agent Frameworks, MCP & Lifecycle Management

Key Takeaways Explain This Topic AI

Use specialized agents only when measured benefit exceeds coordination cost and failure risk.

MCP standardizes discovery and invocation but does not make a tool trusted or authorized.

Version agent instructions, tools, knowledge sources, and aliases as one evaluated release.

Last updated: September 2026

  • 5.2 Agent Frameworks, MCP & Lifecycle Management
  • Agent Lifecycle, Versioning, and Routing

Bedrock Agents implement an immutable lifecycle architecture designed to support CI/CD pipelines, automated testing, and zero-downtime production deployments.

1. Working Draft ( DRAFT )

When an agent is created or modified, all changes exist exclusively within the DRAFT version. The DRAFT is a mutable sandbox where developers iterate on instructions, attach or detach knowledge bases, and adjust action group schemas.

2. The Agent Preparation Step ( PrepareAgent API)

Changes made to the DRAFT version do not take effect immediately at runtime. Before testing or publishing updates, developers must invoke the PrepareAgent API (or click Prepare in the AWS Management Console). The preparation process compiles the agent's prompt templates, action schemas, and knowledge base associations into an optimized runtime artifact. Invoking an agent whose status is NOT_PREPARED executes outdated logic or raises configuration exceptions.

3. Immutable Numeric Versions

Once the DRAFT reaches a stable, tested state, developers publish an immutable version (e.g., 1 , 2 , 3 ) using the CreateAgentVersion API. Published versions are static snapshots: their instructions, foundation models, action groups, and schema configurations are permanently locked and cannot be edited. If architectural changes are required, developers update the DRAFT , call PrepareAgent , and publish version 4 .

4. Agent Aliases and Traffic Routing

Client applications should never bind directly to numeric versions or the mutable DRAFT . Instead, invocations target Agent Aliases (such as DEV , STAGING , or PROD ). An alias acts as a stable routing pointer to one or more published numeric versions.

  • Aliases support routing configurations for canary deployments and blue/green rollouts: {
  • "routingConfiguration": [
  • {
  • "agentVersion": "1",
  • "weight": 90
  • },
  • {
  • "agentVersion": "2",
  • "weight": 10
  • }
  • ]
  • }

This enables teams to route 10% of live production traffic to a newly released version while monitoring CloudWatch metrics and agent traces before shifting 100% of the workload.

User Session Management & The InvokeAgent API

Bedrock Agents maintain state across conversational turns through the InvokeAgent runtime API. The client application initiates and continues interactions by specifying a unique session identifier.

Core InvokeAgent Parameters

agentId : The unique identifier of the Bedrock Agent.

agentAliasId : The alias representing the target release (e.g., TSTALIASID for test or production alias).

sessionId : An arbitrary, alphanumeric string (minimum 2 characters, maximum 100 characters) supplied by the caller to identify the conversation. Reusing the same sessionId across sequential requests preserves conversational memory, session attributes, and prior dialogue context.

inputText : The natural-language query or command from the user.

enableTrace : A boolean flag ( true or false ). When set to true , the API returns detailed diagnostic tracing information in the response stream, exposing the agent's internal thoughts, tool invocations, and observations.

sessionState : Optional object allowing callers to inject sessionAttributes (persisting across the entire session) or promptSessionAttributes (scoped to the single turn).

Session Lifecycle and Idle Timeouts

Amazon Bedrock maintains active session context in memory for a default idle time-to-live (TTL) of 30 minutes . If no requests are received for a given sessionId within 30 minutes, Bedrock terminates the session. A subsequent call with the same sessionId initiates a brand-new conversation without prior context. The idle session TTL can be configured up to session boundaries to match business requirements.

Response Streaming

The InvokeAgent API returns an asynchronous event stream ( ResponseStream ). Clients consume the stream to process real-time events:

chunk : Contains incremental UTF-8 text bytes of the generated response as tokens are produced by the foundation model.

trace : Emitted when enableTrace=true , delivering granular ReAct reasoning steps, tool input parameters, and Lambda responses.

returnControl : Emitted when an action group is configured for client-side tool execution, passing parameters to the client for local execution.

Traditional Deterministic Workflows vs. ReAct Agents

Architectural Dimension Traditional Workflows (e.g., Step Functions) Bedrock Agents (ReAct Orchestration)

Execution Path Rigid, predefined state machine branches. Unforeseen inputs fail or hit catch-all error states. Dynamic, non-linear reasoning. Adapts to novel user requests and re-plans based on tool outputs.

Tool Argument Extraction Requires strict regex, rule engines, or explicit UI form fields. Natural language comprehension extracts parameters directly from unstructured conversation.

Handling Ambiguity Cannot handle missing data without hardcoded validation forms. Autonomously asks clarifying follow-up questions to elicit required parameters.

Latency & Predictability Deterministic, highly predictable latency and execution paths. Variable latency and token consumption depending on the number of ReAct reasoning loops.

Cost Profile Predictable, low compute cost per state transition. Incurs foundation model token charges for each ReAct thought, tool selection, and response step.

  • Exam Scenarios & Common Architectural Traps
  • Real-World Exam Scenario

A enterprise logistics company develops a shipment tracking agent. During testing, a developer updates the agent's system instructions in the AWS Management Console to mandate that users provide a tracking PIN before viewing shipment locations. However, when the automated test suite invokes the agent alias pointing to DRAFT , the agent continues to disclose shipment locations without prompting for the PIN.

Diagnosis & Resolution : The developer modified the working draft but failed to trigger the PrepareAgent operation. In Amazon Bedrock, changes to instructions, action groups, or knowledge bases in DRAFT remain uncompiled until PrepareAgent is executed. The test environment was executing the previous compiled runtime build. Executing PrepareAgent compiles the new instructions into the runtime environment, resolving the issue.

Common Traps to Avoid

Trap 1: Hardcoding Production Clients to DRAFT : Directly targeting the DRAFT version in production code leaves the application vulnerable to breaking changes whenever developers modify the agent. Production clients must always target a published Alias pointing to an immutable numeric version.

Trap 2: Forgetting PrepareAgent Before Version Publication : Attempting to create an agent version when the agent is in a NOT_PREPARED state will either fail or publish an obsolete build. The lifecycle must strictly follow: Edit DRAFT → Invoke PrepareAgent → Test → Publish Version → Update Alias.

Trap 3: Over-Relying on Agents for Static 2-Step Workflows : If a business process strictly consists of Step A followed unconditionally by Step B with no conditional branching or language understanding, implementing a Bedrock Agent introduces unnecessary token latency and cost. AWS Step Functions is the optimal choice for static, deterministic pipelines.

Strands, Agent Squad, and MCP

The current blueprint explicitly includes Strands Agents, AWS Agent Squad, and Model Context Protocol (MCP). Strands provides an agent-development approach for model, tool, and loop composition. AWS Agent Squad is an example of coordinating specialized agents. These frameworks do not remove the need for a deterministic application boundary: define which agent owns a task, what evidence is handed off, how conflicts are resolved, and when the workflow stops.

MCP standardizes how a client discovers and invokes server capabilities. A lightweight stateless server can be implemented behind Lambda-oriented HTTP patterns; more complex or long-running tools can use container services such as ECS or AgentCore Runtime. Current AgentCore documentation supports streamable HTTP and both stateless and stateful MCP modes. Validate tool schemas, authenticate clients, authorize each operation, constrain egress, cap time and recursion, and treat all tool output as untrusted input to the model.