OpenAI Agents API vs LangGraph vs AWS AgentCore: What Should You Actually Run Yourself?

A coding agent changes a downstream timeout in a Java service from 250 to 400 milliseconds. It runs the tests, prepares a canary, and asks a release owner for approval. The owner comes back forty minutes later. By then, the agent's worker has restarted and another engineer has pushed a new commit to the same branch.

The saved conversation still says the change passed verification. If the system now tells the agent to continue, which build will it deploy? The one tested forty minutes ago, or whatever the branch points to now? And if the deployment controller accepts the canary request but the network response disappears, which component knows whether to retry?

This is a useful way to compare OpenAI Agents API, LangGraph, and Amazon Bedrock AgentCore. All three can take part in this workflow, but they manage different kinds of work. One can supply a managed coding-agent loop, another can express a durable process in application code, and another can host the execution environment. Those responsibilities sometimes overlap, and the products can also run together.

The important choice is how much of the agent loop, workflow persistence, and compute infrastructure your team wants to own. The release itself gives us a way to test whether that choice works when a process disappears, an approval arrives late, or an external action finishes without sending a response.

The products are not at the same layer#Copy link

Start by separating the thing that chooses the next tool from the thing that remembers the business process, and from the computer that runs the tool. A team can buy one of those and build the other two. It can also buy several without making them one system.

The last option is important, but its status matters. As of October 29, 2026, OpenAI's Agents API is in public beta, AWS AgentCore Harness is generally available, and Bedrock Managed Agents powered by OpenAI remains in public preview. The Bedrock preview documents a narrower surface, including no subagents and no programmatic tool calling or code mode in its supported workflow. AWS can run the Codex harness, but that does not mean every capability in the OpenAI-hosted service is available through the preview. OpenAI's launch, AgentCore Harness availability, and Bedrock preview limitations are the source documents for these distinctions.

LangGraph is not necessarily self-hosted. LangSmith Deployment has cloud, hybrid, and self-hosted options and can serve frameworks other than LangGraph. Likewise, you can run LangGraph or the OpenAI Agents SDK on AgentCore Runtime. A company already using one framework may need secure compute rather than another agent framework.

The release has to identify what actually passed verification#Copy link

Our agent is supposed to inspect the timeout configuration, look for another timeout in the client library, propose a patch, and run the team's established integration suite. Only then can a human authorize a five-percent canary in a particular production region.

A branch name cannot serve as the approval target because it can move. Even an artifact digest alone is insufficient. It tells us which bytes are involved, not whether those bytes came from a trusted build or passed the required tests.

I would have the release service maintain an immutable release attempt, with a unique ID for each candidate and proposed rollout. A new candidate or a new rollout plan creates a new attempt rather than rewriting the identity of the old one.

release_attempt_id: rel-2048-attempt-03
repository: checkout-api
source_commit: 7a19b0c
candidate_artifact_digest: sha256:a91...   # Abbreviated
ci_evidence_id: ci-run-5482
ci_evidence_digest: sha256:44c...
verification_status: VERIFIED
rollout_plan_digest: sha256:31f...
target: checkout-api/prod/eu-west
approval_status: AWAITING_APPROVAL
operation_id: null

These are illustrative application fields, not the schema of any vendor. The CI system, rather than the model, must attest what it built and tested. An evidence record should bind the source commit, output artifact digest, required test suite, result, and relevant build environment. The release service should retrieve that record from an approved CI identity or verify signed provenance against an approved builder. A JSON file written by the agent with tests_passed: true would not be sufficient.

The provenance check still requires judgment. A genuine CI run can execute the wrong suite. A passing test may not cover the timeout behavior under load. The release policy needs to say which evidence qualifies this kind of change for a five-percent canary. The model can analyze the test output and propose a plan, but it cannot make an untrusted test report authoritative by summarizing it.

Once the artifact and plan are fixed, the approver reviews that exact pair. If the branch advances and produces a different artifact before approval arrives, the new artifact needs its own verification and approval. The old approval may still permit the originally tested candidate if rollout preconditions remain valid. That is a business policy decision, not a question for the agent's saved chat history.

