@agent-native/core 0.57.0 → 0.58.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,232 @@
1
+ ---
2
+ title: "Harness Agents"
3
+ description: "Run Claude Code, Codex, Pi, and other full coding harnesses as embedded agents inside Agent-Native, with their own loop, sandbox, native tools, and resumable SQL-backed sessions."
4
+ search: "harness agents AgentHarness ai-sdk HarnessAgent Claude Code Codex Pi Cursor Mastra embedded coding agent resolveAgentHarness startAgentHarnessRun resumable session sandbox host tools"
5
+ ---
6
+
7
+ # Harness Agents
8
+
9
+ A harness agent is a full agent runtime — Claude Code, Codex, Pi, and similar —
10
+ that owns its own loop, workspace, native file tools, session state, compaction,
11
+ approval model, and sandbox behavior. Agent-Native runs these through the
12
+ **`AgentHarness`** substrate in `@agent-native/core/agent/harness`, streams their
13
+ events into the normal transcript, and persists their native session so a thread
14
+ can pause and resume.
15
+
16
+ This is different from the built-in chat agent and from bringing your own chat
17
+ runtime. The built-in agent and `AgentEngine` are for one model round trip
18
+ beneath `runAgentLoop`. A harness is not an `AgentEngine` provider — it runs its
19
+ own loop end to end, so Agent-Native drives it as a session, not as a single
20
+ model call.
21
+
22
+ | You want to… | Use |
23
+ | -------------------------------------------------------------------------- | ------------------------------------------------------------- |
24
+ | Run Claude Code / Codex / Pi **as the agent**, with their own loop + tools | **Harness agents** (this page) |
25
+ | Put an agent you built elsewhere behind Agent-Native's **chat UI** | [`AgentChatRuntime`](/docs/native-chat-ui#byo-agent-runtimes) |
26
+ | Let an external MCP host (Claude Code, Cursor, …) **call into your app** | [External Agents](/docs/external-agents) |
27
+ | Render a Claude-Code/Codex-style **coding workspace UI** | [Agent-Native Code UI](/docs/code-agents-ui) |
28
+ | Spawn background / sub-agent runs and teams | [Custom Agents & Teams](/docs/agent-teams) |
29
+
30
+ ## Built-in harnesses {#built-in}
31
+
32
+ `registerBuiltinAgentHarnesses()` registers three adapters backed by the AI SDK
33
+ `HarnessAgent`:
34
+
35
+ | Name | Runtime | Sandbox | Approvals |
36
+ | ---------------------------- | ----------- | ------- | --------- |
37
+ | `ai-sdk-harness:claude-code` | Claude Code | yes | yes |
38
+ | `ai-sdk-harness:codex` | Codex | yes | no |
39
+ | `ai-sdk-harness:pi` | Pi | no | yes |
40
+
41
+ Their runtime packages are **optional peer dependencies** and load lazily, so an
42
+ app that never uses a harness does not pay for it. Each adapter carries an
43
+ `installPackage` hint (for example `@ai-sdk/harness@canary
44
+ @ai-sdk/harness-codex@canary`); `resolveAgentHarness` throws a clear install
45
+ error if the packages are missing, and `isAgentHarnessPackageInstalled(entry)`
46
+ lets you check first.
47
+
48
+ ## Register and resolve {#register-resolve}
49
+
50
+ ```ts
51
+ import {
52
+ registerBuiltinAgentHarnesses,
53
+ resolveAgentHarness,
54
+ } from "@agent-native/core/agent/harness";
55
+
56
+ registerBuiltinAgentHarnesses();
57
+ const adapter = resolveAgentHarness("ai-sdk-harness:codex");
58
+ ```
59
+
60
+ `resolveAgentHarness(name, config?)` returns an `AgentHarnessAdapter`. The
61
+ optional `config` is forwarded to the adapter factory — for the AI SDK adapters
62
+ that maps to `AiSdkHarnessAdapterOptions` (`label`, `description`,
63
+ `permissionMode`, `harnessOptions`, `agentOptions`). Use `listAgentHarnesses()`
64
+ to enumerate what is registered for a picker.
65
+
66
+ ## Run a turn {#run-a-turn}
67
+
68
+ `startAgentHarnessRun` bridges a harness session into the shared run-manager
69
+ lifecycle. It creates (or reuses) the native session, persists it, streams the
70
+ turn, translates each harness event into transcript events, and detaches the
71
+ resumable state when the turn completes.
72
+
73
+ ```ts
74
+ import { startAgentHarnessRun } from "@agent-native/core/agent/harness";
75
+
76
+ const run = startAgentHarnessRun({
77
+ runId,
78
+ threadId,
79
+ adapter,
80
+ input: { prompt },
81
+ createSession: {
82
+ sessionId,
83
+ resumeState, // opaque value from a previous turn, if resuming
84
+ instructions,
85
+ sandbox, // required for sandboxed harnesses — see Sandbox Adapters
86
+ permissionMode: "allow-reads",
87
+ tools, // a narrow, intentional set of host tools (see below)
88
+ },
89
+ ownerEmail,
90
+ orgId,
91
+ });
92
+ ```
93
+
94
+ `startAgentHarnessRun` returns the `ActiveRun` from the run-manager, so the turn
95
+ shows up through the existing run routes, transcript, and cancellation just like
96
+ any other agent run. Pass an already-created `session` instead of `createSession`
97
+ to continue a session you are holding in memory.
98
+
99
+ ## Sessions and resume {#sessions}
100
+
101
+ A harness owns long-lived native session state. Agent-Native persists it in SQL
102
+ so a thread can survive across turns, processes, and deploys. The `resumeState`
103
+ is **opaque** — Agent-Native stores it and hands it back, but never inspects or
104
+ interprets it.
105
+
106
+ ```ts
107
+ import {
108
+ getLatestAgentHarnessSessionForThread,
109
+ listAgentHarnessSessions,
110
+ } from "@agent-native/core/agent/harness";
111
+
112
+ const last = await getLatestAgentHarnessSessionForThread(threadId);
113
+ // Feed last?.resumeState into createSession.resumeState on the next turn.
114
+ ```
115
+
116
+ The store also exposes `saveAgentHarnessSession`, `updateAgentHarnessSession`,
117
+ `getAgentHarnessSession`, `getAgentHarnessSessionByRunId`,
118
+ `markAgentHarnessSessionStopped`, and `ensureAgentHarnessSessionTables`.
119
+ `startAgentHarnessRun` calls the save/update/stop paths for you; reach for them
120
+ directly only in a custom host.
121
+
122
+ ## Host tools and permissions {#host-tools}
123
+
124
+ A harness brings its own native tools (read, edit, write, shell, and so on), so
125
+ you do **not** re-expose file editing as host tools. Pass only a **narrow,
126
+ intentional set** of Agent-Native actions through `createSession.tools` when you
127
+ want the harness to reach specific app operations — and keep `defineAction`
128
+ auth, request context, timeouts, truncation, and read-only metadata intact when
129
+ you do.
130
+
131
+ `permissionMode` gates what the harness may do without approval:
132
+
133
+ | Mode | Meaning |
134
+ | ------------- | -------------------------------------------------- |
135
+ | `allow-reads` | Default. Reads run; edits and risky actions prompt |
136
+ | `allow-edits` | Reads and edits run; other risky actions prompt |
137
+ | `allow-all` | No approval gating |
138
+
139
+ When a harness pauses for approval it emits an `approval-request` event and the
140
+ session is marked `idle` with the pending approval recorded, so the UI can
141
+ surface it and resume on the user's decision. See
142
+ [Human Approval](/docs/human-approval) for the approval surface.
143
+
144
+ ## Events {#events}
145
+
146
+ A harness session streams `AgentHarnessEvent` values, which Agent-Native
147
+ translates to the standard `AgentChatEvent` stream with
148
+ `agentHarnessEventToAgentChatEvents`. The event union covers `text-delta`,
149
+ `thinking-delta`, `activity`, `tool-start`, `tool-done` (which can carry an
150
+ `mcpApp` payload for native widgets), `approval-request`, `file-change`,
151
+ `compaction`, `usage`, `error`, and `done`. Because tool results flow through the
152
+ same translation, action-declared native widgets still render — see
153
+ [Native Chat UI](/docs/native-chat-ui).
154
+
155
+ ## Background runs and the UI {#background-runs}
156
+
157
+ Harness runs project into the shared `BackgroundAgentRun` shape with
158
+ `createAgentHarnessBackgroundAgentController()` and are available through the
159
+ existing run routes as `goalId=agent-harness`. That means a long-running Claude
160
+ Code or Codex session appears in the same background-run and transcript surfaces
161
+ as Agent Teams and other adapters, with `listAgentHarnessBackgroundRuns`,
162
+ `listAgentHarnessBackgroundTranscriptEvents`, `getAgentHarnessBackgroundRun`, and
163
+ `stopAgentHarnessBackgroundRun` available for custom hosts.
164
+
165
+ ## Custom adapters {#custom-adapters}
166
+
167
+ To wrap a runtime that is not one of the built-ins, implement
168
+ `AgentHarnessAdapter` and register it. The adapter declares its capabilities and
169
+ creates sessions; a session exposes `streamTurn` and optional `continueTurn`,
170
+ `approve`, `detach`, `stop`, and `destroy`.
171
+
172
+ ```ts
173
+ import {
174
+ registerAgentHarness,
175
+ type AgentHarnessAdapter,
176
+ } from "@agent-native/core/agent/harness";
177
+
178
+ const myHarness: AgentHarnessAdapter = {
179
+ name: "acme:my-coder",
180
+ label: "Acme Coder",
181
+ description: "Runs the Acme coding agent.",
182
+ installPackage: "@acme/coder",
183
+ capabilities: {
184
+ sandbox: true,
185
+ resumable: true,
186
+ approvals: true,
187
+ hostTools: true,
188
+ fileEvents: true,
189
+ },
190
+ async createSession(opts) {
191
+ // Build your native session and adapt it to AgentHarnessSession.
192
+ return createAcmeSession(opts);
193
+ },
194
+ };
195
+
196
+ registerAgentHarness({
197
+ name: myHarness.name,
198
+ label: myHarness.label,
199
+ description: myHarness.description,
200
+ installPackage: myHarness.installPackage,
201
+ capabilities: myHarness.capabilities,
202
+ create: () => myHarness,
203
+ });
204
+ ```
205
+
206
+ Keep the runtime package optional with a dynamic import in `createSession` and an
207
+ `installPackage` hint. For bridge-backed coding harnesses, require a real
208
+ sandbox/workspace provider rather than running an arbitrary coding agent in the
209
+ host process — see [Sandbox Adapters](/docs/sandbox-adapters). The AI SDK adapter
210
+ (`createAiSdkHarnessAdapter`, backed by `HarnessAgent` from `@ai-sdk/harness`) is
211
+ one implementation of this contract, not the public abstraction.
212
+
213
+ ## Don't {#donts}
214
+
215
+ - Don't add Claude Code, Codex, Cursor, Mastra, or Pi as an `AgentEngine`. They
216
+ own their loop; running one under `AgentEngine.stream()` double-runs the loop
217
+ and loses session lifecycle semantics.
218
+ - Don't replay full Agent-Native chat history into a harness each turn. Resume
219
+ the harness session with its `resumeState` instead.
220
+ - Don't store `resumeState` in `application_state`. It belongs in the harness
221
+ session SQL table.
222
+ - Don't expose every app action to every harness session by default. Hand it a
223
+ small, intentional tool set.
224
+
225
+ ## Related docs {#related-docs}
226
+
227
+ - [Native Chat UI](/docs/native-chat-ui) — put your own agent behind the chat UI with `AgentChatRuntime`.
228
+ - [Agent Surfaces](/docs/agent-surfaces) — choose headless, chat, sidecar, or full-app.
229
+ - [Agent-Native Code UI](/docs/code-agents-ui) — the reusable coding workspace surface.
230
+ - [Custom Agents & Teams](/docs/agent-teams) — background runs and sub-agent delegation.
231
+ - [Sandbox Adapters](/docs/sandbox-adapters) — pluggable execution backends for coding harnesses.
232
+ - [Human Approval](/docs/human-approval) — the approval surface harness runs use.
@@ -190,27 +190,27 @@ See [Context Awareness](/docs/context-awareness) for the full pattern: navigatio
190
190
 
