AWS previews Amazon Bedrock AgentCore

Source record: modular services in the July 2025 preview

On July 16, 2025, AWS announced the preview of Amazon Bedrock AgentCore as a set of services for deploying and operating AI agents. The announcement named runtime, memory, gateway, browser, code interpreter, identity, and observability capabilities, and said the services could work with models and frameworks inside or outside Bedrock. AWS documentation describes a managed runtime, MCP-oriented gateway, agent identity functions, isolated code execution, browser capability, and OpenTelemetry-compatible observability. The 2025 announcement was a preview notice; it does not settle present availability, regional coverage, or suitability for a specific workload.

Hypler engineering interpretation: services still need a system policy

A modular platform can make infrastructure boundaries more visible, but the application still has to decide what is allowed. An isolated runtime does not choose a safe tool policy. A memory service does not determine what may be retained. A gateway does not decide whether an API action needs human approval. Map each platform capability to an application-level policy: data categories, caller identity, allowed tools, permissible actions, evidence retention, and an owner who can disable the integration.

This mapping also avoids a common design error: assuming a vendor component replaces a control that must exist in the application. For example, a browser session may be technically isolated while the agent still submits a consequential form. The action should remain gated by the same authorization, validation, and review rules that would apply if a human used the form directly. Infrastructure isolation reduces one class of risk; it does not confer business authority.

Hypothetical workflow: read-only research with a hard stop

Consider a hypothetical research assistant that retrieves documents from an approved collection, extracts cited passages, and prepares a draft briefing. It may use a browser only for a fixed list of public domains and has no credentials for systems of record. Its memory is limited to the task session and stores source identifiers rather than unrestricted transcripts. The final output is a draft with citations and uncertainty labels; it cannot send mail, create tickets, or publish a page.

That design has a useful stop point. If a source is inaccessible, untrusted, or outside the allowlist, the workflow reports the gap. It does not seek a workaround, reuse unrelated session context, or expand its own permissions. A reviewer can decide whether to add a source or accept the incomplete briefing. The system remains helpful without converting an information request into an unattended action chain.

Architecture: explicit boundaries for memory and tools

Model access, session state, long-term memory, and tool credentials should be distinct layers. Define what enters each layer and how it expires. A tool gateway should expose a small catalog of operations with schemas, authorization checks, rate limits, and auditable outcomes. Avoid giving a general-purpose agent a broad credential simply because several future tasks might need it. Add a capability only when a named workflow and test demonstrate the need.

For code or browser execution, isolate the session and pass only task-specific inputs. Treat generated files, downloads, and browser artifacts as untrusted until validated. Keep a clear channel between a planning result and an execution request, preferably with a structured approval token or a human-confirmed transition. Observability should connect a task identifier to each tool request, policy decision, and outcome while minimizing sensitive content in routine logs.

Failure modes: remembered data and delegated authority

Memory can become a hidden source of error when stale facts, another user's context, or a prior instruction reappear in a later task. Tool gateways can convert a vague model response into a real side effect if schemas are too permissive or authorization is checked only at the start of a session. Browser automation can follow untrusted page content into actions that were never part of the request. These are design risks even when every individual managed service is functioning as documented.

Test session expiry, memory deletion, source filtering, unauthorized tool calls, malformed parameters, policy changes during a task, and a browser page that contains adversarial instructions. Test a partial execution and a retry after a network failure. The expected result should show that the system knows whether an action happened, prevents duplicate effects, and preserves enough evidence for a reviewer to decide the next step.

Evaluation and release checklist

Start with a written threat and data-flow review for the workflow, including which service stores data and for how long. Use synthetic fixtures to test retrieval, tool authorization, session isolation, and observability before connecting production records. Define rejection criteria such as an uncited answer, a tool call outside the allowlist, a missing audit event, or a state-changing action without an approval token. Test them; do not assume a managed platform prevents them.

For a limited release, use a small audience, read-only or reversible actions, rollback, and an incident owner. Capture configuration versions and test results so upgrades can be compared with the prior setup. Check current AWS documentation for service availability, supported regions, limits, and upgrade behavior. Tie each expansion in access to the workflow's acceptance checks, and retain the configuration and evidence from the previous release for comparison.

Related capabilities

• SI infrastructure development