The release record is useful even if you later replace the agent platform. It is the one object that represents the work the product promised to do.

OpenAI Agents API when the investigation itself is difficult#Copy link

OpenAI Agents API offers a managed Codex harness. The harness handles the model and tool loop, session state, context compaction, subagents, and recovery. In the release example, that is valuable during the uncertain part of the task. The agent may need to find the timeout in several libraries, reproduce a failing test, inspect commit history, and decide which additional evidence to collect.

The execution environment is configurable. With an OpenAI-hosted sandbox, OpenAI runs the harness and provides the computer where commands execute. With a self-hosted sandbox, a codex exec-server in your environment connects out to the managed service. Your team operates that sandbox and controls its local filesystem and network access. The harness remains an OpenAI-managed service. A self-hosted sandbox is not equivalent to running the entire agent stack privately. An agent that only calls remote tools may not need a sandbox at all. OpenAI's architecture guide describes these arrangements.

For our service, the agent could call a prepare_release_candidate tool with a pinned source revision and patch. The application tool validates repository permissions and requests a trusted CI build. It returns a release-attempt reference and an evidence status. There is no reason to put a production deployment credential in the coding sandbox.

The managed session may last across many turns, and the application can recover saved items after a stream disconnects. The precise event matters, though. The documentation says an idle session means it can accept input, not that the previous turn completed successfully. A completed turn can still contain failed tool work. The application should inspect the actual items and evidence rather than promote an idle or completed event into a release status.

OpenAI also documents an Idempotency-Key on session-message submission. If the application times out while sending the same logical message, it can retry with the same key and session ID. That protects against duplicating an input submission. It does not deduplicate deployment operations performed by an external controller. The sessions guide makes that retry scope explicit.

A material constraint belongs in the decision before any performance testing. OpenAI currently documents US-only data residency and no Zero Data Retention support for Agents API, including when the execution sandbox is self-hosted. If the workload cannot send the relevant source, prompt, or session information through that data boundary, the managed service may not be eligible, regardless of how good the harness is. Agents API data controls should be checked again when deployment is planned.

For a coding-heavy product whose hardest work is investigation and tool use, I would test the Agents API early. It is less attractive as the sole owner of a fixed release process with multiple external approvals and audit requirements. That process can surround the managed harness as ordinary application code or run in a separate workflow engine.

LangGraph when the process itself needs explicit control#Copy link

LangGraph makes the workflow part of the application implementation. You can define a node for investigation, another for trusted verification, another for the approval wait, and a final node that requests a release through a restricted service. A node may contain a model-driven loop, but the graph's decision to advance from verification to approval can be deterministic.

For this example, a graph might have the following outline:

inspect_code -> propose_candidate -> trusted_ci_verification
                                      |             |
                                   failed        verified
                                      |             |
                                   revise     await_approval
                                                    |
                                             denied / approved
                                                |        |
                                               stop   request_canary
                                                          |
                                                  reconcile_controller

This is not executable LangGraph syntax. Its value is that the allowed transitions are visible in code. An approval receipt must match the verified release attempt before the execution node is enabled. A model cannot just output approved: true and cause the graph to jump ahead.

LangGraph stores graph state through a checkpointer and uses a thread_id to locate it. An interrupt() can pause a thread for human input, then resume through Command(resume=...). There is a detail that can surprise teams coming from ordinary coroutine code. LangGraph documents that the interrupted node restarts from its beginning on resume. If that node sent the approval notification before calling interrupt(), the notification may be sent again. Separate the side effect from the pause, or put it behind an idempotent receiver. LangGraph interrupts explains this replay behavior.

Checkpoint durability also changes the failure contract. The documented sync mode persists before the next step, while async can permit some exposure to a process crash and exit does not preserve intermediate progress against a mid-run failure. An in-memory checkpointer is unsuitable if restarting the process must preserve pending approvals. The correct choice depends on the consequences of replay and on the external records the application already maintains. Persistence and durability modes describe these options.

A paused thread is also a versioning obligation. If the team deploys a new graph with different node names or state fields while approval is pending, it needs a migration strategy for older threads. Retaining the old graph version until its outstanding work finishes may be safer than attempting to resume every checkpoint against the newest graph definition.

