eve 0.58.1 → 0.59.1

package/docs/evals/judge.mdx

@@ -19,7 +19,7 @@ export default defineEval({
 
 ## The graders
 
-The judges live under `t.judge.autoevals`. The namespace names the [Braintrust autoevals](https://github.com/braintrustdata/autoevals) grader family, so the factuality and closedQA semantics are autoevals', not eve-invented. Each grader scores `t.reply` by default and is soft by default (tracked, no gate):
+The judges live under `t.judge.autoevals`. The namespace names the [Braintrust autoevals](https://github.com/braintrustdata/autoevals) grader family, so the factuality and closedQA semantics are autoevals', not eve-invented. Each grader scores the most recently settled turn’s assistant message by default and is soft by default (tracked, no gate):
 
 | Grader                                   | Grades                                                                                 |
 | ---------------------------------------- | -------------------------------------------------------------------------------------- |
@@ -28,6 +28,8 @@ The judges live under `t.judge.autoevals`. The namespace names the [Braintrust a
 | `t.judge.autoevals.closedQA(criteria)`   | Whether the reply satisfies a free-form yes/no criterion (no expected answer to match) |
 | `t.judge.autoevals.sql(expected)`        | Semantic equivalence of two SQL statements                                             |
 
+Judges receive the latest message text from the session whose turn most recently settled as the input prompt. Approval responses and stream reads preserve that prompt. For multipart messages, including `session.sendFile()`, the prompt contains the text parts.
+
 A failed `closedQA` assertion prints the input and judge explanation:
 
 ```text
@@ -40,7 +42,7 @@ A failed `closedQA` assertion prints the input and judge explanation:
 
 The reference or criteria is the positional argument. An options object follows:
 
-- `on` is the value to grade, defaulting to `t.reply`. Pass an intermediate draft or parsed value to grade it instead.
+- `on` is the value to grade, defaulting to the most recently settled turn’s assistant message. Pass an intermediate draft or parsed value to grade it instead.
 - `model` and `modelOptions` are a per-call judge override (see below).
 
 ```ts
@@ -48,20 +50,20 @@ const draft = await t.send("Draft the welcome email.");
 t.judge.autoevals.closedQA("professional tone", { on: draft.message }).atLeast(0.6);
 ```
 
-For a multi-turn eval, pass `t.transcript` to grade the primary session's complete observed conversation instead of only its final reply:
+For a multi-turn eval, pass `session.transcript` to grade a session's complete observed conversation instead of only its final reply:
 
 ```ts
-await t.send("My favorite word is marigold. Remember it.");
-await t.send("What is my favorite word?");
+const { session } = await t.send("My favorite word is marigold. Remember it.");
+await session.send("What is my favorite word?");
 
 t.judge.autoevals
   .closedQA("The assistant remembers the user's favorite word across turns", {
-    on: t.transcript,
+    on: session.transcript,
   })
   .atLeast(0.8);
 ```
 
-`t.transcript` contains the session's user and assistant messages in turn order. It excludes reasoning, tool calls, and tool results. See [Multi-turn evals](./cases#multi-turn-evals) for the transcript format and independent sessions.
+`session.transcript` contains the session's user and assistant messages in turn order. It excludes reasoning, tool calls, and tool results. See [Multi-turn evals](./cases#multi-turn-evals) for the transcript format and independent sessions.
 
 ## Soft scoring and thresholds
 
@@ -91,7 +93,7 @@ The judge model is resolved once when the runner builds `t`. It is **never** the
 import { defineEvalConfig } from "eve/evals";
 
 export default defineEvalConfig({
-  judge: { model: "openai/gpt-5.4-mini" }, // the default judge for every eval in this tree
+  judge: { model: "openai/gpt-5.6-luna" }, // the default judge for every eval in this tree
 });
 ```
 

package/docs/evals/overview.mdx

@@ -32,10 +32,10 @@ import { includes } from "eve/evals/expect";
 export default defineEval({
   description: "Basic message and tool-usage coverage for the weather agent.",
   async test(t) {
-    await t.send("What is the weather in Brooklyn?");
+    const turn = await t.send("What is the weather in Brooklyn?");
     t.succeeded();
     t.calledTool("get_weather");
-    t.check(t.reply, includes("Sunny"));
+    t.check(turn.message, includes("Sunny"));
   },
 });
 ```
@@ -51,7 +51,7 @@ import { defineEvalConfig } from "eve/evals";
 import { Braintrust } from "eve/evals/reporters";
 
 export default defineEvalConfig({
-  judge: { model: "openai/gpt-5.4-mini" },
+  judge: { model: "openai/gpt-5.6-luna" },
   reporters: [Braintrust({ projectName: "my-agent" })],
 });
 ```
@@ -100,7 +100,7 @@ model: mockModel({
 
 `t` is both the driver and the assertion surface. There are no separate `input`, `run`, `checks`, or `scores` fields. You write ordinary control flow, sending turns and asserting inline.
 
-- **Drive** the agent: `t.send(...)`, `t.start(...)`, `t.cancel()`, `t.respond(...)`, `t.respondAll(...)`, `t.sendFile(...)`, `t.requireInputRequest(...)`, `t.newSession()`. Live turns returned by `start()` can wait for typed mid-turn events before cancellation or settlement. Read what came back with `t.reply` (the last assistant message), `t.transcript` (the primary session's user and assistant messages), `t.sessionId`, and `t.events`. See [Cases](./cases).
+- **Drive** the agent: `t.session()` creates an empty session; `t.send(...)` creates a session with its first message and returns a turn. Continue through `turn.session.send(...)`. Session handles also expose `start`, `cancel`, `respond`, `respondAll`, `sendFile`, and `requireInputRequest`. Read output from `turn.message`, and conversation state from `turn.session`. See [Cases](./cases).
 - **Assert** with three surfaces, covered next.
 
 ## Three assertion surfaces
@@ -108,8 +108,8 @@ model: mockModel({
 Each surface matches a genuinely different kind of judgment:
 
 - **Scoped methods** read the final whole run on `t`, snapshot one independent session when invoked there, or inspect one immutable `EveEvalTurn`. See [Assertions](./assertions).
-- **`t.check(value, assertion)`** grades an explicit value with a deterministic builder from `eve/evals/expect`, such as `t.check(t.reply, includes("sunny"))`. Grade `t.reply`, an intermediate draft, parsed JSON, or anything else. See [Assertions](./assertions).
-- **`t.judge.autoevals.*`** is the LLM-as-judge surface, like `t.judge.autoevals.closedQA("cites a source")`. It grades `t.reply` by default; pass `{ on: t.transcript }` to grade a multi-turn conversation. The judge uses the configured judge model, never the agent under test. See [Judge](./judge).
+- **`t.check(value, assertion)`** grades an explicit value with a deterministic builder from `eve/evals/expect`, such as `t.check(turn.message, includes("sunny"))`. Grade `turn.message`, an intermediate draft, parsed JSON, or anything else. See [Assertions](./assertions).
+- **`t.judge.autoevals.*`** is the LLM-as-judge surface, like `t.judge.autoevals.closedQA("cites a source")`. It grades the most recently settled turn’s assistant message by default; pass `{ on: turn.session.transcript }` to grade a multi-turn conversation. The judge uses the configured judge model, never the agent under test. See [Judge](./judge).
 
 ## Gate vs soft
 

package/docs/evals/reporters.mdx

@@ -18,7 +18,7 @@ import { defineEvalConfig } from "eve/evals";
 import { Braintrust } from "eve/evals/reporters";
 
 export default defineEvalConfig({
-  judge: { model: "openai/gpt-5.4-mini" },
+  judge: { model: "openai/gpt-5.6-luna" },
   reporters: [Braintrust({ projectName: "weather-agent" })],
 });
 ```

package/docs/evals/targets.mdx

@@ -29,6 +29,11 @@ export default defineEval({
 
 Sessions attached this way are full `EveEvalSession`s: you can keep driving them and assert directly on that session (`session.succeeded()`, `session.calledTool(...)`). Aggregate assertions on `t` continue to read the whole run, including every attached session.
 
+For session creation and message delivery, use the [drive API](./cases#the-drive-api).
+`t.session()` creates a session without a first message; call `session.send()` or `session.start()`
+on the returned handle to use it. `t.send()` creates a new session with its first message.
+These helpers handle the session protocol, retries, and event collection for the eval.
+
 ## Authentication
 
 Local targets send no auth: `eve eval` owns the dev server it boots. For a remote `--url`, eve gets the expected Vercel owner and project from `VERCEL_ORG_ID` and `VERCEL_PROJECT_ID` when both are set. Otherwise it reads `.vercel/project.json`. Eve then asks Vercel to resolve the exact HTTPS origin and sends ambient credentials only when the project IDs match. An arbitrary URL remains anonymous.

package/docs/guides/client/messages.mdx

@@ -36,11 +36,11 @@ console.log(result.status, result.message);
 
 When the stream includes `session.failed`, the turn returns `status: "failed"` rather than throwing. Transport and route errors throw `ClientError`.
 
-`session.send()` retries `409 session_not_active` three times when a durable run has been accepted
-but its command inbox is still starting. The retries wait 250 ms, 500 ms, and 1 second. Other
-errors, `session.respond()`, control methods, and raw HTTP requests do not use this retry. An unknown
-session still throws `ClientError` immediately, while a terminal session throws after the final
-attempt. The client never creates a replacement session.
+`session.send()` retries `409 session_not_ready` with bounded exponential backoff for up to 20
+seconds when a durable run has been accepted but its command inbox is still starting. The caller's
+abort signal cancels the wait. Other errors, `session.respond()`, control methods, and raw HTTP
+requests do not use this retry. An unknown
+or terminal session throws `ClientError` immediately with `session_not_active`. The client never creates a replacement session.
 
 ## Send a full turn payload
 

package/docs/guides/client/overview.mdx

@@ -113,7 +113,21 @@ Per-request headers override client-level values with the same name. For example
 
 ## Sessions
 
-For an ID-addressed session, create it explicitly with the first message:
+Create and park an ID-addressed conversation before its first turn when you can start session work
+while the user is still composing:
+
+```ts
+const { session } = await client.sessions.create();
+
+const response = await session.send("Summarize account A.");
+await response.result();
+```
+
+The create promise resolves when the server accepts the durable workflow. It does not open the
+event stream or wait for initialization; an early `session.send()` uses the
+same bounded startup retries as other follow-ups.
+
+To create the session and start its first turn in one request, include the message:
 
 ```ts
 const { session, response } = await client.sessions.create({ message: "Summarize account A." });

package/docs/guides/dynamic-capabilities.md

@@ -265,6 +265,12 @@ Write callback properties as inline function expressions, arrows, method shortha
 
 Closure values must be JSON-serializable. Plain objects, arrays, strings, finite numbers, booleans, and `null` are supported; `undefined` object properties are omitted. Functions, class instances, `Date`, `Map`, symbols, non-finite numbers, and cyclic values fail resolution with the tool name and callback phase instead of being serialized lossily.
 
+Dynamic tools preserve authored input and output validation, including Zod refinements and transformations. JSON Schema describes the tool to the model; the authored validator checks its input and output. eve transforms inline `inputSchema` and `outputSchema` expressions into schema factories and snapshots the JSON-serializable values they capture, just as it does for callbacks.
+
+Write schemas inline in `defineTool()`, or reference a stable module-level schema. A schema stored in a resolver-local variable is a non-serializable capture; inline its construction instead. Schema factories must be synchronous and deterministic for their captured values. Keep external reads in the resolver and capture the resulting JSON data. Imported functions and module-level values remain live code, so they must not hide per-session state.
+
+Schema factories use the same session, scope, resolver entry, and recovery rules as the tool's callbacks. A recovered factory receives its original captures, even if re-running the resolver produces different values. If a required factory is missing, validation fails explicitly; eve does not substitute its JSON Schema description.
+
 Call expressions such as `execute: makeExecutor()` are not transformed. Put the callback body directly in `defineTool()` inside an authored module; eve rejects a dynamic tool if a callback lacks durable metadata.
 
 ### Create dynamic tools in a package
@@ -298,6 +304,22 @@ export function createSearchTool(baseUrl: string) {
 
 Wrap every callback property with the helper. This includes labels, approval policies, `approvalKey`, `execute`, and `toModelOutput`.
 
+For live schemas created in a provider package, use `defineDurableSchema` from `eve/tools`. Put the schema's per-tool values in `closure` and construct the schema in `schema`. Plain JSON Schema objects need no helper.
+
+```ts
+import { defineDurableSchema } from "eve/tools";
+import { z } from "zod";
+
+export function amountSchema(limit: number) {
+  return defineDurableSchema({
+    closure: { limit },
+    schema: ({ limit }) => z.object({ amount: z.number().refine((amount) => amount <= limit) }),
+  });
+}
+```
+
+Pass the result as `inputSchema` or `outputSchema` in `defineTool()`. Rebuild existing extensions with the current `eve extension build` to generate schema factories. A live dynamic schema without a durable factory is rejected at resolution with instructions to inline its construction or use `defineDurableSchema`.
+
 `closure` is the callback's only durable snapshot. Store the identifiers and configuration needed to reproduce the call there. Reconstruct clients or look up live runtime state when the callback runs. The callback may call stable imported functions, but it must not capture runtime objects outside `closure`. Those values disappear on a cold start.
 
 eve-provided factories, including [memory provider tools](../memory), use the same durable callback mechanism.

package/docs/guides/evaluate.md

@@ -1,12 +1,13 @@
 ---
 title: Automatic Model Selection
-description: "Choose an agent model from the current request with an AI SDK evaluation model."
+description: "Choose agent models automatically or evaluate typed questions in your tools and application code."
 ---
 
 Use `autoModel` to choose an agent model from an allowlist before inference begins.
 It uses the [AI SDK evaluation API](https://ai-sdk.dev/docs/ai-sdk-core/evaluation),
 so the evaluator can be a Vercel AI Gateway model ID or an evaluation model from
-an installed provider.
+an installed provider. Use `evaluate` from the same entrypoint to ask typed
+questions in your own tools or application code.
 
 `eve/experimental/evaluate` is experimental. Its API can change between eve
 releases, and the AI SDK evaluation model specification can change in patch
@@ -37,7 +38,8 @@ does not add a TypeSafe credential or transport layer. During `eve dev`, a
 Gateway evaluator uses the same connection selected through `/login` as Gateway
 language models. A configured AI SDK default provider still owns string model
 resolution during development. The TUI footer displays `dynamic model` when the
-agent uses `autoModel`.
+agent uses `autoModel`, then adds the resolved model for the current turn, such as
+`dynamic model · openai/gpt-5.6-luna`.
 
 ## Use a provider directly
 
@@ -102,6 +104,79 @@ Supported reasoning values are `"provider-default"`, `"none"`, `"minimal"`,
 `"low"`, `"medium"`, `"high"`, and `"xhigh"`. An omitted value inherits the
 agent's reasoning setting.
 
+## Evaluate inside a tool
+
+Use `evaluate` to ask choice, score, or boolean questions about the state you pass to it.
+It defaults to `typesafe-ai/jev` and uses the same authentication as `autoModel`,
+including the Gateway connection selected through `/login` during `eve dev`.
+Pass `model` to use another evaluation model ID or a provider instance. A configured
+AI SDK default provider takes precedence over the local Gateway connection.
+
+```ts title="agent/tools/classify-request.ts"
+import { evaluate } from "eve/experimental/evaluate";
+import { defineTool } from "eve/tools";
+import { z } from "zod";
+
+export default defineTool({
+  description: "Choose the team that can help with a customer request.",
+  inputSchema: z.object({ request: z.string().min(1).max(8000) }),
+  async execute({ request }, ctx) {
+    const result = await evaluate({
+      state: { request },
+      questions: {
+        team: {
+          type: "choice",
+          instructions: "Select the team best suited to handle the request.",
+          criteria: {
+            billing: "Invoices, payments, and refunds",
+            support: "Product questions and troubleshooting",
+          },
+        },
+      },
+      abortSignal: ctx.abortSignal,
+    });
+    return { team: result.answers.team.choice };
+  },
+});
+```
+
+The choice above is typed as `"billing" | "support"`. Each question appears under
+its authored key in `result.answers`. Results also include token usage, warnings,
+provider metadata, and response metadata.
+
+`evaluate` accepts AI SDK evaluation options, including `maxRetries`, `headers`,
+and `providerOptions`. Pass an `abortSignal` to cancel the request. Input and
+answer validation, retries, and provider errors follow AI SDK semantics.
+
+You can also call `evaluate` outside a tool; it does not require an active eve
+session. Each call performs its own evaluation. `autoModel` uses this function
+and adds the per-turn routing behavior described below.
+
+## Evaluate tool approvals
+
+Use `auto({ model? })` when an evaluation model should decide whether a
+tool call can run automatically or needs human approval. It accepts the same
+AI SDK evaluation model strings and provider instances described above and
+defaults to `typesafe-ai/jev`:
+
+```ts title="agent/tools/deploy.ts"
+import { defineTool } from "eve/tools";
+import { auto } from "eve/tools/approval";
+import { z } from "zod";
+
+export default defineTool({
+  description: "Deploy an application.",
+  inputSchema: z.object({ environment: z.string() }),
+  approval: auto({ model: "typesafe-ai/jev" }), // Uses AI SDK string-model resolution
+  execute: ({ environment }) => deploy(environment),
+});
+```
+
+The evaluation model reviews the tool name and input for dangerous effects. A
+caution, failed review, or incomplete input requires human approval. See
+[Human-in-the-loop approvals](/docs/human-in-the-loop#approvals) for classifier
+options and data handling.
+
 ## Runtime behavior
 
 `autoModel` evaluates at the first `step.started` event, after the incoming prompt

package/docs/guides/frontend/overview.mdx

@@ -74,9 +74,10 @@ export function Chat() {
 | --------- | ----------------------------------------------------------------------------------------- |
 | `data`    | Projected UI state from the reducer. Defaults to `{ messages }`.                          |
 | `status`  | `"ready"`, `"resuming"`, `"submitted"`, `"streaming"`, or `"error"`. Drives the composer. |
-| `error`   | The last `Error` thrown, if any.                                                          |
+| `error`   | The latest session creation, stream, resume, or turn failure.                             |
 | `events`  | Raw eve stream events for this session.                                                   |
 | `session` | Serializable fixed session cursor (`sessionId`, `streamIndex`).                           |
+| `prewarm` | Create the durable session without starting a turn.                                       |
 | `send`    | Send text or a multi-part message, with per-turn options.                                 |
 | `respond` | Answer pending HITL input requests, with per-turn options.                                |
 | `resume`  | Replay an attached session and follow its in-flight turn.                                 |
@@ -85,6 +86,50 @@ export function Chat() {
 
 Most chat UIs only need `data.messages` and `status`. Drop down to `events` when you need the authoritative wire events directly, for example to persist an audit log or build a custom projection.
 
+Pass `prewarm: true` to start a workflow when the chat mounts and after each reset:
+
+```tsx
+import { useEveAgent } from "eve/react";
+
+export function Chat() {
+  const agent = useEveAgent({ prewarm: true });
+
+  return <button onClick={agent.reset}>New chat</button>;
+}
+```
+
+Prewarming defaults to `false`: the first send creates the session. Enable it when your
+application's auth, headers, and any chat-record binding are ready at mount. Applications
+that prepare those in the submit handler should keep the default.
+
+Prewarming starts the workflow and establishes its inbox, then parks before session hooks,
+dynamic definitions, or sandbox setup run. The first message passes through the channel's
+`onMessage` hook and supplies the identity and context for initialization and `turn_0`.
+
+The explicit `prewarm()` method resolves on `202 Accepted`, as does `client.sessions.create()`.
+It does not wait for an initialization event; concurrent calls share the same create request.
+The composer stays `"ready"`, meaning it can accept input, and prewarming does not run
+`prepareSend`. A concurrent `send()` waits only for acceptance, then posts the message.
+If the inbox is still starting, the client retries `409 session_not_ready` with bounded
+exponential backoff for up to 20 seconds. The caller's abort signal cancels the wait. Stream
+events are not a prerequisite for sending.
+
+A failed create sets `error` and calls `onError` when no send is waiting. A waiting send can
+fall back to creating a session with its message. After creation succeeds, initialization
+failures arrive on the stream during the first turn. The configured session timeout starts
+at creation, so an unused prewarmed session can expire before its first message.
+
+The hook keeps consuming one session stream across turns and idle periods. Replies,
+authorization updates, and turns started elsewhere all update the same projection. A turn settling
+does not close the connection. The transport reconnects from its cursor after a disconnect or the
+server's renewable 60-second lease; lease renewal does not start a turn or clear UI state.
+Unmounting or resetting closes the local stream without cancelling the old durable session.
+
+`reset()` reuses the hook instance and clears the conversation. With `prewarm: true`, it
+immediately prepares the next owned session; otherwise, the next send creates it. An explicitly supplied
+`session` remains externally owned and is never replaced by prewarming or reset. Use
+`initialSession` with `resume: true` to restore a saved chat.
+
 `data.messages` are eve-owned `EveMessage[]`. Common text, reasoning, file, and dynamic-tool parts follow the [AI SDK `UIMessage`](https://ai-sdk.dev/docs/reference/ai-sdk-core/ui-message) rendering convention, but the types are not interchangeable. eve also exposes authorization and HITL metadata, and a file part's URL can be absent. Adapt those parts before passing messages to an API typed as `UIMessage[]`.
 
 When the root agent delegates, its stream emits `subagent.called` with the child's `childSessionId`, then `subagent.completed` after admission with a working task receipt. Later task notifications wake the parent with completion, failure, or cancellation. Detailed child progress lives on the child session's stream instead of being flattened into the root `data.messages`. Use the lower-level [TypeScript client](../client/overview#sessions) to attach to that ID when your UI needs live subagent activity. See [What the parent sees](../../subagents#what-the-parent-sees) for the complete contract.
@@ -227,9 +272,9 @@ const agent = useEveAgent({
 The hook accepts these lifecycle callbacks:
 
 - `onEvent(event)`: fires for each eve stream event as it arrives.
-- `onError(error)`: fires with the last `Error` when a turn fails.
+- `onError(error)`: fires when session creation, streaming, resume, or a turn fails. A failed prewarm reports here when no send is waiting to retry creation.
 - `onFinish(snapshot)`: fires with the final `{ data, status, session, ... }` snapshot once a turn settles.
-- `onSessionChange(session)`: fires when the session cursor advances. Persist it to resume across reloads.
+- `onSessionChange(session)`: fires when a session is created, its cursor advances, or reset clears it. Persist the session state to resume across reloads.
 
 ```tsx
 const agent = useEveAgent({
@@ -306,9 +351,9 @@ then save a final snapshot in `onFinish`.
 
 `initialEvents` must be an ordered prefix of the same session's stream, but its endpoint does not have to line up exactly with where the stream resumes. When the event count matches `initialSession.streamIndex`, catch-up continues from that cursor. A partial or overlapping saved log falls back to index `0`. Every event carries a stable [`meta.id`](/docs/concepts/sessions-runs-and-streaming#the-event-envelope), and the store drops any event whose id it has already applied, so an overlapping replay renders once and `onEvent` only fires for events your UI has not seen.
 
-For multiple chat threads, keep one saved event log and session cursor per thread. `agent`, `host`, `reducer`, `session`, `initialEvents`, `initialSession`, `auth`, `headers`, `optimistic`, and `resume` are read when the hook creates its store, so remount the chat component when switching threads, for example with `key={chat.id}`.
+For multiple chat threads, keep one saved event log and session cursor per thread. `agent`, `host`, `reducer`, `session`, `initialEvents`, `initialSession`, `auth`, `headers`, `optimistic`, `prewarm`, and `resume` are read when the hook creates its store, so remount the chat component when switching threads, for example with `key={chat.id}`.
 
-Pass `resume: true` with `initialSession` to rebuild the projection from the durable stream after mount. While `status` is `"resuming"`, render hydrated `data` but disable message and HITL submission; do not present cancellation or active-turn progress controls. If catch-up finds an in-flight turn, `status` changes to `"streaming"` before the binding follows it to a boundary. A settled tail changes directly to `"ready"` after a bounded catch-up check, without waiting for the live stream idle timeout. If that check finds a newly started turn or pending authorization, eve keeps following it. A terminal session failure changes to `"error"`.
+Pass `resume: true` with `initialSession` to rebuild the projection from the durable stream after mount. While `status` is `"resuming"`, render hydrated `data` but disable message and HITL submission; do not present cancellation or active-turn progress controls. If catch-up finds an in-flight turn, `status` changes to `"streaming"` before the binding follows it to a boundary. The stream reports its initial durable tail so catch-up can finish without closing the connection or waiting for an idle timeout. A settled tail changes directly to `"ready"`; a newer turn or pending authorization remains `"streaming"`. The connection stays open to receive later events. A terminal session failure changes to `"error"`.
 
 ```tsx
 const agent = useEveAgent({
@@ -332,6 +377,10 @@ const agent = useEveAgent({
 });
 ```
 
+Headers supplied to `send()` apply to that turn request and become the credentials used by the
+continuous session stream on its next reconnect. A later send replaces them with that turn's
+headers.
+
 When a framework integration mounts multiple named agents, pass `agent` instead of `host`:
 
 ```tsx

package/docs/guides/frontend/use-eve-agent-svelte.mdx

@@ -45,14 +45,14 @@ Call the binding once for a conversation and read its reactive getters directly.
 
 The state fields are reactive getters; the commands are ordinary methods:
 
-| Property                                       | Svelte shape                      |
-| ---------------------------------------------- | --------------------------------- |
-| `data`                                         | `TData`                           |
-| `status`                                       | `UseEveAgentStatus`               |
-| `error`                                        | `Error \| undefined`              |
-| `events`                                       | `readonly MessageStreamEvent[]`   |
-| `session`                                      | `ClientSessionState \| undefined` |
-| `send`, `respond`, `resume`, `cancel`, `reset` | Methods                           |
+| Property                                                  | Svelte shape                      |
+| --------------------------------------------------------- | --------------------------------- |
+| `data`                                                    | `TData`                           |
+| `status`                                                  | `UseEveAgentStatus`               |
+| `error`                                                   | `Error \| undefined`              |
+| `events`                                                  | `readonly MessageStreamEvent[]`   |
+| `session`                                                 | `ClientSessionState \| undefined` |
+| `send`, `respond`, `prewarm`, `resume`, `cancel`, `reset` | Methods                           |
 
 Read the getters directly in templates, `$derived`, or `$effect`. The [shared returned-state reference](./overview#returned-state) describes what each value and command does.
 
@@ -107,6 +107,11 @@ See [Human-in-the-loop prompts](./overview#human-in-the-loop-prompts) for reques
 
 ## Cancel, reset, and resume
 
+Pass `prewarm: true` to prepare an owned workflow on mount and after reset. It defaults
+to `false`, so the first send creates the session. The binding waits for create acceptance,
+retries while the inbox starts, and keeps the session stream open across turns. See [Prewarming and returned state](./overview#returned-state) for creation, failure, and
+connection behavior.
+
 Call `agent.cancel()` to stop the durable server-side turn while the binding remains attached through settlement. Destroying the component only disconnects its local stream; it does not cancel server execution. Call `agent.reset()` to clear local state and start a new session. Pass `initialSession`, `initialEvents`, and `resume: true` to restore a saved conversation and follow an in-flight turn. During bounded catch-up, `agent.status` is `"resuming"`; keep the hydrated conversation visible, disable submission, and wait for `"ready"`, `"error"`, or `"streaming"`. Use `agent.resume()` directly when restoration is controlled imperatively. See [Resumable sessions](./overview#resumable-sessions) for the persistence contract and [Sending and streaming](./overview#sending-and-streaming) for cancellation behavior.
 
 ## Custom host and credentials

package/docs/guides/frontend/use-eve-agent-vue.mdx

@@ -44,14 +44,14 @@ async function handleSubmit() {
 
 The state fields are computed refs; the commands are ordinary methods:
 
-| Property                                       | Vue shape                                      |
-| ---------------------------------------------- | ---------------------------------------------- |
-| `data`                                         | `ComputedRef<TData>`                           |
-| `status`                                       | `ComputedRef<UseEveAgentStatus>`               |
-| `error`                                        | `ComputedRef<Error \| undefined>`              |
-| `events`                                       | `ComputedRef<readonly MessageStreamEvent[]>`   |
-| `session`                                      | `ComputedRef<ClientSessionState \| undefined>` |
-| `send`, `respond`, `resume`, `cancel`, `reset` | Methods                                        |
+| Property                                                  | Vue shape                                      |
+| --------------------------------------------------------- | ---------------------------------------------- |
+| `data`                                                    | `ComputedRef<TData>`                           |
+| `status`                                                  | `ComputedRef<UseEveAgentStatus>`               |
+| `error`                                                   | `ComputedRef<Error \| undefined>`              |
+| `events`                                                  | `ComputedRef<readonly MessageStreamEvent[]>`   |
+| `session`                                                 | `ComputedRef<ClientSessionState \| undefined>` |
+| `send`, `respond`, `prewarm`, `resume`, `cancel`, `reset` | Methods                                        |
 
 Destructuring preserves reactivity because each state value remains a ref. Read refs with `.value` in `<script>` and without `.value` in a template. The [shared returned-state reference](./overview#returned-state) describes what each value and command does.
 
@@ -109,6 +109,11 @@ See [Human-in-the-loop prompts](./overview#human-in-the-loop-prompts) for reques
 
 ## Cancel, reset, and resume
 
+Pass `prewarm: true` to prepare an owned workflow on mount and after reset. It defaults
+to `false`, so the first send creates the session. The binding waits for create acceptance,
+retries while the inbox starts, and keeps the session stream open across turns. See [Prewarming and returned state](./overview#returned-state) for creation, failure, and
+connection behavior.
+
 Call `cancel()` to stop the durable server-side turn while the composable remains attached through settlement. Disposing the component only disconnects its local stream; it does not cancel server execution. Call `reset()` to clear local state and start a new session. Pass `initialSession`, `initialEvents`, and `resume: true` to restore a saved conversation and follow an in-flight turn. During bounded catch-up, `status.value` is `"resuming"`; keep the hydrated conversation visible, disable submission, and wait for `"ready"`, `"error"`, or `"streaming"`. Use `resume()` directly when restoration is controlled imperatively. See [Resumable sessions](./overview#resumable-sessions) for the persistence contract and [Sending and streaming](./overview#sending-and-streaming) for cancellation behavior.
 
 ## Custom host and credentials

package/docs/guides/remote-agents.md

@@ -29,6 +29,7 @@ export default defineRemoteAgent({
 | `headers`          | `HeadersValue`                                | No       | none              | Static or lazily resolved request headers.                                                                                                               |
 | `path`             | `string`                                      | No       | `/eve/v1/session` | Route appended to `url` for the create-session request.                                                                                                  |
 | `outputSchema`     | `StandardSchema \| JSON Schema`               | No       | none              | Structured return type for the first turn of each fresh remote session. A continuation may provide its own per-call schema.                              |
+| `tool`             | `boolean`                                     | No       | `true`            | Expose the remote agent as a tool to the parent model. Set `false` to allow only `ctx.agent()` calls from authored workflow tools.                       |
 
 ## Dynamic remote agents
 
@@ -80,7 +81,7 @@ The function may be async and must return a non-empty string. `auth` and `header
 
 ## Calling a remote agent
 
-To the model, a remote agent is another subagent tool. You call it the same way you call a local subagent, with a `message` and an optional `outputSchema`. The message must carry the full task, including any context the remote agent needs, because it never receives the parent's conversation history.
+By default, a remote agent is another subagent tool to the model. The model calls it the same way it calls a local subagent, with a `message` and an optional `outputSchema`. Set `tool: false` when an authored workflow tool should be the only model-facing routing surface; the workflow can still call the remote agent by its path-derived name through `ctx.agent()`. The message must carry the full task, including any context the remote agent needs, because it never receives the parent's conversation history.
 
 To require structured output, set an `outputSchema` on the agent definition for fresh delegations or on an individual call for that turn. The structured value arrives in the task's completion notification, and the remote child remains available for follow-up messages. See [Subagents](../subagents) for continuation behavior.