add-harness-package

✓ Official★ 25,366

by vercel · part of vercel/ai

Guide for adding new AI SDK harness packages. Use when creating a new @ai-sdk/harness-<name> package that adapts a coding-agent runtime to HarnessV1.

🔒 Repo-maintenance skill. It exists to help maintain vercel/ai itself — it's only useful if you contribute code to that project.

This is the playbook your agent receives when the skill activates — you don't need to read it to use the skill, but it's here to audit before installing.

Adding a New Harness Package

This guide covers creating a new @ai-sdk/harness-<name> package for an agent harness.

A harness can be host-driven, where the runtime runs in the host process and uses the sandbox remotely, or bridge-backed, where a small bridge runs inside the sandbox because the runtime needs local access to the sandbox filesystem or process environment. Prefer host-driven when the runtime supports it.

First-Party vs Third-Party Harnesses

Third-party packages: Any runtime can publish an external harness package.
First-party @ai-sdk/harness-<name> packages: Create an issue first to discuss whether the runtime belongs in this repo.

Reference Example

See https://github.com/vercel/ai/pull/16255/changes for a complete example of adding a new harness.

Harness Architecture

The AI SDK uses a layered harness architecture following the adapter pattern:

Harness specification (@ai-sdk/harness): Defines interfaces like HarnessV1 and HarnessV1Session
Utilities (@ai-sdk/harness/utils): Shared code for implementing harnesses
Harness implementations (@ai-sdk/harness-<name>): Concrete adapters for harnesses
Harness agent (@ai-sdk/harness/agent): The high-level user-facing HarnessAgent API

Step-by-Step Guide

1. Create Package Structure

Create packages/harness-<name> with this baseline structure:

packages/harness-<name>/
├── src/
│   ├── index.ts
│   ├── <name>-harness.ts
│   ├── <name>-harness.test.ts
│   └── <name>-auth.ts              # if the runtime needs auth resolution
├── package.json
├── tsconfig.json
├── tsconfig.build.json
├── tsup.config.ts
├── turbo.json
├── vitest.node.config.js
└── README.md

If the runtime must execute inside the sandbox, add bridge files as well:

src/
├── <name>-bridge-protocol.ts
├── <name>-bridge-protocol.test.ts
└── bridge/
    ├── index.ts
    ├── package.json
    └── pnpm-lock.yaml

