---
title: OpenAI Agents
description: Test OpenAI Agents with tools, handoffs, sessions, sandbox workflows, and tracing in promptfoo.
keywords:
  [
    openai agents,
    multi-turn workflows,
    agent tools,
    agent handoffs,
    agentic systems,
    function calling,
    opentelemetry tracing,
  ]
sidebar_label: OpenAI Agents
---

# OpenAI Agents

Test multi-turn agentic workflows built with the [@openai/agents](https://github.com/openai/openai-agents-js) SDK. Evaluate agents that use tools, persist session history, hand off between specialists, or run inside the SDK's sandbox runtime.

:::note
This page covers the JavaScript `@openai/agents` SDK and the built-in `openai:agents:*` provider.

If you are using the Python `openai-agents` SDK, use the [OpenAI Agents Python SDK guide](/docs/guides/evaluate-openai-agents-python) and the [`openai-agents` example](https://github.com/promptfoo/promptfoo/tree/main/examples/openai-agents) instead.
:::

## Prerequisites

- Install Promptfoo and the supported JavaScript SDK together: `npm install promptfoo @openai/agents@^0.14.1`
- Set `OPENAI_API_KEY` environment variable
- Agent definition (inline or in a TypeScript/JavaScript file)

The SDK is an optional peer and is not installed by default. Use the project-local `npx promptfoo` command for file-exported agents so Promptfoo and the agent share the same SDK installation. An incompatible SDK in your project does not prevent ordinary Promptfoo evals; selecting `openai:agents:*` checks compatibility.

For inline agents, a global installation is also supported:

```bash
npm install -g promptfoo @openai/agents@^0.14.1
```

For a one-off inline-agent eval, run this from an empty directory outside an existing npm project, using an absolute config path:

```bash
npx --yes --package=promptfoo --package=@openai/agents@^0.14.1 promptfoo eval -c /absolute/path/config.yaml --no-cache
```

## Basic Usage

```yaml
providers:
  - id: openai:agents:my-agent
    config:
      agent:
        name: Customer Support Agent
        model: gpt-6-luna
        instructions: You are a helpful customer support agent.
      maxTurns: 10
```

For repeatable eval baselines, set a model explicitly on the exported SDK agent or with
`config.model`. The SDK's fallback model can change between releases, so do not treat an
implicit default as a stable eval input.

## Configuration Options

| Parameter          | Description                                                                         | Default               |
| ------------------ | ----------------------------------------------------------------------------------- | --------------------- |
| `agent`            | Agent definition (inline object or `file://path`)                                   | -                     |
| `tools`            | Additional tool definitions (inline array or `file://path`)                         | -                     |
| `handoffs`         | Additional handoff definitions (inline array or `file://path`)                      | -                     |
| `maxTurns`         | Maximum conversation turns; set `null` to disable the SDK turn limit                | 10                    |
| `model`            | Override model specified in agent definition                                        | -                     |
| `modelSettings`    | SDK `ModelSettings` overrides, including reasoning, verbosity, and retry settings   | -                     |
| `inputGuardrails`  | Additional input guardrails (inline array or `file://`)                             | -                     |
| `outputGuardrails` | Additional output guardrails (inline array or `file://`)                            | -                     |
| `session`          | Persistent SDK session definition, instance, factory, or `file://` export           | -                     |
| `sandbox`          | Sandbox runtime config, local client definition, factory, or `file://` export       | -                     |
| `runOptions`       | Additional non-streaming SDK `run()` options such as `conversationId` or filters    | -                     |
| `executeTools`     | Execute function tools normally (`real`) or replace them with mocked results        | `real`                |
| `toolMocks`        | Mocked tool outputs keyed by tool name, used when `executeTools` is `mock` or false | -                     |
| `tracing`          | Enable Promptfoo OTLP export for SDK spans                                          | false                 |
| `otlpEndpoint`     | Custom OTLP endpoint URL for Promptfoo tracing                                      | http://localhost:4318 |

`config.model` and `config.modelSettings` are execution overrides. When present, each option
replaces the corresponding field on the initial agent and every handoff agent, including agents
loaded from a file. Omit either option to preserve that field from each agent definition.

Agents invoked independently by guardrails, tool callbacks, or `Agent.asTool()` keep their own
model and settings. Configure those agents directly when comparing models across a nested workflow.

## File-Based Configuration

Load agent and tools from external files:

```yaml
providers:
  - id: openai:agents:support-agent
    config:
      agent: file://./agents/support-agent.ts
      tools: file://./tools/support-tools.ts
      maxTurns: 15
      tracing: true
```

Top-level `tools`, `handoffs`, `inputGuardrails`, and `outputGuardrails` augment whatever is already defined on the loaded agent.

Any SDK `Tool` instance is accepted when it comes from a JavaScript/TypeScript file export. That includes function tools, hosted tools, `computerTool`, `shellTool`, and `applyPatchTool`. Inline YAML tool definitions are for function tools only.

Inline agent definitions follow the SDK `AgentOptions` surface for fields such as dynamic `instructions`, dynamic `prompt`, `handoffOutputTypeWarningEnabled`, `toolUseBehavior`, and `resetToolChoice`. Use a file-exported SDK agent when those options need executable code.

## Multimodal Input

If a rendered prompt is a JSON object or array that matches the SDK's `AgentInputItem` shape, Promptfoo passes it to `run()` as structured input instead of a plain string. This supports image, audio, and file inputs:

```yaml
prompts:
  - file://./prompts/vision-input.json

providers:
  - id: openai:agents:vision-agent
    config:
      agent: file://./agents/vision-agent.ts

tests:
  - vars:
      image: file://./images/cat.jpg
```

Example prompt file (`prompts/vision-input.json`):

```json
[
  {
    "role": "user",
    "content": [
      { "type": "input_text", "text": "What is in this image?" },
      { "type": "input_image", "image": "{{image}}" }
    ]
  }
]
```

Promptfoo resolves local image vars like `file://./images/cat.jpg` to data URLs before the prompt is passed to the SDK.

Arbitrary JSON prompts that do not match an agent input item are still sent as plain text.

**Example agent file (`agents/support-agent.ts`):**

```typescript
import { Agent } from '@openai/agents';

export default new Agent({
  name: 'Support Agent',
  model: 'gpt-6-luna',
  instructions: 'You are a helpful customer support agent.',
});
```

**Example tools file (`tools/support-tools.ts`):**

```typescript
import { tool } from '@openai/agents';
import { z } from 'zod';

export const lookupOrder = tool({
  name: 'lookup_order',
  description: 'Look up order status by order ID',
  parameters: z.object({
    order_id: z.string().describe('The order ID'),
  }),
  execute: async ({ order_id }) => {
    return { status: 'shipped', tracking: 'ABC123' };
  },
});

export default [lookupOrder];
```

## Agent Handoffs

Transfer conversations between specialized agents:

```yaml
providers:
  - id: openai:agents:triage
    config:
      agent:
        name: Triage Agent
        model: gpt-6-luna
        instructions: Route questions to the appropriate specialist.
      handoffs:
        - agent:
            name: Technical Support
            model: gpt-6-luna
            instructions: Handle technical troubleshooting.
          description: Transfer for technical issues
```

## Guardrails

Validate the initial agent input and final agent output with guardrails:

```yaml
providers:
  - id: openai:agents:secure-agent
    config:
      agent: file://./agents/secure-agent.ts
      inputGuardrails: file://./guardrails/input-guardrails.ts
      outputGuardrails: file://./guardrails/output-guardrails.ts
```

These OpenAI Agents SDK guardrails enforce the initial input and final output; tool guardrails are a separate SDK feature. In Promptfoo, a tripped SDK guardrail currently surfaces as a provider error, while a successful run does not populate the response used by Promptfoo's [`guardrails` assertion](/docs/configuration/expected-outputs/guardrails). Test the application behavior with ordinary assertions, or wrap the provider and normalize tripwires when you need the guardrail assertion.

See OpenAI's [guardrails and human review guide](https://developers.openai.com/api/docs/guides/agents/guardrails-approvals) for the SDK execution model.

## Sessions

OpenAI Agents SDK sessions keep conversation history across agent runs. Promptfoo supports the SDK session classes directly and also provides YAML-friendly shortcuts for the built-in session types:

```yaml
providers:
  - id: openai:agents:support-agent
    config:
      agent: file://./agents/support-agent.ts
      session:
        type: memory
        sessionId: support-demo
```

Supported inline session types are:

| Type                          | Use case                                                                 |
| ----------------------------- | ------------------------------------------------------------------------ |
| `memory`                      | Local in-memory demo or test session                                     |
| `openai-conversations`        | Server-managed OpenAI Conversations API history                          |
| `openai-responses-compaction` | Responses API history with automatic compaction over an underlying store |

For more control, export an SDK `Session` instance or a factory from a file:

```yaml
providers:
  - id: openai:agents:support-agent
    config:
      agent: file://./agents/support-agent.ts
      session: file://./sessions/support-session.ts
```

Inline session definitions and exported session instances stay attached to the provider for later turns. Export a factory when you want Promptfoo to create a fresh session for each call.

If you need the full `run()` surface, use `runOptions`. Promptfoo reserves `context`, `maxTurns`, `signal`, and streaming mode, but passes through the remaining non-streaming SDK options:

```yaml
providers:
  - id: openai:agents:support-agent
    config:
      agent: file://./agents/support-agent.ts
      runOptions:
        previousResponseId: resp_123
        conversationId: conv_123
        reasoningItemIdPolicy: omit
```

When an option needs executable code, such as `sessionInputCallback`, `callModelInputFilter`, `toolErrorFormatter`, or `errorHandlers`, point it at a `file://` export.

## Local Context

Promptfoo passes the current test vars into the SDK's local `context` object for each run. Tools and callbacks can read those values through `runContext.context`:

```typescript
export const lookupCustomerContext = tool({
  name: 'lookup_customer_context',
  description: 'Read the current customer tier from local run context.',
  parameters: z.object({}),
  execute: async (_args, runContext) => ({
    customer_tier: (runContext?.context as { customer_tier?: string }).customer_tier,
  }),
});
```

Use this for local application state that should be available to tools and hooks. It is separate from conversation history; use `session`, `conversationId`, or `previousResponseId` when you want to carry turns forward.

## Stateful Red Team Runs

Stateful red-team strategies such as [`crescendo`](/docs/red-team/strategies/multi-turn) and [`hydra`](/docs/red-team/strategies/hydra) need two things at once:

- all turns within one attack should share history
- separate tests should not share the same session

Use `transformVars` to stamp each test with a stable per-test session ID, then export a session factory that reuses sessions by that ID:

```yaml
providers:
  - id: openai:agents:support-agent
    config:
      agent: file://./agents/support-agent.ts
      session: file://./sessions/redteam-session.ts

defaultTest:
  options:
    transformVars: '{ ...vars, sessionId: context.uuid }'

redteam:
  strategies:
    - id: crescendo
      config:
        stateful: true
```

```typescript title="sessions/redteam-session.ts"
import { MemorySession } from '@openai/agents';

const sessions = new Map<string, MemorySession>();

export default async function createSession(context?: {
  vars?: {
    sessionId?: string;
  };
}) {
  const sessionId = context?.vars?.sessionId ?? 'default-session';
  const existing = sessions.get(sessionId);
  if (existing) {
    return existing;
  }

  const session = new MemorySession({ sessionId });
  sessions.set(sessionId, session);
  return session;
}
```

This keeps each multi-turn attack stateful while still isolating one generated test case from another. With Hydra, set `stateful: true` only after configuring this session factory so Hydra can send just the newest turn while the SDK session preserves earlier turns. The same pattern is useful for [`agentic:memory-poisoning`](/docs/red-team/plugins/memory-poisoning), which also depends on persistent state across turns.

## Sandbox Agents

`@openai/agents` v0.9 added beta `SandboxAgent` support in the JavaScript SDK. File-exported sandbox agents work with the same provider:

```typescript
import { Manifest, SandboxAgent, file } from '@openai/agents/sandbox';

export default new SandboxAgent({
  name: 'Workspace Assistant',
  instructions: 'Inspect the workspace before answering.',
  defaultManifest: new Manifest({
    entries: {
      'task.md': file({ content: 'Ticket PF-42: update the release note.' }),
    },
  }),
});
```

```yaml
providers:
  - id: openai:agents:workspace-agent
    config:
      agent: file://./agents/workspace-agent.ts
      sandbox:
        type: unix-local
      maxTurns: 12
```

Use `type: unix-local` for the SDK's local sandbox client or `type: docker` for the Docker client. You can also pass a full SDK `SandboxRunConfig`, a file export, or a factory if you need custom sessions, snapshots, manifests, or clients.

Inline agent definitions can opt into the sandbox runtime with `type: sandbox`, but file-exported SDK agents are the better fit once you need custom capability objects such as `skills()` or non-default manifests.

## Skills and Shell Tools

The JavaScript SDK exposes local skills through `shellTool` and sandbox capability objects. Because these require executable SDK objects, define them in TypeScript/JavaScript and load them from `file://` rather than trying to express them as YAML:

```typescript
import { shellTool } from '@openai/agents';

export default [
  shellTool({
    shell: myShellImplementation,
    environment: {
      type: 'local',
      skills: [
        {
          name: 'ticket-summary',
          description: 'Summarize ticket files',
          path: './skills/ticket-summary',
        },
      ],
    },
  }),
];
```

For `SandboxAgent` workflows, use the SDK's sandbox capability helpers in the exported agent file. Prefer an explicit capability list such as `shell()` plus `skills({ ... })` when you know the model only needs those tools; the SDK's broader default capability set can expose tools that a particular model does not support.

## Retry Policies

OpenAI Agents SDK v0.7 added opt-in retry settings on `modelSettings.retry`. Promptfoo supports YAML-friendly retry policy presets and passes them to the SDK as runtime callbacks.

```yaml
providers:
  - id: openai:agents:support-agent
    config:
      agent: file://./agents/support-agent.ts
      modelSettings:
        retry:
          maxRetries: 2
          backoff:
            initialDelayMs: 250
            maxDelayMs: 2000
            multiplier: 2
            jitter: true
          policy:
            any:
              - providerSuggested
              - httpStatus:
                  - 429
                  - 503
```

Supported preset policies are `never`, `providerSuggested`, `networkError`, and `retryAfter`.

You can also compose them with `any` or `all`. If you are configuring Promptfoo in TypeScript or JavaScript instead of YAML, you can pass SDK retry callbacks directly.

## Mock Tool Execution

Use mocked tool outputs for deterministic evals without executing function tools:

```yaml
providers:
  - id: openai:agents:support-agent
    config:
      agent: file://./agents/support-agent.ts
      tools: file://./tools/support-tools.ts
      executeTools: mock
      toolMocks:
        lookup_order:
          status: shipped
          tracking: ABC123
```

Mock mode supports function tools and direct `Agent` handoffs only. It fails closed for explicit
`Handoff` objects (their callbacks can have side effects), MCP servers, hosted tools, `SandboxAgent`
capabilities, reusable prompt templates, and model `providerData` that overrides the request's tools
or prompt. Use direct agents for handoffs with mocked tools. Lifecycle hooks can observe the
run, but cannot change the mocked tools or handoff configuration. Hooks and agent definitions
still run as trusted local code; mock mode does not isolate them.

## Tracing

Enable OpenTelemetry tracing to debug agent execution:

```yaml
providers:
  - id: openai:agents:my-agent
    config:
      agent: file://./agents/my-agent.ts
      tracing: true # Exports to http://localhost:4318
```

With a custom OTLP endpoint:

```yaml
providers:
  - id: openai:agents:my-agent
    config:
      agent: file://./agents/my-agent.ts
      tracing: true
      otlpEndpoint: https://otel-collector.example.com:4318
```

Or enable globally:

```bash
export PROMPTFOO_TRACING_ENABLED=true
npx promptfoo eval
```

Traces include agent execution spans, tool invocations, model calls, handoff events, token usage, and sandbox lifecycle spans. Promptfoo records the overall run as `invoke_agent` and normalizes Responses API model calls into `chat` spans with their model, token usage, and `openai.api.type: responses`. SDK tool spans become `tool.name`, `tool.arguments`, and `tool.output`, and sandbox command spans become command trajectory steps so the standard `trajectory:*` assertions work on both regular and sandbox runs.

When Promptfoo tracing is enabled, the provider adds Promptfoo OTLP export alongside any tracing processors already registered in the SDK. The exporter follows the evaluation's configured HTTP receiver, including IPv6 hosts and JSON- or protobuf-only receivers. Passing a trace context by itself does not enable export unless a receiver or explicit `otlpEndpoint` is available. If Promptfoo tracing is disabled, the SDK's own tracing behavior still applies; set `OPENAI_AGENTS_DISABLE_TRACING=1` if you also want to suppress the SDK exporter.

Once Promptfoo is collecting those traces, you can assert on the agent's path instead of only its final message:

```yaml
tests:
  - vars:
      query: 'Find order 123 and tell me whether it shipped'
    assert:
      - type: trajectory:tool-used
        value: search_orders

      - type: trajectory:tool-args-match
        value:
          name: search_orders
          args:
            order_id: '123'

      - type: trajectory:tool-sequence
        value:
          steps:
            - search_orders
            - compose_reply

      - type: trajectory:goal-success
        value: 'Determine whether order 123 shipped and tell the user the correct status'
        provider: openai:gpt-6-luna
```

See [Tracing](/docs/tracing/) for the eval-level OTLP setup required when you want Promptfoo to ingest and evaluate these traces directly.

## Example: D&D Dungeon Master

The complete example, including its agent and tool files, is available in
[examples/openai-agents-basic](https://github.com/promptfoo/promptfoo/tree/main/examples/openai-agents-basic).
Its config uses the following file references:

```yaml
description: D&D Adventure with AI Dungeon Master

prompts:
  - '{{query}}'

providers:
  - id: openai:agents:dungeon-master
    config:
      agent: file://./agents/dungeon-master-agent.ts
      tools: file://./tools/game-tools.ts
      maxTurns: 20
      tracing: true

tests:
  - description: Dragon combat with attack roll
    vars:
      query: 'I draw my longsword and attack the red dragon!'
    assert:
      - type: llm-rubric
        value: Response includes dice rolls for attack and damage

  - description: Check character stats
    vars:
      query: 'What are my character stats and current HP?'
    assert:
      - type: contains-any
        value: ['Thorin', 'Fighter', 'level 5']
```

:::tip

Try the interactive example: `npx promptfoo@latest init --example openai-agents-basic`

:::

## Example: Advanced TypeScript Features

For sessions, tracing assertions, sandbox agents, and skills, see the runnable [`openai-agents-advanced`](https://github.com/promptfoo/promptfoo/tree/main/examples/openai-agents-advanced) example:

```bash
npx promptfoo@latest init --example openai-agents-advanced
cd openai-agents-advanced
npm install
npx promptfoo eval -c promptfooconfig.yaml --no-cache -j 1
npx promptfoo eval -c promptfooconfig.sandbox.yaml --no-cache
```

## Scope

This provider targets non-streaming text and sandbox `run()` workflows. Use `openai:realtime:*` for Realtime API evals. Serialized human-in-the-loop `RunState` resume flows are application state, so test those through a custom JavaScript provider wrapper instead of passing them as prompt text.

## Environment Variables

| Variable                    | Description                |
| --------------------------- | -------------------------- |
| `OPENAI_API_KEY`            | OpenAI API key (required)  |
| `PROMPTFOO_TRACING_ENABLED` | Enable tracing globally    |
| `OPENAI_BASE_URL`           | Custom OpenAI API base URL |
| `OPENAI_ORGANIZATION`       | OpenAI organization ID     |

## Limitations

:::warning

Tools must be async functions. Synchronous tools will cause runtime errors.

:::

- Agent definition files must be TypeScript or JavaScript
- File paths require `file://` prefix (relative paths resolve from config file location)
- Default maximum: 10 turns (configure with `maxTurns`, or set `null` to disable the SDK turn limit)

## Related Documentation

- [OpenAI Provider](/docs/providers/openai) - Standard OpenAI completions and chat
- [Codex Security SDK](/docs/providers/openai-codex-security) - Repository scans, finding validation, coverage, and scan cost evals
- [OpenAI Agents Python SDK Guide](/docs/guides/evaluate-openai-agents-python) - Python SDK example with Promptfoo tracing and framework-specific provider wrapping
- [Tracing](/docs/tracing) - OTLP ingestion and trajectory assertions
- [Red Team Guide](/docs/red-team/quickstart) - Test agent safety
- [Multi-turn Jailbreaks](/docs/red-team/strategies/multi-turn) - Stateful red-team strategy guidance
- [Multi-turn Session Management](/docs/red-team/troubleshooting/multi-turn-sessions) - Provider-specific session setup
- [Assertions](/docs/configuration/expected-outputs) - Validate agent responses
- [OpenAI Agents SDK](https://github.com/openai/openai-agents-js) - Official SDK documentation