LangGraph itself is a framework, not a mandatory invitation to run Kubernetes. LangSmith Deployment can provide durable serving and scaling, in managed, hybrid, and self-hosted configurations. It can host several agent frameworks, not only LangGraph. If the company already owns Temporal, Step Functions, or another reliable workflow system for approvals and canaries, I would first put the model-driven code inside one of its activities. Adding LangGraph to reimplement an existing release state machine could create two recovery systems with overlapping authority. LangSmith Deployment makes the serving options explicit.

AgentCore when the missing piece is compute, or an AWS-managed loop#Copy link

AgentCore Runtime addresses the compute problem. It hosts your packaged agent code in managed execution sessions with isolation, networking, and lifecycle facilities. The framework can be LangGraph, the OpenAI Agents SDK, Strands, or something you wrote yourself. Runtime does not, by itself, choose which tools the agent should call or provide your release state machine.

AgentCore Harness is a different AWS product. It provides a managed Strands-based model and tool loop running on AgentCore Runtime. The team configures models, tools, instructions, skills, and limits instead of maintaining the loop directly. AWS documents a way to export Harness configuration as editable Strands Python code. This is helpful if a prototype later needs custom orchestration, but it does not transfer an in-progress managed session and all pending effects into a new runtime automatically. AWS's Harness and Runtime comparison and export documentation are specific about these differences.

The AWS runtime session ID also deserves care. With the default microVM configuration, the idle timeout is 15 minutes and the maximum compute lifetime is eight hours. AWS documents that the logical session can continue after the microVM is replaced. It does not follow that a Python variable or unpersisted local file survived that replacement. Persistent files require the appropriate storage configuration, while business approvals need their own durable record. Instances provide a different compute option with supported lifetimes up to fourteen days. AgentCore lifecycle settings describes those bounds.

The isolation story has a qualification that should matter to anyone executing repository code. AWS says application backends must enforce user-to-session mapping. It also documents that code inside a Runtime microVM can access its execution-role credentials through the metadata endpoint. A broad role attached to an untrusted coding sandbox is dangerous even if each session has its own microVM. The role should be tightly scoped, and production deployment should sit behind a separate action service that checks the intended release. AgentCore security guidance states these responsibilities directly.

There is also Bedrock Managed Agents powered by OpenAI. This is not AgentCore Harness with a different model. It uses a Codex-based managed loop with the model interaction on Bedrock and tool execution on customer-provided compute, including AgentCore Runtime. In its current public preview, the available features and regions are narrower than the OpenAI-hosted Agents API. In particular, the documented preview does not support subagents or programmatic tool calling. It should be evaluated for the workflow it supports today, not the feature set a similarly named harness offers elsewhere.

For a company already committed to AWS and satisfied with its own model loop, Runtime is often the direct option to test. If it wants the loop managed, Harness is an additional choice. Whether the OpenAI-powered Bedrock preview is eligible is a separate maturity, region, and feature decision.

The canary request disappears after the controller accepts it#Copy link

The agent has now produced a tested artifact, sha256:a91..., and the release owner has approved a five-percent canary in eu-west. A new branch commit exists, but the approval is only for a91. The release service checks that the approved operation still satisfies the deployment policy, including the target, test evidence, plan, and permitted time window.

The approval should identify one immutable release attempt and one canonical action name. Using START_CANARY_5_PERCENT everywhere avoids a subtle failure in which the approval authorizes a five-percent rollout but the executor matches a broader start_canary permission.

approval_id: appr-592
release_attempt_id: rel-2048-attempt-03
artifact_digest: sha256:a91...
ci_evidence_digest: sha256:44c...
rollout_plan_digest: sha256:31f...
target: checkout-api/prod/eu-west
action: START_CANARY_5_PERCENT
approved_by: release-owner-17
expires_at: 2026-10-29T02:00:00Z

Suppose approval is received twice because an event was retried. It should not produce two canaries. Nor should a new candidate reuse this release attempt. At the creation of the approved operation, the application locks the immutable attempt, validates the trusted CI evidence and approval receipt, then inserts an operation and a database outbox row in the same transaction.

