Generative AI on AWS now spans much more than choosing a foundation model and sending it a prompt. Production systems need model access, tool execution, identity, memory, retrieval, observability, evaluation, guardrails, vector search, deployment automation, and cost controls that can survive real users. Amazon Bedrock provides model and orchestration capabilities, while Amazon Bedrock AgentCore adds managed infrastructure for agents that need gateways, identity, memory, runtime, observability, policy, and related production services.<\/p>\n
This page upgrades the existing AWS generative AI overview at its current URL. It is the parent for the new Amazon<\/a> GenAI cluster, including AgentCore, Bedrock Agents, the Converse API, Bedrock Flows, Guardrails, Aurora pgvector, and later articles on evaluation, networking, inference, and RAG quality. The goal is to keep the hub architectural: which service owns each responsibility, where controls sit, and how the pieces fit without turning every workload into the same design.<\/p>\n The existing article on Amazon Bedrock Agents<\/a> is useful context because agent diagrams often compress several operational boundaries into one box. A production AWS GenAI architecture is stronger when those boundaries are explicit.<\/p>\n There are several legitimate ways to build an agent or GenAI application on AWS. A simple application can call Amazon Bedrock through the Converse API and keep orchestration in application code. Bedrock Agents can manage the model-driven loop and use action groups or knowledge bases. Bedrock Flows can coordinate prompts, agents, knowledge-base retrieval, Lambda functions, conditions, and code nodes through a versioned flow. AgentCore can host and operate more general agent frameworks and expose production services such as Gateway, Identity, Memory, Observability, Runtime, Policy, Browser, and Code Interpreter.<\/p>\n The correct boundary depends on how much orchestration the application wants AWS to manage. Bedrock Converse API<\/a> is a good fit when the team owns the control loop and wants one conversational interface across supported models. Bedrock Agents Tool Use<\/a> is appropriate when action groups and the Bedrock agent runtime should own tool selection and fulfillment. Amazon Bedrock Flows<\/a> is useful when the workflow needs an explicit graph of deterministic and generative steps.<\/p>\n AgentCore belongs at a different layer. It can work with agents built using different frameworks and models, providing operational services around them rather than requiring one Bedrock-native reasoning loop.<\/p>\n AgentCore separates responsibilities that many teams otherwise build repeatedly. Amazon Bedrock AgentCore Gateway<\/a> provides a managed MCP-oriented entry point to tools and other targets. Amazon Bedrock AgentCore Identity<\/a> gives agents stable workload identities and manages credentials for user-delegated or machine-to-machine access. Amazon Bedrock AgentCore Memory<\/a> separates short-term events from long-term extracted memories and organizes them by actor, session, strategy, and namespace.<\/p>\n Amazon Bedrock AgentCore Observability<\/a> then closes the operations loop with CloudWatch-backed metrics, logs, spans, traces, and session views using OpenTelemetry-compatible telemetry. These services can be used together, but they should not be treated as one inseparable bundle. A team may need Gateway and Identity without long-term memory, or Observability for an agent hosted outside AgentCore Runtime.<\/p>\n This separation matters for governance. Identity policy should not be hidden inside the prompt. Memory retention should not be coupled accidentally to runtime scaling. Tool registration should not be mixed with model instructions. Independent services give teams clearer control points.<\/p>\n Amazon Bedrock now supports multiple tool-use patterns. The Converse API can perform client-side tool use where the model requests a tool and application code executes it. The broader Bedrock tool-use surface can also support server-side tool execution in selected APIs, while Bedrock Agents can use action groups backed by Lambda or return control to the application. AgentCore Gateway exposes tool capabilities through MCP.<\/p>\n The model-side tool schema describes what is callable. The security architecture still has to decide who may call it, under which identity, with what arguments, and whether the action is safe to repeat. API security<\/a> remains relevant because agent tools are still APIs even when the model chooses them.<\/p>\n High-impact tools should use deterministic authorization and approval outside the model. A prompt that says \u201cnever perform destructive actions without permission\u201d is not a substitute for a policy engine, IAM permission, or application-side check.<\/p>\n Agent memory stores information about prior interactions or extracted facts that should persist across sessions. Retrieval supplies external knowledge relevant to the current request. Mixing them creates confusing state: a user preference is not the same thing as a knowledge-base passage, and a document chunk is not automatically a fact the agent should remember about a person.<\/p>\n AgentCore Memory provides short-term events and optional long-term strategies that extract structured memories. Bedrock Knowledge Bases and vector stores provide retrieval. The existing Amazon Bedrock Knowledge Bases<\/a> article explains where managed retrieval fits, while Aurora pgvector Indexing<\/a> covers the database side when an application wants PostgreSQL-based vector search.<\/p>\n For RAG systems, the enterprise RAG chunking<\/a> strategy and the planned Testing RAG Quality on AWS<\/a> article matter as much as the vector database. A fast index cannot compensate for chunks that lost the meaning of the source document.<\/p>\n Amazon Bedrock Guardrails can apply content filters, denied topics, sensitive-information filters, prompt-attack detection, contextual grounding, and Automated Reasoning checks. These controls are useful, but they do not replace identity and authorization. A safe-looking model output can still trigger an unauthorized tool if the tool boundary is weak.<\/p>\n Bedrock Guardrail Automated Reasoning<\/a> adds a different type of validation by translating natural-language statements into formal logic and checking them against an explicit policy. That is strongest for domains with clear rules, not as a general truth detector for every open-ended response.<\/p>\n The existing AI guardrails and content safety<\/a> article provides the broader principle: controls should sit where they can actually enforce behavior. Later cluster articles on Private GenAI Networking on AWS<\/a> and Prompt Injection Defenses on AWS<\/a> address other layers of the threat model.<\/p>\n AWS supports several vector-search paths, including Amazon OpenSearch Service, OpenSearch Serverless, Aurora PostgreSQL with pgvector, and managed vector-store integrations through Bedrock Knowledge Bases. The right choice depends on scale, filtering, relational joins, operational ownership, latency, and retrieval requirements.<\/p>\n Vector database design<\/a> should start from the access pattern rather than the popularity of one engine. Aurora pgvector is compelling when vector search belongs close to relational data and PostgreSQL is already part of the application. OpenSearch can be stronger when search infrastructure, lexical + vector retrieval, or search-specific scaling is central to the workload.<\/p>\n The planned articles on Vector Search with Aurora PostgreSQL<\/a> and Vector Search with OpenSearch Serverless<\/a> cover those paths in more detail.<\/p>\n GenAI observability is not only model latency and token count. Agent workloads can include memory retrieval, gateway calls, policy evaluation, model inference, tool invocations, vector search, Lambda, and downstream APIs. AgentCore Observability and CloudWatch can expose service metrics and OpenTelemetry traces across those components.<\/p>\n The existing GenAI observability<\/a> article is relevant because the useful unit is often an accepted business outcome rather than one model call. Later articles such as Model Evaluation on Bedrock<\/a> and Hallucination Evaluation on AWS<\/a> extend the quality side of that operating model.<\/p>\n Teams should be able to answer whether a failure came from the model, memory, a tool, retrieval, authorization, or infrastructure. If every failure is reported as \u201cthe AI gave a bad answer,\u201d the architecture is not observable enough.<\/p>\n Prompts, flows, agent configurations, policies, model selection, tool schemas, and infrastructure all change over time. Those changes should move through version control, testing, deployment, and rollback rather than being edited manually in production with no record of what changed.<\/p>\n The existing CI\/CD for AI<\/a> article provides the general change-management principle, while the planned CI\/CD for GenAI Applications<\/a> article applies it directly to AWS generative AI workloads.<\/p>\n A production-ready AWS GenAI system is therefore a software system with probabilistic components, not a prompt demo with infrastructure added later. The strongest designs make model choice, state, identity, tools, retrieval, safety, evaluation, cost, and deployment visible enough that another engineer can operate the workload without relying on the original builder\u2019s memory.<\/p>\n That operational view also prevents service overlap from becoming architectural confusion. A team can use AgentCore Gateway with a custom agent, Bedrock Agents for another workload, and Converse for a third without forcing one standard where the responsibilities differ. The standard should be the control objectives\u2014identity, safe tools, observable execution, tested retrieval, versioned deployment, and measurable quality\u2014not one mandatory orchestration product.<\/p>\n Cost should be traced through the same architecture. Model tokens are only part of the bill; vector search, agent runtime, gateway traffic, memory, Lambda, logs, evaluations, and provisioned capacity all contribute. The existing GenAI cost on AWS<\/a> discussion is useful because optimization should follow the workload path rather than simply shortening every prompt.<\/p>\n That makes the final architecture easier to review, test, and operate.<\/p>\n","protected":false},"excerpt":{"rendered":" Generative AI on AWS now spans much more than choosing a foundation model and sending it a prompt. Production systems need model access, tool execution, identity, memory, retrieval, observability, evaluation, guardrails, vector search, deployment automation, and cost controls that can survive real users. Amazon Bedrock provides model and orchestration capabilities, while Amazon Bedrock AgentCore adds […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19759","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tChoose the execution boundary before choosing the orchestration feature<\/h3>\n
AgentCore turns agent infrastructure into separately governed services<\/h3>\n
Tool use needs both a model contract and an execution policy<\/h3>\n
Memory and retrieval solve different context problems<\/h3>\n
Guardrails, identity, and network controls address different risks<\/h3>\n
Vector search should be chosen by data and operational constraints<\/h3>\n
Observability and evaluation have to follow the full agent path<\/h3>\n
Production GenAI needs deployment discipline, not console memory<\/h3>\n