OpenMA now supports the OpenAI Agents API

You can now point the official OpenAI SDK at an OpenMA Node server and run agents on infrastructure you control. This release adds the OpenAI Agents API at /openai/v1, with durable sessions, client function tools, subagents, live streaming, and file artifacts.

The Claude-compatible API remains available at /v1 on Node and Cloudflare. Both contracts use OpenMA’s existing session infrastructure. You bring the model credentials, choose the runtime, and keep the conversation history and outputs in your own deployment.

The initial OpenAI compatibility baseline is openai@7.15.0. The endpoint is available on Node today, with specific execution limits described below.

Start with the SDK you already use

Start a Node + Docker deployment, create an API key in its Console, and add a Model Card with your provider credentials. Then install the pinned SDK in your application:

npm install openai@7.15.0

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.OPENMA_API_KEY,
  baseURL: "http://localhost:8787/openai/v1",
});

const events = await client.beta.agents.sessions.create({
  agent: {
    model: "your-configured-model",
    instructions: "Be concise and explain your conclusions.",
  },
  environment: { type: "none" },
  input: "Explain when a background task needs durable state.",
  stream: true,
});

for await (const event of events) {
  console.log(event);
}

The client API key authenticates to OpenMA. The Model Card provides the upstream model key. Using the OpenAI API contract does not require every session to use an OpenAI model: execution uses the model configured in your OpenMA deployment.

This example selects environment: { type: "none" }, so text and client function tools can run without provisioning a physical sandbox. Code execution and environment files need a connected sandbox. The SDK guide walks through both the request contract and the current runtime boundaries.

A session can outlive your connection

Consider an agent that needs your application to look up an order. It emits a function call, pauses, and waits for a result. Your service might restart before that lookup finishes. A useful agent platform needs to retain exactly which call is pending and where its result belongs.

OpenMA persists the pending action in the session’s native history. After a Node restart with storage retained, your application can retrieve the session, submit the result with the original call and turn identifiers, and continue the same unfinished turn. An accepted input retried with the same idempotency key and payload is not dispatched again. Reusing that key for different input returns a conflict.

That gives an application a durable place to reconnect to. Your own external function side effects still need idempotency, just as they would in any background job system.

Streaming follows the same separation between execution and observation. Disconnecting from SSE stops listening; it does not cancel the agent. To stop execution, send an explicit cancellation event. If you reconnect after missing output, read the durable Items and Turns and subscribe to new events. The pinned OpenAI stream is live-only, so clients should not expect it to replay everything they missed.

Delegate work and keep the child conversations

Enable agent.multi_agent.enabled and the main agent can delegate subtasks. It receives controls to create a child, send input, wait, interrupt, close, and resume it. Each child keeps its own conversation history and shares the parent’s files when a sandbox is connected.

For example, a coordinator can ask one child to investigate an implementation and another to examine its tests. When they finish, it can ask a follow-up in the same child conversation instead of starting from scratch. The API exposes child Items and Turns so an application can show those histories separately.

The current execution baseline is single-level delegation. The main agent can create children; children do not receive tools to create further children. They inherit MCP and search configuration, while client function tools remain on the main agent. A completed child turn leaves that child available for further work; closing it is a separate lifecycle action.

Keep the files that matter

When an agent runs in a connected environment, file operations reach the real sandbox. Outputs written under /workspace/outputs are published as immutable Artifacts after the corresponding root turn completes successfully. You can list, retrieve, download, and delete those artifacts through the SDK.

An artifact records the session, environment, turn, and path it came from. This lets an application associate a generated report or patch with the work that produced it, even after the sandbox has gone away. Ordinary uploaded files do not automatically become artifacts, and publication happens after execution completion as its own persistence step.

The environment type name openai_hosted belongs to the API contract. With OpenMA, the environment is still supplied by your configured runtime; it is not a request to execute on OpenAI’s hosted service.

Two APIs, one durable history

The implementation translates the OpenAI contract onto OpenMA’s existing application services. Saved agents use native agent records. Credentials use the existing encrypted vault services. Artifacts use native immutable files. Sessions, Turns, Items, and required actions are reconstructed from ordered, committed session facts.

This matters when something goes wrong. There is one authoritative history behind execution and the API views, so a process restart does not require reconciling a second set of OpenAI-specific conversation tables. Child histories use native session threads, and initial input is admitted through the durable execution outbox.

These changes sit alongside the recent work on execution leases, managed resource preparation, sandboxed ACP harnesses, and persistent memory. They extend the platform’s shared execution machinery. The OpenAI adapter does not yet expose every capability available through the native API.

What this release covers

The release has maintained tests using the official SDK against the production Node service, real SQL persistence, and a controlled local model server. They exercise resource persistence, function continuation, child controls, restart recovery, streaming, and cancellation. Separate contract tests cover SDK requests, HTTP responses, and history projection.

That evidence has a specific scope. It does not certify every live model or physical sandbox provider, and broad HTTP coverage does not mean every saved configuration can execute today.

The current limits are:

• Node only. The OpenAI endpoint is not mounted on the Cloudflare host.
• Advanced environment configuration is incomplete. Packages, setup, environment variables, input-file injection, plugins, skills, capability directories, and restricted networking are not wired through this adapter.
• Some model and tool options are incomplete. Explicit reasoning controls, fast service tier, structured output, deferred tools, and advanced MCP configuration are not yet supported on this execution path.
• Delegation is one level deep. Recursive child execution is outside this release’s baseline.

Unsupported execution settings are rejected when creating a session. Saving an agent or environment template does not imply that the selected runtime can enact every option. The compatibility guide has the detailed list.

Try it on your own server

Follow the Node deployment guide, then use the OpenAI Agents API quickstart. The source and test suites are available under Apache 2.0.

If you already use OpenMA’s Claude-compatible API, your existing endpoint remains available. For an application built around the OpenAI Agents contract, there is now another way to run it: with OpenMA owning the durable execution and your deployment owning the infrastructure.

For the product thinking behind this work, read Why Agent as a Service: what changes when a team can hand an agent an ongoing assignment.