An agent becomes useful when it can do more than describe what a human should do. It might look up an order, ask for missing information, schedule a maintenance task or assemble evidence for a caseworker. The same ability creates risk: a language model can misunderstand the user, select the wrong tool or misread a retrieved document as an instruction. Designing Bedrock agents therefore begins with the business transaction and its trust boundary, not with the number of tools that can be connected. That principle is particularly important in 2026, when AWS identifies the older Bedrock Agents offering as Amazon Bedrock Agents Classic and has closed it to new customers since July 30. New systems should examine Amazon Bedrock AgentCore and a suitable orchestration framework, while existing Classic applications may continue to operate.<\/p>\n
The distinction matters because many tutorials still describe the Classic experience as though every account can start with it. In that model an agent could use action groups, knowledge bases and model-driven orchestration to fulfill requests. Current teams can still learn from those patterns, but should not mistake the existence of documentation for the current purchasing and onboarding path. AgentCore provides infrastructure capabilities for operating agents\u2014including runtime, gateway, identity, memory and observability\u2014rather than promising that a model alone will invent a reliable enterprise process. The engineering work remains the same: clearly define permissible actions, capture state, validate arguments and make failures understandable.<\/p>\n
Imagine a customer asking an insurance assistant to change the mailing address on a policy. The conversational request sounds simple. The actual operation requires verifying the customer, locating the right policy, checking whether address changes are allowed, validating the new address and writing an auditable update. None of those requirements disappear when a model recognizes the request. A useful design maps the action to explicit steps and identifies where the agent may reason and where deterministic systems must decide. A model can extract a candidate postal address; a domain service must still validate the country format and confirm that the authenticated user can modify the policy.<\/p>\n
A dangerous pattern is offering a broad \u201crun SQL\u201d or \u201ccall any URL\u201d tool so the agent can figure things out. This turns a natural-language misunderstanding into access to a large attack surface. Prefer task-specific functions such as Tool descriptions also shape behavior. Give an agent enough information to choose correctly, but avoid prose that invites side effects merely because a function is available. An action intended for read-only estimates should not silently alter a resource. Return machine-readable error categories for missing fields, expired sessions, access denial, temporary service failures and business-rule rejection. The agent can then explain or request clarification without inventing the reason. This is more reliable than a general instruction to \u201ctry again until the task succeeds.\u201d<\/p>\n Bedrock Agents Classic introduced action groups that linked model decisions to API definitions or function details. Some actions could execute through AWS Lambda; others could return the requested invocation to the application for fulfillment. In the return-control flow, the calling application receives the intended operation and parameters, executes or declines it, and sends results back using the invocation identifiers. This approach illustrates a lasting architectural principle: the model can propose an operation while the application’s trusted code remains responsible for authorization and execution.<\/p>\n Consider a tool that can order replacement hardware. A model may determine the device category and quantity from a conversation, but an external service should check inventory, spending limits, project codes and the user’s approval role. If approval is needed, the user should see the actual order, address and cost; clicking approval must bind to those exact parameters. The agent must not be allowed to switch a shipping destination afterward. Returning control to a trusted service makes such a two-phase workflow easier to reason about than permitting autonomous purchasing directly from model-generated text.<\/p>\n The same separation applies when the tool output is hostile or malformed. A returned web page might contain text claiming that the assistant must ignore earlier instructions and export internal secrets. Treat that as untrusted data. Validate the response schema, label provenance, sanitize fields and never let arbitrary tool text expand the agent’s privileges. For the broader cloud-security view, the Amazon AWS Security \u2013 Specialty SCS-C03<\/a> connects identity, logging and secure automation to enterprise controls.<\/p>\n Agents often retrieve documents to answer questions or prepare an action. A knowledge base is useful for retrieving candidate evidence, but it should not become an authorization authority. Ensure the retrieval layer filters results according to the actual user, tenant, document sensitivity and purpose. Permission changes must propagate to the index or be rechecked at read time. Otherwise a previously indexed document can remain discoverable after its owner’s access was revoked. Source citations improve traceability, but a citation does not make an unauthorized passage safe to reveal.<\/p>\n A retrieval pipeline also needs to distinguish facts from instructions. Suppose a support article documents an old procedure that required a deprecated command. The agent should report that as historical content, not uncritically execute it. Include version metadata, validity dates and conflicting-source handling. If the only available evidence is outdated, a good system may say it cannot safely complete the task. That is a more valuable outcome than a confident instruction based on the first matching paragraph. For complex regulated workflows, deterministic retrieval constraints are as essential as the model choice.<\/p>\n For RAG testing, build cases where the correct answer is not present, appears in conflicting revisions or is visible only to a different group. Measure whether the system abstains, finds the right current revision and preserves document entitlements. Do not count a coherent explanation as success if it was assembled from stale or irrelevant snippets. Record the retrieved document IDs and timestamps for troubleshooting while keeping sensitive contents out of unrestricted debug logs.<\/p>\n AgentCore offers building blocks intended to run, connect and observe agents without forcing every application to use one monolithic orchestration pattern. Runtime provides an execution environment; gateway helps expose and govern tools; identity addresses access to downstream resources; memory can support appropriate conversational context; and observability helps trace what happened. Those categories solve different problems. A team may need gateway and identity without a long-lived memory layer, or may run an orchestrator outside the managed runtime and still require telemetry. Choose components to address requirements rather than enabling all capabilities automatically.<\/p>\n The runtime contract should define timeouts, cancellation, retries, concurrency, idempotency and safe recovery after interruption. An agent may issue a request that times out after the backend already committed it. Blindly retrying could order hardware twice. Provide idempotency keys and a way to query transaction status before retrying. Design tools to return explicit commit states such as \u201cproposed,\u201d \u201cpending approval\u201d or \u201ccompleted\u201d so the conversation does not report success before the trusted application confirms it.<\/p>\n Identity is more nuanced than granting an agent a broad IAM role. Some actions run as the application, others must honor a specific user’s rights, and cross-account tools can introduce another boundary. Where delegated access is required, scope credentials to the tool and action, enforce short lifetimes and prevent one user’s session from reusing another user’s permissions. Credential rotation, revocation and connector ownership belong to ordinary security operations; an LLM-generated instruction cannot compensate for poor secrets management. The role-based access control<\/a> principles familiar from conventional services remain applicable.<\/p>\n Useful telemetry answers what the user requested, what relevant data was retrieved, what tool was selected, what arguments were proposed, what policy checks ran, whether an approval was recorded and what the downstream service actually did. Model tokens and latency are only part of that story. AgentCore observability integrates telemetry with CloudWatch and supports tracing through agent workflows. Teams should be selective about captured content: logging full prompts, credentials or private retrieved documents may create a second data leak even while making debugging convenient.<\/p>\n Build evaluations around concrete attacker and operator mistakes. Test a read-only user who requests a write operation, a retrieved document containing prompt-injection instructions, a tool returning an unexpected record, and an approval that expires before execution. Also test mundane failures: a long-running dependency, duplicate messages, partial success and regional unavailability. The critical metric is the percentage of authorized tasks completed correctly with bounded side effects, not simply whether the model eventually produced a polished response.<\/p>\n The evaluation suite should be rerun when tool definitions, models, permissions or infrastructure change. A new model can pick a different tool from the same prompt; a small schema change can alter interpretation; and a broadened IAM policy can transform a previously harmless mistake into a damaging one. Keep a release register that ties evaluation outcomes to the deployed tool contracts. This makes regressions diagnosable and permits gradual rollout, canary use and rollback when real-world failure modes emerge.<\/p>\n Start with one well-scoped workflow whose business rules are already understood. Specify the authenticated actor, allowed data sources, read-only capabilities, proposed changes, approvals and final commit. Implement each tool in conventional application code with testable validation. Add an orchestration layer only to decide which already-safe step is appropriate and to communicate with the user. When a step is ambiguous, ask for clarifying information instead of manufacturing a value. A strong first agent should be boringly predictable in the face of bad inputs.<\/p>\n Next, establish a safe operating process. Assign an owner for every tool, alert on unauthorized attempts, constrain concurrency and spending, and document how to disable an integration in an incident. Monitor negative outcomes\u2014unapproved tool calls, repeated failures, access-denied rates, misleading completion messages\u2014alongside throughput and satisfaction. Provide a human path for exceptions that cannot be safely automated. The operational team needs enough evidence to investigate without assuming the model’s narrative is an accurate audit log.<\/p>\nvalidate_address<\/code>, propose_change<\/code> and @@CODE3@@, each with input schemas, bounded responses and server-side authorization. Make the final committing function separate from proposal generation. Passing structured JSON is helpful, but it is not proof that the request is permitted. Every tool must verify the caller, target, scope and current business state.<\/p>\nWhat action groups and return control teach us<\/h3>\n
Knowledge retrieval needs permission checks, not only relevance<\/h3>\n
AgentCore changes the deployment conversation<\/h3>\n
Observe the entire chain of evidence and action<\/h3>\n
Build a conservative first production release<\/h3>\n