Add a CHANGELOG.md containing just the package heading (# @ai-sdk/harness-<name>). Every package is required to have one.

2. Configure package.json

Use existing harness packages as the source of truth for scripts, exports, repository metadata, and publish settings.

Required package basics:

"name": "@ai-sdk/harness-<name>"
"type": "module"
"version": "0.0.0" (starting point for new packages)
"license": "Apache-2.0"
"sideEffects": false
dependency on @ai-sdk/harness via workspace:*
dependency on @ai-sdk/provider-utils via workspace:* when using sandbox/auth/schema utilities
runtime SDK/CLI dependencies required by the harness
dev dependencies matching existing harness packages
"engines": { "node": ">=22" }

For bridge packages, add any bridge asset copy step required for files under src/bridge/.

Bridge dependency rules (bridge-backed harnesses):

The bridge's runtime deps live in src/bridge/package.json (installed in-sandbox at bootstrap), not the main package.json. After changing them, regenerate src/bridge/pnpm-lock.yaml with pnpm --dir packages/harness-<name>/src/bridge install --lockfile-only --ignore-workspace (runnable from the repo root).
For every third-party import in src/bridge/, keep three things in sync: the import, the external array in tsup.config.ts, and the dep in src/bridge/package.json. A missing entry shows up only at sandbox runtime as a module-resolution error.
Include packages the runtime lazily imports — e.g. provider SDKs (@anthropic-ai/sdk, openai) resolved from the model id at runtime — even though nothing imports them directly. These fail only when a model of that provider is actually used.
Match shared dependency versions (transport, schema, tooling, runtime SDKs) to what the other harness packages currently use — copy from a sibling package rather than choosing your own pins. Stale pins drift from security patches and can desync from the shared bridge runtime; check the current versions at creation time.

3. Create TypeScript, Build, and Test Configs

Copy the nearest existing harness package config files and adjust paths/package names:

tsconfig.json
tsconfig.build.json
tsup.config.ts
turbo.json
vitest.node.config.js

Harness packages currently use Node tests only unless the implementation has a specific reason to add another runtime.

4. Implement the Harness Adapter

Export a factory from <name>-harness.ts and re-export it from src/index.ts.

Use the architecture doc for contract details. At implementation time, verify:

return a HarnessV1 with specificationVersion: 'harness-v1';
use a stable kebab-case harnessId;
expose adapter-native built-in tools through builtinTools;
keep construction synchronous and side-effect free;
use startOpts.sandboxSession and startOpts.sessionWorkDir; never create a separate sandbox;
throw HarnessCapabilityUnsupportedError from the method that needs an unsupported runtime capability;
don't hardcode a default model unless the runtime technically requires one — some underlying SDKs have no default of their own. Otherwise pass the model only when the consumer configured one and leave the original SDK's default untouched; keep the session's modelId consistent with what's actually sent (don't report a model the bridge silently overrode);
handle the tools and instructions that doPromptTurn/doContinueTurn may receive: if the runtime can't take custom tools, throw HarnessCapabilityUnsupportedError so it's obvious rather than silently dropped; if it has no native instructions input, prepend them to the first user message (the Codex/Claude Code workaround);
quote interpolated paths (workDir, bridge-state dir, …) when building shell commands for sandbox.run/sandbox.spawn — they can contain spaces.

If the runtime needs in-sandbox setup, expose getBootstrap().

5. Implement Runtime-Specific Concerns

Add only the concerns the runtime needs:

auth resolution — for AI Gateway support, use the central getAiGatewayAuthFromEnv() helper rather than reading env directly. This ensures both VERCEL_OIDC_TOKEN and AI_GATEWAY_API_KEY are accepted as Gateway credential. When the runtime resolves provider per model, resolve the provider from the model id and set that provider's env; if routing through the gateway, note that base-URL conventions differ per provider (e.g. an Anthropic client appends /v1/messages to a root base, an OpenAI client appends to a /v1 base);
custom-tool schema translation — if you convert host tools' JSON Schema into the runtime's tool format, convert recursively (nested objects, array items, enums, descriptions); a flat top-level-only conversion silently drops the model's structured guidance. Passing the JSON Schema through directly, if the runtime accepts it, avoids the problem;
skill or discovery-file materialization;
native protocol to harness stream/control translation;
lifecycle state schema;
bridge protocol and diagnostics.

Certain structural conventions for harness adapters are being enforced via the konsistent CLI. Run pnpm konsistent once you're done to check for those. Fix any violations flagged before proceeding.

6. Write Tests

Add focused Node tests for:

factory metadata and settings;
auth resolution;
sandbox usage and path placement;
host-driven remote operations or bridge protocol behavior;
prompt/control event translation;
resume session vs continue turn behavior;
unsupported capability errors;
skill materialization, if supported.

Use mocked sandbox sessions and bridge/runtime boundaries where possible. Do not require live provider credentials in unit tests.

getBootstrap() reads the compiled bridge assets (e.g. dist/bridge/index.mjs), which don't exist when tests run against src, so a test that calls it will hit ENOENT. Mock node:fs/promises readFile for the bridge asset paths (see the Codex/OpenCode harness tests for the pattern).

7. Add README

Keep README short:

package purpose;
setup command;
minimal HarnessAgent usage;
required sandbox capabilities, such as ports for bridge-backed runtimes;
notable auth configuration.

Link to the main harness docs for broader concepts.

8. Add Examples

Add relevant examples for the new harness.

Add API/function examples under examples/ai-functions when the harness package needs a scriptable provider-behavior example.
Add interactive examples mirroring the existing harness examples in examples/harness-e2e-next (Next.js) and examples/harness-e2e-tui (TUI).

9. Add Documentation

Create documentation in content/providers/02-ai-sdk-harnesses/<next number>-<name>.mdx.

Include:

Setup instructions
Required sandbox capabilities
Authentication configuration
Harness-specific options
Usage examples
Known limitations

Update content/docs/03-ai-sdk-harnesses/05-harness-adapters.mdx to list the new harness when it is ready to be public.

10. Update References and Validate

Run from the workspace root:

pnpm konsistent
pnpm update-references
pnpm --filter @ai-sdk/harness-<name> build
pnpm --filter @ai-sdk/harness-<name> test
pnpm type-check:full

Add a changeset with pnpm changeset. For a brand-new harness package's first release, use major (not the usual patch), matching the other harness packages.

Run relevant harness examples against a live sandbox early — don't rely on unit tests and type-check alone. Runtime API constraints (e.g. unexpected config-option rejections, the exact streaming event names the runtime emits, gateway base-URL format) surface only when the bridge actually drives the runtime, and they're far cheaper to find before the docs/examples are built on top.

Checklist

Harness Abstraction Architecture
@ai-sdk/harness README
Existing harness packages with similar runtime placement