NEW DELHI, September 30, 2026, 5:00 PM IST — Amazon Web Services and OpenAI have put the Codex agent harness inside a managed Amazon Bedrock service, giving enterprises a way to run long-lived AI agents with AWS identities, isolated execution environments and cloud-native observability.
The preview, called Amazon Bedrock Managed Agents powered by OpenAI, moves more of the agent control plane into infrastructure that platform teams already operate. The model loop, session state and context compaction are managed by the service, while commands and file operations run in an environment chosen by the customer.
That division matters as companies move from short chatbot exchanges to agents that keep context, use tools and work across multiple steps. For DevOps and cloud teams, the difficult questions are increasingly about execution identity, network reach, persistent state, audit evidence and cost—not only model quality.
What AWS and OpenAI announced
OpenAI listed Bedrock Managed Agents among more than 20 updates at its DevDay conference on Tuesday. The company said the service takes core capabilities from its Agents API and adapts them to run natively with AWS resources. AWS describes the preview as a joint product that combines OpenAI models and the Codex harness with Amazon Bedrock AgentCore.
The Codex harness runs the loop between the model and tools, maintains the session and compacts context as it grows. According to the AWS implementation guide, commands and file work can execute locally during development or in AgentCore Runtime inside the customer’s AWS account.
Each AgentCore Runtime session receives its own microVM and runs under a customer-controlled execution role. Teams can connect the runtime to a VPC for private-resource access, and model calls remain in Bedrock Managed Agents rather than inside the command-execution container. AWS says the agent runtime and model inference remain within AWS.
The service is in preview, and AWS warns that its features and APIs can change before general availability. The current quick-start uses the OpenAI GPT-5.6 Luna model, requires AWS credentials and IAM permissions, and deploys a container image through AWS CodeBuild.
How the execution boundary works
The important architectural split is between reasoning and action. Bedrock Managed Agents decides when the agent should call a tool or issue a command. AgentCore Runtime performs that work inside the customer environment, where IAM, VPC routing and security groups can constrain what the session reaches.
The default runtime configuration in AWS documentation has a 30-minute idle timeout and an eight-hour maximum lifetime. Teams can add session storage when files and agent state must survive an idle stop. They can also package reusable skills inside the runtime image or mount skills from an S3 Files access point when a VPC-connected deployment needs centrally updated procedures.
Observability uses OpenTelemetry components in the runtime image and sends logs and spans to Amazon CloudWatch. AWS says each call to the lifecycle server creates an invocation span, with generative-AI traces appearing in CloudWatch after processing. That gives operators a native place to inspect runs, although the usefulness of those traces will depend on retention, redaction and alerting policies configured by each customer.
OpenAI’s DevDay recap also says the broader Agents API now supports computer use, multi-agent work, tool search, tool calling and context compaction. Bedrock Managed Agents is the AWS-native path for teams that want those agent patterns tied to AWS identity and runtime controls.
What platform teams should verify before adoption
The first review should focus on the execution role. A separate identity per agent is useful only when policies stay narrow. Teams should avoid broad account permissions, scope resource access to specific projects and test denied actions as deliberately as successful ones. The runtime invocation permission and the runtime’s own execution role are separate controls and should be reviewed independently.
Network design is the next control point. A VPC-connected agent may reach private services that are invisible from the public internet, so security groups, routes and private endpoints become part of the agent’s effective authority. Build steps may still need internet access to download dependencies, which means build-time egress should not automatically become runtime egress.
Persistence also changes the incident model. Session storage helps an agent resume long work, but it can retain generated files, connection state and local context. Teams should define lifecycle rules, encryption, backup expectations and deletion procedures before using persistent workspaces with sensitive repositories or operational data.
Costs require their own controls. AWS documentation notes that AgentCore Runtime, CodeBuild image builds and model calls can all incur charges. Long-running agents should therefore have idle limits, maximum lifetimes, per-project budgets and alerts tied to useful work rather than raw token volume. GravityDevOps’ LLMOps guide provides a broader framework for evaluating model operations, while the CI/CD tools comparison can help teams place policy checks and runtime-image validation into delivery pipelines.
Preview status limits the immediate conclusion
AWS and OpenAI are reducing the amount of infrastructure a team must assemble to run a persistent agent, but “managed” does not remove operational responsibility. Customers still control the execution role, network path, skills, storage and much of the telemetry policy. A permissive role or exposed private service remains dangerous even when the agent loop itself is managed.
The companies have not published independent production benchmarks for reliability, isolation or cost at scale. AWS says each session receives its own microVM and that inference stays inside AWS, but prospective users should validate regional availability, quotas, failure recovery, data handling and audit coverage against their own requirements before moving sensitive work into the preview.
The practical significance is that agent platforms are converging with ordinary cloud operations. Model choice remains important, but production readiness increasingly depends on the same controls used for other workloads: least-privilege identity, isolated compute, private networking, observable execution and disciplined lifecycle management.
Sources
OpenAI, DevDay 2026 recap; Amazon Web Services, Amazon Bedrock Managed Agents product page; AWS Documentation, Bedrock Managed Agents with OpenAI implementation guide; and Axios, independent DevDay coverage.
