\nAgentic AI applications differ from ordinary prompt-response systems because the model can plan, call tools, retrieve context, preserve memory, and continue through several steps before returning a result. On AWS, current production agent architecture centers increasingly on Amazon Bedrock AgentCore resources such as Runtime, Gateway, Identity, Memory, tools, observability, and policy integrations. Amazon Bedrock Agents Classic still exists for existing customers, but AWS now documents it as not open to new customers, so new architectures should be evaluated against AgentCore rather than designed around the older service by default.<\/p>\n
The current AWS Certified Generative AI Developer \u2013 Professional (AIP-C01)<\/a> exam covers agentic AI, RAG, security, monitoring, cost optimization, CI\/CD, and enterprise integration. AWS Certified AI Practitioner<\/a> covers adjacent foundations. The linked AWS Certified Machine Learning Engineer \u2013 Associate (MLA-C01)<\/a> page is for an earlier version of a related ML engineering exam: English MLA-C01 testing ended September 28, 2026, and MLA-C02 English beta began September 29. Japanese, Korean, and Simplified Chinese MLA-C01 delivery continues during beta, as AWS\u2019s MLA-C02 transition<\/a> explains.<\/p>\n A model may propose creating a service ticket, but its output is not authorization to execute. A separate component must validate tool identity, user scope, typed arguments and any required human approval. A response timeout after ticket creation should trigger a committed-state lookup, not a duplicate create call. Limit tool depth and execution budget so a failed plan cannot loop indefinitely. Tool responses and retrieved files are data, not new system-level instructions. Record the actual business operation ID and authorization decision as evidence of completion. The Bedrock tool-use<\/a> workflow describes how models request actions, but the application remains responsible for authorization, approvals and rollback.<\/p>\n \nThe model can decide which capability is needed, but tool execution should occur through controlled interfaces with explicit schemas, authentication, authorization, and error handling.<\/p>\n Do not let model text become arbitrary shell, SQL, or API authority. Agent tools should expose constrained business operations such as \u201cget order status\u201d or \u201ccreate approved ticket,\u201d not unrestricted infrastructure access.\n<\/p>\n Agent architecture should begin with a task boundary. \u201cHelp employees\u201d is too broad; \u201csummarize an approved policy, open a support request, and check its status\u201d creates clearer knowledge, tools, permissions, and success criteria.<\/p>\n The task boundary determines which tools should exist. Every additional tool expands model choice space, authorization complexity, cost, and the chance of an incorrect call. Expose the smallest tool set needed for the current agent role.<\/p>\n Tool schemas should use precise names, typed parameters, required fields, and constrained values. Ambiguous tool descriptions force the model to infer business rules that should be encoded in the interface.<\/p>\n Validation should occur before the underlying system receives the request. Check parameter ranges, identity, resource ownership, and approval state independently from the model’s reasoning.<\/p>\n High-impact actions may need human confirmation. An agent can prepare a change, explain its evidence, and request approval while an authorized user remains responsible for the final destructive or financial operation.<\/p>\n Idempotency is important because agent runtimes can retry after timeout or network failure. Tools that create tickets, send messages, or submit orders should accept stable operation IDs or otherwise detect duplicate requests.<\/p>\n Tool errors should return structured information the agent can reason about without exposing sensitive internals. Distinguish permission denied, invalid input, transient service failure, and business-rule rejection so the agent chooses the right recovery path.<\/p>\n Retry policy should remain bounded. An agent that keeps retrying a failing tool can increase cost or create rate-limit problems. Limit attempts and escalate or stop when the failure is unlikely to resolve automatically.<\/p>\n Human-in-the-loop checkpoints can be inserted at several stages: before using a sensitive source, before high-impact tool execution, or before finalizing a regulated recommendation. The checkpoint should have enough evidence for the reviewer to make an informed decision.<\/p>\n Retry behavior should preserve idempotency and user intent. A network timeout after creating a ticket should lead to a status check before the agent creates a second ticket automatically.<\/p>\n \nAgentCore Runtime can host agent code and provide session-aware invocation, streaming responses, and integration with other AgentCore services. It creates an operational boundary around the agent rather than requiring teams to invent every hosting primitive themselves.<\/p>\n The runtime should still be treated as application infrastructure: version code, manage permissions, control network egress, and test behavior before promotion.\n<\/p>\n Network egress should be controlled. Agents capable of arbitrary HTTP access can leak data or call unapproved systems. Route external access through governed tools, gateways, VPC controls, or allowlists according to the environment’s threat model.<\/p>\n Agent registries can help organizations discover deployed runtimes and gateways across accounts. Discovery should be paired with ownership and lifecycle metadata so the registry becomes an operational inventory rather than a list of anonymous agents.<\/p>\n Production rollout should include traffic controls so one new agent version cannot consume all tool quotas or downstream API capacity. Rate limits and circuit breakers protect shared enterprise systems.<\/p>\n Disaster recovery should cover memory, gateway configuration, policies, and runtime artifacts, not only the agent code. Restoring one component without the others can produce inconsistent behavior after an outage.<\/p>\n Decommissioning should revoke tool credentials, remove gateway targets, archive or delete memory according to policy, retire registry entries, and stop observability billing. Agent lifecycle is broader than deleting one runtime.<\/p>\n AgentCore’s rapid feature evolution makes current documentation important. Production architecture should use generally available capabilities appropriate to the workload and keep preview features isolated until the organization accepts their support and change risk.<\/p>\n \nAgentCore Gateway can expose tool targets and runtime agents behind a common access layer. Current AWS capabilities also support MCP-oriented patterns, sessions, and centralized authorization for supported target types.<\/p>\n This is useful when several agents need controlled access to the same enterprise tools. Governance becomes easier when tool discovery and invocation pass through one managed boundary instead of each agent embedding credentials independently.\n<\/p>\n Gateway architecture is useful for centralizing tool governance, but the gateway should not become one overprivileged service identity. Preserve caller or workload context and use target-specific permissions.<\/p>\n MCP-style tool interoperability<\/a> can reduce custom integration work, but exposed tool catalogs should still be curated. Discoverability is not authorization; a tool appearing in the registry does not mean every agent should be able to invoke it.<\/p>\n Agent versioning should include tool contracts. A prompt expecting `customer_id` can fail after the tool backend changes the parameter to `account_id`, so interface compatibility must be tested like an API contract.<\/p>\n Tool discovery through MCP or gateway catalogs can increase flexibility, but dynamic discovery should not mean unrestricted use. Policy should decide which tools are visible and invocable for a given agent, user, or task.<\/p>\n Code-interpreter tools create a stronger execution boundary. Limit filesystem, network, package installation, runtime duration, and data access according to the use case. A powerful execution sandbox still needs explicit constraints.<\/p>\n \nAgent actions often need to reflect the caller’s authority. AgentCore Identity and application IAM should preserve enough user or workload context that the agent cannot escalate privileges simply because the model requests a tool call.<\/p>\n Authorization must follow the acting identity, target resource, and task context rather than a single shared administrator role for every tool invocation. A valid model-generated request does not expand that authorization.<\/p>\n AgentCore Identity can help integrate OAuth clients, API keys, and other supported identity patterns. The architecture should decide whether the agent acts as itself, on behalf of a user, or under a service role for each tool interaction.<\/p>\n Guardrails can filter content, sensitive information, or unsafe categories where configured, but they should complement application authorization rather than replace it. A model-safety policy cannot decide whether one employee may refund another employee’s account.<\/p>\n Session management should account for identity changes. If a user logs out or changes authorization, long-lived agent sessions should not continue using stale privileges or memory scoped to the prior identity.<\/p>\n \nShort-term session context and longer-term memory can help agents preserve preferences, state, or learned facts across interactions. Memory also creates privacy, deletion, retention, and correctness responsibilities.<\/p>\n Do not store every conversation indefinitely by default. Define what information belongs in memory, how it is scoped to users or agents, and how outdated or sensitive memory is removed.\n<\/p>\n Memory should have scope. User-specific preferences should not leak across users; project memory should not become global; and sensitive context should not be written to long-term memory merely because it appeared in a conversation.<\/p>\n Long-term memory also needs conflict and freshness rules. A remembered preference or fact can become outdated, and the agent should know when authoritative enterprise data should override stored memory.<\/p>\n Memory migrations deserve the same care. Changing the schema or interpretation of long-term memory can cause an upgraded agent to misread records written by the previous version. Version memory structures or provide migration logic where persistence spans releases.<\/p>\n \nAgents frequently need trusted organizational context before acting. Amazon Bedrock Knowledge Bases and other retrieval systems can supply documents and facts while keeping tool actions separate from knowledge retrieval.<\/p>\n Grounding does not automatically make an answer correct. Evaluate retrieval quality, stale documents, permissions, and citations so an agent does not take action from irrelevant or unauthorized evidence.\n<\/p>\n Retrieval should be permission-aware. An agent should not retrieve a confidential policy and then be blocked only at the final tool call; sensitive evidence should be filtered before it enters the model context.<\/p>\n External web or browser tools should be treated as untrusted input channels. Retrieved pages can contain malicious prompt instructions or misleading content, so the agent should separate tool data from system authority and validate outputs before acting.<\/p>\n Prompt injection testing should include indirect injection from retrieved documents and tool responses, not just malicious user prompts. Agents consume many external text channels that can attempt to influence behavior.<\/p>\n \nMultiple specialized agents can divide work by domain, tool set, or trust boundary. A coordinator can route tasks while subagents focus on narrower capabilities.<\/p>\n Multi-agent design adds latency, cost, and observability complexity. Use it only when specialization or security boundaries provide clear value over one well-designed agent.<\/p>\n Policy and guardrails should remain independent controls around agent behavior. Agent behavior should be constrained by tool permissions, model safety controls, Bedrock Guardrails where appropriate, and policy checks around actions. A prompt instruction such as \u201cnever delete data\u201d is weaker than an API that does not expose deletion or requires separate authorization.<\/p>\n The strongest agentic pattern uses the model as an orchestrator inside a governed system rather than as the system itself. Identity, tools, data, policy, memory, and observability remain explicit services around the model’s probabilistic decisions.<\/p>\n Agent boundaries should also reflect failure domains. A finance agent and an IT operations agent may use the same runtime technology but should not necessarily share tool credentials, memory, or policy because a compromise or bad prompt in one domain should not expose the other.<\/p>\n Cost and safety can interact. Restricting unbounded loops, recursive delegation, and repeated tool calls reduces both risk and spend. Hard execution budgets are often useful safeguards for agentic systems.<\/p>\n Multi-agent systems need clear context boundaries. Passing the full conversation and every tool result to every subagent increases token cost and data exposure. Delegate only the context each specialist needs.<\/p>\n Coordinator agents should be evaluated for routing accuracy as well as final task success. A technically correct final answer can hide unnecessary delegation that increases latency and cost.<\/p>\n \nAgentCore observability can emit metrics, logs, spans, and traces for runtime, memory, gateway, tools, identity, and related resources. Track model calls, tool selections, latency, errors, throttling, safety events, and task completion.<\/p>\n Observability should answer what the agent attempted, which tool ran, under whose identity, with what result, and where time or cost accumulated.\n<\/p>\n Observability should use one trace or correlation identifier across model calls, memory access, gateway calls, tools, and application logs. This makes a multi-step agent interaction diagnosable without manually matching timestamps.<\/p>\n Cost should be attributed at task level. One user request can produce several inference calls, searches, tool invocations, memory operations, and CloudWatch events. Track the full workflow rather than only model-token spend.<\/p>\n Latency budgets should also be decomposed. If a task takes ten seconds, operators should know how much time belonged to model reasoning, retrieval, tools, network, or downstream systems.<\/p>\n Observability data can be sensitive because traces may contain prompts, tool arguments, memory content, or retrieved text. Apply retention, access, and masking appropriate to the information captured.<\/p>\n Agents should expose enough status for users to understand long tasks. Progress such as \u201cretrieving data,\u201d \u201cwaiting for approval,\u201d or \u201ctool failed\u201d is more useful than a silent spinner and can reduce duplicate submissions.<\/p>\n \nTest task completion, tool sequence, safety, authorization, recovery from tool failure, memory correctness, and human escalation. Current AgentCore evaluation capabilities support automated evaluation patterns that go beyond one final response score.<\/p>\nSeparate reasoning from tool execution<\/h2>\n
Use AgentCore Runtime as a managed execution boundary<\/h2>\n
Use Gateway to centralize tool access<\/h2>\n
Use Identity for workload and user-aware authorization<\/h2>\n
Add memory only where it improves the task<\/h2>\n
Use RAG and enterprise data as evidence<\/h2>\n
Design multi-agent systems around clear delegation<\/h2>\n
Instrument every reasoning-to-action boundary<\/h2>\n
Evaluate agents as workflows, not chatbots<\/h2>\n