191
191
  Agent-native supports a lot of agent-facing protocols because different hosts standardize different pieces of the same workflow. App authors should not have to choose among them or rebuild the same operation for each client. The center of gravity stays the action system.
192
192
 
193
- | Surface | Status | What agent-native provides | What you write |
194
- | ----------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- |
195
- | Agent tool calling | Shipping | The in-app agent sees actions as function tools with zod-derived JSON Schema. | `defineAction()` |
196
- | UI actions | Shipping | React calls the same action through `useActionMutation()` / `useActionQuery()`. | The same action |
197
- | Native chat widgets | Shipping | Tool results with explicit widget discriminants can render native tables, charts, and typed app results in chat. | Structured action results |
198
- | HTTP and CLI | Shipping | Actions auto-mount at `/_agent-native/actions/:name` and run via `pnpm action <name>`. | The same action |
199
- | MCP server | Shipping | External MCP hosts get Streamable HTTP tools, the `ask-agent` meta-tool, and optional MCP Apps resources. | The same action, plus optional `mcpApp` |
200
- | MCP OAuth | Shipping | Standard remote MCP OAuth, PKCE, dynamic client registration, refresh tokens, and `mcp:read` / `mcp:write` / `mcp:apps` scopes. | Nothing per action |
201
- | MCP Apps | Shipping | External hosts that support app resources can render iframe/native-host widgets, with deep-link fallback elsewhere. | Optional `mcpApp` metadata |
202
- | A2A | Shipping | Other agents discover the agent card and call the app over JSON-RPC tasks. | The same actions and agent config |
203
- | Deep links | Shipping | Action results can round-trip users into the running UI through `/_agent-native/open` and `agentnative://open`. | Optional `link` metadata |
204
- | MCP clients | Shipping | The app can also consume local, remote, or hub-shared MCP servers as `mcp__...` tools. | `mcp.config.json` or settings |
205
- | Instructions and skills | Shipping | `AGENTS.md`, skills, memory, slash commands, sub-agents, jobs, and automations live in the SQL-backed workspace. | Workspace resources, not protocol glue |
206
- | Agent Web | Shipping | Public pages can publish `robots.txt`, `sitemap.xml`, `llms.txt`, markdown mirrors, and structured metadata. | Route access plus `agentWeb` config |
207
- | Extensions | Shipping | Sandboxed mini-apps call app actions, persist extension data, and use proxied fetch helpers. | Extension HTML using `appAction()` |
208
- | AG-UI | Adapter target | A good fit for connecting an external agent runtime to an agent-native chat/UI shell through event streams. | An adapter, not duplicate actions |
209
- | ACP | Coding-agent/editor | Useful for coding agents inside editors/IDEs; not the general BYO app-chat runtime contract. | Editor/agent adapter work |
210
-
211
- The practical rule is simple: implement domain operations as actions, add `readOnly`, `publicAgent`, `link`, `mcpApp`, or an explicit native widget result only when a surface needs it, and use skills/instructions for behavior. MCP, A2A, MCP Apps, MCP OAuth, UI mutations, native chat widgets, CLI commands, and deep-link handoffs are adapters around that same core.
212
-
213
- Adapter horizon: [AG-UI](https://docs.ag-ui.com/introduction) is a strong fit for connecting external agent runtimes to Agent-Native chat and app shells through events. [ACP](https://zed.dev/acp) is important for coding-agent/editor interoperability, but it is not the general BYO app-agent UI contract.
193
+ | Surface | Status | What agent-native provides | What you write |
194
+ | --------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
195
+ | Agent tool calling | Shipping | The in-app agent sees actions as function tools with zod-derived JSON Schema. | `defineAction()` |
196
+ | UI actions | Shipping | React calls the same action through `useActionMutation()` / `useActionQuery()`. | The same action |
197
+ | Native chat widgets | Shipping | Tool results with explicit widget discriminants can render native tables, charts, and typed app results in chat. | Structured action results |
198
+ | AgentChatRuntime connectors | Shipping | The chat shell can sit on top of OpenAI Agents, OpenAI Responses, Claude Agent SDK, Vercel AI SDK, AG-UI, or normalized HTTP streams. | Pick a runtime helper or stream normalized events |
199
+ | HTTP and CLI | Shipping | Actions auto-mount at `/_agent-native/actions/:name` and run via `pnpm action <name>`. | The same action |
200
+ | MCP server | Shipping | External MCP hosts get Streamable HTTP tools, the `ask-agent` meta-tool, and optional MCP Apps resources. | The same action, plus optional `mcpApp` |
201
+ | MCP OAuth | Shipping | Standard remote MCP OAuth, PKCE, dynamic client registration, refresh tokens, and `mcp:read` / `mcp:write` / `mcp:apps` scopes. | Nothing per action |
202
+ | MCP Apps | Shipping | External hosts that support app resources can render iframe/native-host widgets, with deep-link fallback elsewhere. | Optional `mcpApp` metadata |
203
+ | A2A | Shipping | Other agents discover the agent card and call the app over JSON-RPC tasks. | The same actions and agent config |
204
+ | Deep links | Shipping | Action results can round-trip users into the running UI through `/_agent-native/open` and `agentnative://open`. | Optional `link` metadata |
205
+ | MCP clients | Shipping | The app can also consume local, remote, or hub-shared MCP servers as `mcp__...` tools. | `mcp.config.json` or settings |
206
+ | Instructions and skills | Shipping | `AGENTS.md`, skills, memory, slash commands, sub-agents, jobs, and automations live in the SQL-backed workspace. | Workspace resources, not protocol glue |
207
+ | Agent Web | Shipping | Public pages can publish `robots.txt`, `sitemap.xml`, `llms.txt`, markdown mirrors, and structured metadata. | Route access plus `agentWeb` config |
208
+ | Extensions | Shipping | Sandboxed mini-apps call app actions, persist extension data, and use proxied fetch helpers. | Extension HTML using `appAction()` |
209
+ | ACP | Coding-agent/editor | Useful for coding agents inside editors/IDEs; not the general BYO app-chat runtime contract. | Editor/agent adapter work |
210
+
211
+ The practical rule is simple: implement domain operations as actions, add `readOnly`, `publicAgent`, `link`, `mcpApp`, or an explicit native widget result only when a surface needs it, and use skills/instructions for behavior. MCP, A2A, MCP Apps, MCP OAuth, UI mutations, native chat widgets, AgentChatRuntime connectors, CLI commands, and deep-link handoffs are adapters around that same core.
212
+
213
+ Adapter horizon: [A2UI](https://a2ui.org/) is worth watching for portable generated UI across trust boundaries, but first-party Agent-Native widgets should stay explicit native renderers. [ACP](https://zed.dev/acp) is important for coding-agent/editor interoperability, but it is not the general BYO app-agent UI contract.
214
214
 
215
215
  ## Three product shapes {#three-product-shapes}
216
216
 
@@ -302,6 +302,7 @@ Adopting the framework is valuable mostly because of what you stop having to bui
302
302
  - **One action = every surface.** Every action defined with `defineAction()` is simultaneously an agent tool, a typesafe frontend hook (`useActionQuery` / `useActionMutation`), a framework-owned HTTP transport, a CLI command, an MCP tool for external clients, and an A2A tool for other agent-native apps. Optional `link` and `mcpApp` metadata add deep links and MCP Apps UI without a second implementation.
303
303
  - **A full workspace per user.** Skills, shared `LEARNINGS.md`, personal `memory/MEMORY.md`, `AGENTS.md`, custom sub-agents, scheduled jobs, connected MCP servers — all SQL-backed, no dev-box required. See [Workspace](/docs/workspace).
304
304
  - **Drop-in React components.** `<AgentPanel />` and `<AgentSidebar />` render chat + workspace anywhere in your app. See [Drop-in Agent](/docs/drop-in-agent).
305
+ - **BYO agent chat runtimes.** The same chat UI can sit on top of OpenAI Agents, OpenAI Responses, Claude Agent SDK, Vercel AI SDK, AG-UI, or your own normalized HTTP stream. See [Native Chat UI](/docs/native-chat-ui#byo-agent-runtimes).
305
306
  - **Live sync between agent and UI.** Same-process writes stream immediately over `/_agent-native/events`; a lightweight poll keeps serverless, cron, and cross-process writes convergent. Mutating actions invalidate action-backed queries automatically, so agent-created records appear without a manual refresh. See [Live Sync](#polling-sync) below.
306
307
  - **Auth, orgs, RBAC.** Better Auth with orgs/members/roles is wired in for every template. See [Authentication](/docs/authentication).
307
308
  - **Context awareness.** The agent always knows what the user is looking at through the `navigation` app-state key. See [Context Awareness](/docs/context-awareness).
@@ -208,6 +208,39 @@ export function SupportChat() {
208
208
  }
209
209
  ```
210
210
 
211
+ If your endpoint already streams a common agent protocol, use the matching
212
+ connector and skip writing a custom mapper:
213
+
214
+ ```ts
215
+ import {
216
+ createAgUiChatRuntime,
217
+ createClaudeAgentChatRuntime,
218
+ createOpenAIAgentsChatRuntime,
219
+ createOpenAIResponsesChatRuntime,
220
+ createVercelAiChatRuntime,
221
+ } from "@agent-native/core/client/chat";
222
+
223
+ const openAiAgentsRuntime = createOpenAIAgentsChatRuntime({
224
+ endpoint: "/api/openai-agents/chat",
225
+ });
226
+
227
+ const openAiResponsesRuntime = createOpenAIResponsesChatRuntime({
228
+ endpoint: "/api/openai-responses/chat",
229
+ });
230
+
231
+ const claudeAgentRuntime = createClaudeAgentChatRuntime({
232
+ endpoint: "/api/claude-agent/chat",
233
+ });
234
+
235
+ const vercelAiRuntime = createVercelAiChatRuntime({
236
+ endpoint: "/api/vercel-ai/chat",
237
+ });
238
+
239
+ const agUiRuntime = createAgUiChatRuntime({
240
+ endpoint: "/api/ag-ui/chat",
241
+ });
242
+ ```
243
+
211
244
  The endpoint may stream the normalized event shape directly:
212
245
 
213
246
  ```txt
@@ -241,11 +274,10 @@ assistant-ui adapter control. Use `PromptComposer` by itself when your product
241
274
  owns the entire external transcript and only wants Agent-Native's composer
242
275
  field.
243
276
 
244
- AG-UI is still an adapter target: it can be mapped into `AgentChatRuntime`
245
- events, actions, context, and native renderers over time. ACP remains
246
- coding-agent/editor interoperability, not the general app-chat runtime for end
247
- users. A2UI is not claimed as supported here; if it matures, it should adapt
248
- into this same explicit runtime/widget contract.
277
+ OpenAI, AG-UI, Claude Agent SDK, and Vercel AI SDK streams can use the standard
278
+ connector helpers. ACP remains coding-agent/editor interoperability, not the
279
+ general app-chat runtime for end users. A2UI is not claimed as supported here;
280
+ if it matures, it should adapt into this same explicit runtime/widget contract.
249
281
 
250
282
  ## Related docs {#related-docs}
251
283
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@agent-native/core",
3
- "version": "0.57.0",
3
+ "version": "0.58.0",
4
4
  "type": "module",
5
5
  "engines": {
6
6
  "node": ">=22"