A field-service assistant reads a repair manual, retrieves a customer’s ticket and proposes a visit. The moment it can change a booking, an incorrect tool call is no longer merely a poor answer: it has altered an operational record. Safe agent architecture begins at that boundary.<\/p>\n
The AIP-C01 exam<\/a> includes tool contracts, agent state, integration, IAM and reliable operation. In July 2026, AWS placed Bedrock Agents Classic in maintenance mode for new customers; the recommended direction for modern agent workloads is Amazon Bedrock AgentCore. The migration question is how to preserve authorized business behavior, not simply how to change an SDK name.<\/p>\n A work-order lookup is a bounded operation: given an authorized ticket ID, return the current state. An agent may need reasoning to identify a customer’s ambiguous problem and decide which supported operation to request, but the ticket service retains authority over what it returns. The same separation applies to booking an appointment. The model proposes the action; a business service validates identity, permissions and the actual available slot.<\/p>\n Write down which operations can change state before choosing a framework. Reading an approved repair guide is different from altering a customer appointment. If the proposed design needs a general administrator credential merely to support a conversation, redesign the API boundary rather than inventing an elaborate prompt intended to keep the agent polite.<\/p>\n AWS documents that Amazon Bedrock Agents Classic is no longer available to new customers after July 30, 2026. Amazon Bedrock model inference, Knowledge Bases and Guardrails continue. Existing supported customers can maintain Classic workloads, while AgentCore is the modern option for new agent development and migration planning.<\/p>\n An existing Classic system may depend on agent action groups and infrastructure definitions that cannot be migrated by renaming one resource. Document tool behavior, permission boundaries, state persistence, evaluation cases and application contracts before changing runtimes. A migration is complete only when the new deployment preserves the accepted customer outcomes and failure handling.<\/p>\n AWS’s AgentCore Gateway configuration also distinguishes target types. A Lambda target that uses the gateway service role is not the same as an external MCP service that expects OAuth or an API key, and support differs by target. The architecture review should name the actual target, its supported authorization mechanism and whether the business system sees the end-user identity or only a shared integration principal. In a shared-gateway deployment, constrain which callers can discover and invoke sensitive targets using available gateway policy and backend access controls. Test a legitimate tool call and a prohibited one with real application principals. A gateway that authenticates the caller but lets every authenticated person invoke a powerful tool has solved only the first half of the problem.<\/p>\n Amazon Bedrock AgentCore Gateway can expose approved tools through MCP interfaces. Its inbound authorization<\/a> controls who may invoke the gateway, while outbound authorization defines how it connects to a target. Depending on the target and configuration, AWS supports IAM signing and appropriate OAuth-based mechanisms. A valid gateway token does not give the caller unrestricted rights to every backend business record.<\/p>\n Suppose a service role can read all customer tickets but employee A should only see customer A. The target API must enforce that relationship, or a supported delegated identity flow must preserve the caller’s privileges. Don’t pass arbitrary account IDs from free-text prompts directly into privileged APIs without independent authorization checks.<\/p>\n Treat tool-discovery metadata and schemas as approved integration configuration. Adding a new mutation tool changes the agent’s possible actions even when its conversational instructions remain identical.<\/p>\n An API contract might represent an appointment request with fields for ticketId, customerId, proposedWindow, operationId and expectedCaseVersion. The backend validates those fields, compares the current case version and returns a controlled state. If a second request arrives with the same operationId, it should report the original outcome rather than create another booking. This is illustrative application design, not an AgentCore-specific API format. The important distinction is that the durable business record, not a model-generated sentence, is authoritative. The application should be able to reconcile an uncertain result after the response stream disconnects or a network timeout occurs.<\/p>\n A scheduling tool should accept a validated ticket ID, a proposed time window, the authorized actor and a stable request identifier. Its response must distinguish rejected, awaiting approval, accepted and committed states. The agent must not tell a customer that a visit exists until the scheduling system has a corresponding durable record.<\/p>\n A timeout after commit is especially dangerous. If the model retries with a fresh identifier, two visits could be created. Enforce idempotency<\/a> or a comparable transaction-safe rule in the backend, and give operators a way to reconcile unknown outcomes. Exponential backoff addresses temporary overload; it does not prevent a duplicate side effect.<\/p>\nDecide which part is an agent and which part is a tool<\/h3>\n
Agents Classic remains relevant, but new-account availability changed<\/h3>\n
Gateway authentication and tool authorization are different decisions<\/h3>\n
Make every state-changing tool narrow and verifiable<\/h3>\n