# Application pseudocode. The database methods are illustrative.
with db.transaction() as tx:
    attempt = tx.lock_attempt("rel-2048-attempt-03")
    approval = tx.load_approval(attempt.approval_id)
    evidence = tx.load_trusted_ci_evidence(attempt.ci_evidence_id)

    require_matching_artifact_and_plan(attempt, approval, evidence)
    key = (attempt.id, "START_CANARY_5_PERCENT")
    operation = tx.find_operation_by_key(key)
    if operation is None:
        require_authorized_approval(approval, attempt, "START_CANARY_5_PERCENT")
        require_unexpired_and_current_policy(approval, attempt)
        operation = tx.insert_operation(
            unique_key=key,
            artifact_digest=attempt.artifact_digest,
            rollout_plan_digest=attempt.rollout_plan_digest,
            target=attempt.target,
            state="PREPARED",
        )
        tx.insert_outbox_row(operation.id, "REQUEST_CANARY")
    else:
        require_identical_operation_payload(operation, attempt)

The operation key is unique for the immutable release attempt and action. Replaying the approval event finds the existing operation and verifies its payload, even if the original approval has since expired. That replay does not grant authority for a new operation. A newly reviewed artifact or a separately authorized second attempt receives a new attempt ID. The database unique constraint must also prevent two concurrent callbacks from inserting operations with the same key. The application must reject a conflicting payload rather than silently attach new parameters to the original operation.

tx.insert_outbox_row is a database insert, not a call to SQS, Kafka, or the deployment controller. The database commits the operation and the outbox row atomically. A separate dispatcher reads committed outbox rows and sends requests. It can crash after sending, which means at-least-once delivery is possible. The deployment controller should deduplicate by the stable operation ID or provide a trustworthy status lookup under that ID.

I would use an explicit operation lifecycle in the release service:

PREPARED -> DISPATCHED -> ACCEPTED -> RUNNING -> VERIFIED
                |             |          |
                +-------------+----------+-> FAILED
                +-------------+----------+-> UNKNOWN

The states mean different things. DISPATCHED says a request was attempted. ACCEPTED means the controller acknowledged it. VERIFIED requires the expected canary and health outcome to be confirmed by the controller or another authoritative monitor. UNKNOWN means the application lacks enough evidence to claim either success or failure. Failed delivery is not automatically failed deployment.

Now let the controller accept op-781 but drop the network response. The dispatcher must not generate a new logical canary merely because it timed out. It queries the controller using op-781. If the controller recognizes that operation and reports it running, the release service records that state and continues verification. If the controller cannot establish whether the request was accepted and does not offer deduplication, the outcome may remain unknown and require manual reconciliation.

Time-sensitive policy needs a separate decision when an approved request has waited in the outbox. Before a previously unsent operation is first dispatched, the system should enforce the agreed validity rules. Once the controller has accepted it, expiring or revoking the approval does not erase the external change. Stopping or rolling back the canary becomes a new controlled operation with its own status and evidence.

This is not a feature specific to OpenAI, LangGraph, or AWS. A managed session may recover the agent's conversation, LangGraph may recover the graph thread, and AgentCore may start a new compute environment. None substitutes for the operation record that tells the release service whether production changed.

The platform decision I would take into an architecture review#Copy link

The relevant selection criteria are not the number of built-in tools or how quickly a sample agent starts. They are where the non-negotiable boundaries sit, which software the team already operates, and how much control the workload needs over its execution and recovery.

The table is a starting point, not a universal answer. A LangGraph graph can run inside AgentCore Runtime. LangSmith Deployment can host more than LangGraph. A managed harness can be used for an open-ended investigation while a deterministic workflow system owns the release approval. These are combinations with clear boundaries, not redundant stacks by default.

There is also a maturity decision. OpenAI Agents API is in public beta, AgentCore Harness is generally available, and the Bedrock/OpenAI offering is in preview as of this review. An eligible production choice depends on the provider's actual region, retention, quota, support, and feature commitments. A beta service that works well for an internal coding assistant is not automatically acceptable for a regulated rollout controller. A generally available service still requires an application security review.

