A managed agent service, not another model listing
Amazon Bedrock Managed Agents, powered by OpenAI, is available in public preview. AWS announced the service on 29 September as a jointly developed way to run stateful agents using OpenAI models inside AWS. Its scope is broader than choosing a model in the Bedrock catalogue. The service manages a conversation across multiple steps, coordinates tool use and preserves intermediate work, while the customer supplies an execution environment where commands and local tools run.
The launch matters because many agent pilots fail at the point where a useful demonstration becomes a governable service. A production team needs to know where state lives, which identity authorises a call, how a tool is connected, and when a person must approve a consequential action. AWS is offering those concerns as part of a defined platform architecture rather than leaving every customer to assemble an orchestration layer from scratch.
How sessions and execution fit together
AWS documentation describes a session as a stateful conversation that specifies the model, instructions, tools, IAM role and execution environment. A turn is the work triggered by a message and may contain reasoning, tool calls and output. The service keeps conversation context, while an exec server connects the customer-provided compute environment back to Bedrock Managed Agents. Customers may use their own host or Amazon Bedrock AgentCore Runtime.
That separation is operationally important. A service-managed conversation and files in the execution environment have different lifecycles. AWS explicitly notes that deleting a session does not delete files stored in a customer S3 bucket or host. Anyone building a document-processing or code-generation workflow should therefore define retention and cleanup for both state and output files. The preview does not make those governance questions disappear; it makes their boundaries clearer.
Skills, tools and approvals
The service supports reusable skills for specialised procedures and Model Context Protocol servers for additional tools. AWS says an agent can preserve messages, tool calls and intermediate results so that a user can return later and continue. That is especially useful for codebase investigations, multi-document work and file generation, where a single chat response is not the right unit of work.
Each agent uses its own IAM role, according to AWS, and the platform supports human approval before consequential actions. Supported API activity is recorded with AWS CloudTrail. These are substantial controls, but their value depends on configuration. Giving a role broad access or making an approval gate too permissive would undermine the design. A pilot should test denied operations, interrupted sessions and recovery paths as well as successful happy-path work.
Where the preview can run
Bedrock Managed Agents is available in public preview in US East (N. Virginia), US West (Oregon) and US East (Ohio). AWS documentation says session operations use the bedrock-mantle endpoint, while model availability can vary by region and account. Organisations with Australian data-residency requirements should not mistake a service’s AWS branding for local Australian availability. They need to assess whether a US-region preview is suitable for the data and workloads in question.
AWS provides two execution approaches. Self-hosted compute suits a team that already controls a development machine, container or other host and can run the exec server. AgentCore Runtime offers managed runtime sessions and configurable storage in an AWS account. Neither is a zero-configuration choice: the self-hosted option needs host and network management, while the AgentCore example creates storage and networking resources.
Preview economics and sensible first tests
AWS says there is no separate Bedrock Managed Agents charge during preview beyond the underlying resources consumed, and warns that pricing can change at general availability. Model inference, runtime and other AWS resources still incur charges. Its documentation highlights that an example AgentCore deployment can include a NAT gateway and continue costing money even when no agent turn is running. Cost reviews therefore need to cover idle infrastructure, not only model tokens.
The immediate opportunity is a bounded, measurable trial of a stateful workflow: for example, investigating a repository with a limited IAM role, a small tool set and an explicit approval step before any write. Teams should record completion quality, human intervention, latency, total resource cost and security events. AWS and OpenAI have introduced a potentially useful managed path for agent deployment, but the public-preview label means APIs and behaviour may change. Production decisions should follow observed results rather than the announcement alone.
One useful procurement question is what the service manages versus what the customer must operate. AWS handles the agent conversation and model interactions, but tools execute on customer-provided compute. That means the customer remains responsible for patching a self-hosted machine, configuring runtime networking and protecting any files produced by the agent. A managed orchestration service can reduce application work without transferring all operational accountability to the provider. Writing down that shared-responsibility boundary early will make both security review and cost estimates more credible.