Portability is mainly about recoverable application milestones#Copy link

An OpenAI Agents API session ID, a LangGraph thread ID, and an AgentCore runtime session ID are not interchangeable. A transcript export does not reproduce another framework's checkpoint or compaction history. Changing SDK method names in an adapter also does not make a paused workflow portable.

Instead, keep the durable release attempt, trusted CI evidence, approval, operation identity, and controller receipts outside the agent provider. Record the provider session or thread alongside the application attempt so traces can be joined when investigating a failure.

If the team later replaces the managed harness or graph framework, the safest approach is usually to let old attempts complete where they started and route new work to the replacement. For an interrupted release, restart at a verified application milestone such as AWAITING_APPROVAL, using the immutable artifact and evidence already stored. The new agent may investigate an unresolved question, but it should not be asked to reconstruct authority from a previous provider's free-text reasoning trace.

This is less ambitious than pretending every agent session can be moved live between vendors. It is also a migration design an operations team can test and explain.

How I would compare the options before buying one#Copy link

A single scripted demo is a poor platform benchmark. It mostly measures whether the selected agent can solve that one task under favorable conditions. I would test each candidate on pinned repositories and a fixed acceptance suite that covers code investigation, trusted build verification, delayed approval, an execution request whose reply is lost, tenant isolation, and a canary that must stop when its metrics deteriorate.

There should be two experiments. First, a controlled architecture comparison that holds task inputs, tools, model pool, inference budget, and evaluation criteria as close as practical. Managed harnesses cannot always be made behaviorally identical, so document what cannot be controlled, especially context compaction, built-in tools, and retry policy. The result shows the behavior of the whole configuration, not a pure causal effect of one framework name.

The second experiment is the purchasing decision. Let each candidate use its realistic model mix, managed deployment, and infrastructure configuration. Measure cost and latency per verified accepted release, including failed attempts, retries, storage, tracing, CI, human review, repair, and the engineering effort required to operate the platform. Total all those costs across the trial and divide by the number of verified accepted releases, not by the number of agent turns. An AWS-hosted agent and a managed OpenAI harness may have very different cost structures even at the same total token count.

A small acceptance matrix makes the reliability threshold explicit:

Report acceptance rates with uncertainty, cost per accepted outcome, p95 and p99 elapsed time, unknown external outcomes, unauthorized operations blocked, and human repair effort. If the provider tracing cannot be joined to a release attempt and its controller receipt, the application will be difficult to debug regardless of which platform won the benchmark.

I would not buy a new orchestration layer merely because it can resume an agent conversation. For this release workflow, the coding investigation is open-ended, while the approval and deployment steps are intentionally constrained. One reasonable design is a managed harness for the investigation and a durable release service for the consequential transitions. Another is a LangGraph-based orchestration when the team really needs the graph to be the workflow implementation. AgentCore Runtime can host the chosen code if AWS-managed execution is the missing capability.

The decision becomes much easier once the team can show the exact artifact it approves, the external operation it can safely retry, and the business record it can recover after everything else has restarted. Those are the details I would want to see in an architecture review before debating which agent platform has the best developer experience.

For deeper discussion of the model and tool loop, see How Coding Agents Actually Work: Inside the Agent Harness. The separate problem of durable external effects is covered in Designing Long-Running AI Agents That Survive Failures. The Applied AI Engineering Cohort examines these implementation decisions in more detail.

Primary references#Copy link

• OpenAI, Introducing the Agents API, September 2026
• OpenAI, Agents API overview and data controls
• OpenAI, Agents API sessions and message idempotency
• OpenAI, Agents API architecture
• LangGraph, interrupts and restart behavior
• LangGraph, persistence and checkpointers
• LangSmith Deployment environments
• AWS, AgentCore Harness vs Runtime
• AWS, AgentCore Runtime lifecycle
• AWS, AgentCore Runtime security best practices
• AWS, Bedrock Managed Agents powered by OpenAI
• AWS, Bedrock Managed Agents preview limitations