eve 0.71.2 → 0.72.0

package/docs/channels/eve.mdx

@@ -18,6 +18,71 @@ export default eveChannel({
 });
 ```
 
+## Web Chat with Sign in with Vercel
+
+Run `eve add channel/web`, or select **Web Chat** from the terminal UI's channel
+picker. Choose a hosting layout, then **Sign in with Vercel**. Setup uses a
+linked Vercel project and creates a Vercel App that only members of that
+project's team can sign in to.
+
+For a new agent, initialize it first, then link a project and add Web Chat:
+
+```bash
+eve init my-agent --non-interactive
+cd my-agent
+eve link
+eve add channel/web
+```
+
+`eve init --channel-web-nextjs` keeps its existing scaffolding behavior and does
+not provision authentication. Sign-in setup runs through `eve add channel/web`
+or the terminal UI's channel picker.
+
+The generated Next.js app uses Better Auth sessions. The selected agent's HTTP
+channel verifies the same session, while retaining Vercel OIDC and local
+development access. In an agent workspace, setup configures only the selected
+agent. Other agents keep their own authentication policies.
+
+Setup registers `/api/auth/callback/vercel` as a project redirect URI, so Vercel
+validates callbacks against the project's deployment domains. The app uses the
+`authorization_code` grant, `client_secret_post` authentication, and the
+`openid`, `email`, and `profile` scopes. Setup writes `VERCEL_APP_CLIENT_ID`,
+`VERCEL_APP_CLIENT_SECRET`, and `BETTER_AUTH_SECRET` to production and preview;
+secret values are marked sensitive and are never printed or written to source.
+Run `eve deploy` after setup to publish the app. Local development continues
+without browser sign-in.
+
+For automation, supply the setup answers explicitly:
+
+```bash
+eve add channel/web --non-interactive \
+  --answer 'web-hosting="vercel"' \
+  --answer 'web-authentication="vercel"'
+```
+
+Use a linked project with permission to manage Vercel Apps and project
+environment variables. A team owner can complete setup if your role cannot
+create apps. The searchable team picker lists eligible teams first. Disabled
+teams show `needs permission` or `couldn't verify`, with shared recovery guidance
+below the list. If permissions cannot be verified, that team stays
+disabled until you sign in or retry. Linked projects are checked before
+interactive auth setup.
+If setup reports a missing prerequisite, complete it and resume with
+`eve add channel/web --skip-install`. Compatible existing apps
+and credentials are reused; conflicting app settings or credentials stop setup
+with an error. Authored channel or UI files are preserved unless you explicitly
+pass `--overwrite`.
+
+If the team has reached its Vercel App limit, remove an unused app in team
+settings and retry. If a generated app name or slug is taken by an incompatible
+app, rename the Vercel project in its settings and retry. Compatible apps from a
+concurrent setup are reused. A client-secret limit requires removing an unused
+secret from the app's settings; setup never removes an existing secret for you.
+
+Choose **Configure authentication myself** (`web-authentication=custom`) to
+keep the current channel policy. The default placeholder rejects production
+browser requests until you configure your own authentication.
+
 ## Routes
 
 The default eve channel inspects the agent, creates sessions, accepts callbacks and task input, controls sessions, and streams events. Its public routes include:

package/docs/channels/linear.mdx

@@ -95,7 +95,7 @@ Start a session without an inbound webhook with `receive(linear, { target })`. S
 
 ### Attachments
 
-Markdown images hosted at `https://uploads.linear.app` in Agent Session prompts are fetched with the resolved Linear access token and included as image file parts. eve sends the bearer token only to that exact HTTPS origin; images from other hosts remain markdown text. If a Linear upload fails or returns non-image content, eve preserves its markdown reference and continues the text turn. Other inbound file attachments are not supported on this channel today.
+Files uploaded to Linear and referenced in an Agent Session prompt, whether as markdown images (`![name](url)`) or file links (`[name](url)`) hosted at `https://uploads.linear.app`, are fetched with the resolved Linear access token and included as file parts. eve sends the bearer token only to that exact HTTPS origin; images and links from other hosts remain markdown text. If a Linear upload fails, an image reference returns non-image content, or a file link returns an HTML page, the reference becomes its label in the text, the agent gets a short note that the file couldn't be retrieved, and the text turn continues.
 
 ### API handle
 

package/docs/channels/linq.mdx

@@ -20,6 +20,8 @@ The default webhook route is `/eve/v1/linq`. The channel verifies forwarded webh
 
 Set `turnPolicy: "queue"` when every response should finish before Linq starts the next message.
 
+Images and other files people send reach the agent as file parts. eve downloads each one from Linq's CDN and passes the bytes; a failed download, or a file over 25 MB, reaches the agent as a short note.
+
 Customize inbound dispatch with `onMessage`. Return `null` to ignore a message, or return `title` alongside `auth` to set the title when the dispatch starts a run:
 
 ```ts

package/docs/channels/mcp.mdx

@@ -3,7 +3,7 @@ title: "MCP Channel"
 description: "Publish an eve agent as an MCP server with auth support."
 ---
 
-The MCP channel lets clients such as Claude Code delegate durable work to an eve agent through four tools: `agent_start`, `agent_get`, `agent_update`, and `agent_cancel`.
+The MCP channel lets clients such as Claude Code delegate durable work to an eve agent through four tools: `agent_start`, `agent_get`, `agent_update`, and `agent_cancel`. It can also publish the agent's own tools, so a client calls them directly; see [Publish the agent's tools](#publish-the-agents-tools).
 
 Use an [MCP connection](../connections/mcp) instead when your eve agent needs to call someone else's MCP server.
 
@@ -211,6 +211,44 @@ Requests are bounded: the whole MCP request body is limited to 1 MiB, `message`
 - `agent_update` answers one pending batch. Re-sending the same answers after eve has accepted them returns the current invocation state; sending different answers for an already-answered batch is a conflict.
 - `agent_cancel` is cooperative and can race with completion. Poll `agent_get` until the status is terminal (`cancelled`, `completed`, or `failed`), not specifically `cancelled`.
 
+## Publish the agent's tools
+
+By default the channel serves only the `agent_*` tools. Set `tools: true` to also publish every tool the agent can run outside a conversation, and `agent: false` to stop serving the `agent_*` tools:
+
+```ts title="agent/channels/mcp.ts"
+import { localDev } from "eve/channels/auth";
+import { mcpChannel } from "eve/channels/mcp";
+
+export default mcpChannel({
+  auth: localDev(),
+  tools: true,
+});
+```
+
+`tools/list` returns the `agent_*` tools first, then the agent's tools in name order with their input and output JSON schemas. Framework tools, workflow and provider tools, tools without `execute`, and tools added by dynamic resolvers or subagents are not published. While `agent` is on, an agent tool named `agent_start`, `agent_get`, `agent_update`, or `agent_cancel` is not published, and eve logs a warning. With `agent: false`, the channel sends no `agent_*` instructions. Turning off both `agent` and `tools` throws.
+
+Each `tools/call` checks the arguments against the tool's input schema, then runs the tool as the route-authenticated caller, with no model, turn, or workflow run. Every caller the channel's `auth` admits can call these tools, outside the agent's instructions, so review what becomes callable before you turn this on. Each call gets its own session:
+
+- Authored state starts from its initial value, and updates are not kept.
+- A sandbox the tool opens is deleted when the call ends.
+- Calls may run in parallel, and a call retried after a lost response runs again.
+
+A tool that cannot finish over MCP returns an error result with `isError: true` and a `structuredContent.error.code`:
+
+| Code                     | When                                                                                             |
+| ------------------------ | ------------------------------------------------------------------------------------------------ |
+| `invalid_input`          | The tool rejected its input.                                                                     |
+| `denied`                 | The tool's approval policy denied the call.                                                      |
+| `approval_required`      | The approval policy asks a person. The tool did not run; call it from a conversation instead.    |
+| `authorization_required` | The tool needs a sign-in to a connection first. Sign in from a conversation, then call it again. |
+| `internal`               | The tool failed. The message carries an error id that matches the server logs.                   |
+
+### Trace context
+
+MCP clients send W3C trace context in each request's `params._meta`, not in HTTP headers. When a request carries a valid `_meta.traceparent`, that span becomes the parent of everything the request runs, including a published tool's `execute_tool` span. It takes precedence over any parent your platform extracted from the HTTP request's headers. A missing, malformed, or all-zero `traceparent` leaves that parent in place. `_meta.tracestate` is kept only alongside a valid `_meta.traceparent` and only up to 512 characters; a longer value is dropped.
+
+`_meta.baggage` is never read. A caller cannot choose the trace audience, session lineage, or content capture: those come from the channel and your `tracePolicy`, as they do for conversations. The `execute_tool` span records the call's arguments and result only when that content decision allows it, and never records exception text.
+
 ## Invocation ownership
 
 Every MCP operation reruns the configured auth policy. With authenticated policies, an invocation belongs to the principal that started it; knowing its ID is not sufficient. Bearer tokens are not stored with the invocation or forwarded to the agent's tools.

package/docs/channels/photon.mdx

@@ -32,6 +32,11 @@ boundary. See [Overlapping messages](./overview#overlapping-messages).
 
 Set `turnPolicy: "queue"` when every response should finish before Photon starts the next message.
 
+Images and other files people send reach the agent as file parts. Photon's
+webhook lists each file without its bytes, so eve downloads it from Photon by
+its attachment id with the project's credentials. A failed download, or a file
+over 25 MB, reaches the agent as a short note.
+
 Customize inbound dispatch with `onMessage`. Return `null` to ignore a message, or return `title` alongside `auth` to set the title when the dispatch starts a run:
 
 ```ts

package/docs/channels/teams.mdx

@@ -95,19 +95,16 @@ Proactive sessions need an existing conversation reference, because the Bot Fram
 
 ### Attachments
 
-Inbound files are off by default. Opt in to allow personal-scope downloads and public media URLs:
+Inbound files reach the agent as file parts. eve downloads images pasted into a message from Microsoft Bot Connector hosts with your bot credentials, and files uploaded in a personal chat from their pre-authenticated SharePoint download URL (`*.sharepoint.com` or `*.sharepoint.us`). A failed download, or one over the upload limit (25 MB unless `files.uploadPolicy` sets `maxBytes`), reaches the agent as a short note. Personal-chat uploads need `supportsFiles: true` on the bot in your Teams app manifest.
+
+Use `allowedHosts` to download from other hosts, unauthenticated, or `enabled: false` to drop attachments:
 
 ```ts
 export default teamsChannel({
-  files: {
-    enabled: true,
-    allowedHosts: ["smba.trafficmanager.net", "contoso.sharepoint.com"],
-  },
+  files: { allowedHosts: ["files.contoso.com"] },
 });
 ```
 
-eve authenticates downloads from Microsoft Bot Connector hosts with your bot credentials. Downloads from other allowlisted hosts remain unauthenticated.
-
 ## What to read next
 
 - [Channels overview](./overview): the channel contract and every built-in channel

package/docs/channels/twilio.mdx

@@ -70,7 +70,7 @@ Start a session without an inbound message through `to(twilio, target).send(mess
 
 ### Attachments
 
-Inbound media attachments are not supported on this channel today.
+MMS media reaches the agent as file parts. eve downloads each media URL with the account SID and auth token, and only from the Twilio API origin (`https://api.twilio.com`, or `api.apiBaseUrl` when set). If a download fails, the agent gets a short note in place of the file and the text turn continues.
 
 ## Disclaimer
 

package/docs/concepts/built-in-tools.md

@@ -208,6 +208,18 @@ import { webSearch } from "eve/tools/web_search";
 export default webSearch({ provider: "parallel" });
 ```
 
+Select Browserbase Search in the same slot:
+
+```ts title="agent/tools/web_search.ts"
+import { webSearch } from "eve/tools/web_search";
+
+export default webSearch({ provider: "browserbase" });
+```
+
+Use a [Gateway model ID](../agent-config#set-the-model) to route searches through Browserbase. AI Gateway executes the search using `AI_GATEWAY_API_KEY` or Vercel project OIDC credentials; no `BROWSERBASE_API_KEY` is needed. See [Browserbase Search on AI Gateway](https://vercel.com/docs/ai-gateway/models-and-providers/web-search#using-browserbase-search).
+
+The `provider` setting applies only to AI Gateway models. Unsupported direct providers omit `web_search`.
+
 Replace provider-managed search with an authored implementation:
 
 ```ts title="agent/tools/web_search.ts"

package/docs/concepts/sessions-runs-and-streaming.md

@@ -127,11 +127,11 @@ A question or sign-in from inside a running call does not end the turn. This cov
 
 ### Task events
 
-A call to a tool that runs as a task, such as an agent tool, `agentRouter()`, the `workflow` tool, or a workflow tool that defines [`task(input, ctx)`](/docs/tools/workflows#run-calls-as-tasks-task) or [`serve(receive, ctx)`](/docs/tools/workflows#resumable-tasks-serve), returns a receipt as its `action.result` and keeps working. `task.started` reports the task's `taskId` for the call's `callId` and `turnId`, both when a call starts a task and when a call reaches a resumable task by its `taskId`, before any event the task's run publishes for that call. `task.settled` comes once per call, with the same `turnId`, `name`, and `kind` as its `task.started`, `status` `"completed"`, `"failed"`, or `"cancelled"`, and the call's `output` when it completed or `error.message` when it failed. Events recorded by earlier eve versions omit `name` and `kind` on `task.settled`, so match them to their `task.started` by `callId` when those fields are missing. Results reach the model as a message in its history, not as a stream event, so read outcomes from `task.settled`. A session the task's run opens with `ctx.agent` is announced with `agent.started` carrying the `taskId`. An `input.requested`, `authorization.required`, or `authorization.completed` event from a task's run carries its `taskId`. Each of these events names the call the task is serving when it happens: a resumable task's later call brings its own `callId` and `turnId`, which may belong to a later turn than the call that started the task.
+A call to a tool that runs as a task, such as an agent tool, `agentRouter()`, the `workflow` tool, or a workflow tool that defines [`task(input, ctx)`](/docs/tools/workflows#run-calls-as-tasks-task) or [`serve(receive, ctx)`](/docs/tools/workflows#resumable-tasks-serve), returns a receipt as its `action.result` and keeps working. `task.started` reports the task's `taskId` for the call's `callId` and `turnId`, both when a call starts a task and when a call reaches a resumable task by its `taskId`, before any event the task's run publishes for that call. `task.settled` comes once per call, with the same `turnId`, `name`, and `kind` as its `task.started`, `status` `"completed"`, `"failed"`, or `"cancelled"`, and the call's `output` when it completed or `error.message` when it failed. Events recorded by earlier eve versions omit `name` and `kind` on `task.settled`, so match them to their `task.started` by `callId` when those fields are missing. Results reach the model as a message in its history, not as a stream event, so read outcomes from `task.settled`. A session the task's run opens with `ctx.agent` is announced with `agent.started` carrying the `taskId`. An `input.requested`, `authorization.required`, or `authorization.completed` event from a task's run carries its `taskId`. Each of these events names the call the task is serving when it happens: a resumable task's later call brings its own `callId` and `turnId`, which may belong to a later turn than the call that started the task. An `input.requested` relayed from a subagent or a workflow tool run also carries `callId`, the call in this session that the request serves. The request keeps the coordinates it was raised with, and a relayed approval's `request.action.callId` still names the asking run's call, not one of this session's.
 
 A turn doesn't end while tasks are working. When the model ends its text early, eve holds the turn and the stream emits `turn.waiting` for it; the turn continues once a result arrives or its caller writes. In a root session, that text completes as an ordinary `message.completed`. In a child session or a schedule's session, it reports `finishReason: "tool-calls"`, so channels post only the final reply. When the model calls `task_wait` and no result is ready yet, the stream also emits `turn.waiting`. Either way, the next `step.started` for the same `turnId` means the turn resumed, and `session.waiting` comes only after the turn ends. See [Tasks](/docs/tools/tasks#turns-wait-for-their-tasks).
 
-`step.failed` and `turn.failed` carry `{ code, message, details? }` for the failed fragment or turn, and `session.failed` is the terminal session-level variant. `turn.cancelled` is not a failure: the cancelled turn ends without any failure event, `session.waiting` follows, and the session accepts the next message normally. Whatever the turn streamed before cancellation stays on the stream. Durable history keeps the accepted user input and previously settled work, and discards incomplete assistant output. Tool calls the cancellation stopped stay in history, each answered as cancelled, so the model sees that the work started and stopped instead of a request left unanswered. When a turn requested an output schema, the finalized payload lands on `result.completed` as `data.result` before the turn boundary. `authorization.required` carries the sign-in challenge (`data.authorization` may include `url`, `userCode`, `expiresAt`, `instructions`), and `authorization.completed` carries `data.outcome` (`"authorized" | "declined" | "failed" | "timed-out"`). Both carry `data.principalId` when a session principal started the sign-in. It holds the same value as `responderPrincipalId` on approval events, so a channel can deliver the challenge privately to that person even after someone else starts a later turn.
+`step.failed` and `turn.failed` carry `{ code, message, details? }` for the failed fragment or turn, and `session.failed` is the terminal session-level variant. `turn.cancelled` is not a failure: the cancelled turn ends without any failure event, `session.waiting` follows, and the session accepts the next message normally. Whatever the turn streamed before cancellation stays on the stream. Durable history keeps the accepted user input and previously settled work, and discards incomplete assistant output. Tool calls the cancellation stopped stay in history, each answered as cancelled, so the model sees that the work started and stopped instead of a request left unanswered. Before `turn.cancelled`, the stream reports requests the cancel strands as `cancelled` in `input.resolved`. These include the turn's own questions, the session-limit prompt, and requests relayed from the work it stops. When a turn requested an output schema, the finalized payload lands on `result.completed` as `data.result` before the turn boundary. `authorization.required` carries the sign-in challenge (`data.authorization` may include `url`, `userCode`, `expiresAt`, `instructions`), and `authorization.completed` carries `data.outcome` (`"authorized" | "declined" | "failed" | "timed-out"`). Both carry `data.principalId` when a session principal started the sign-in. It holds the same value as `responderPrincipalId` on approval events, so a channel can deliver the challenge privately to that person even after someone else starts a later turn.
 
 A provider response ending with `content-filter` fails with `MODEL_CALL_FAILED`,
 `details.semanticErrorId: "model-response-content-filtered"`, and
@@ -261,7 +261,7 @@ curl -X POST http://127.0.0.1:2000/eve/v1/session/<sessionId>/reset \
 
 Compaction summarizes context without adding a user message. User-role instructions are ordinary history and may be represented by the summary; system-role instructions remain outside it. Attributed [memory](../memory) records are excluded from the summary, canonicalized, and recalled again after the checkpoint. If a turn is active, eve queues the request until that turn settles. A successful compaction emits `compaction.requested` and `compaction.completed`, followed by `session.waiting`; if summarization fails before a checkpoint, the session returns to waiting with its previous history.
 
-Clear removes model-message history in place, including static and dynamic user-role instructions and recalled memory records, while preserving the session identity, system-role instructions, tools, skills, application-defined durable state, limits, and sandbox. It clears framework memory locks and replay bookkeeping but does not delete data from a provider's external store. It does not rerun instruction definitions or resolvers. It emits `context.cleared` followed by `session.waiting`.
+Clear removes model-message history in place, including static and dynamic user-role instructions and recalled memory records, while preserving the session identity, system-role instructions, tools, skills, application-defined durable state, limits, and sandbox. It clears framework memory locks and replay bookkeeping but does not delete data from a provider's external store. It does not rerun instruction definitions or resolvers. Approvals, the session-limit prompt, and sign-ins the cleared history asked for are withdrawn: each resolves as `cancelled` in `input.resolved` or `declined` in `authorization.completed`. Requests relayed from tasks that keep running stay answerable. It then emits `context.cleared` followed by `session.waiting`.
 
 Reset terminally retires the exact session ID. A reset ID never becomes a new session; create another session explicitly for a fresh conversation. Compact, clear, and reset return `"no_active_session"` when the target is already inactive.
 

package/docs/connections/overview.mdx

@@ -194,7 +194,7 @@ export default defineMcpClientConnection({
 });
 ```
 
-`never()` lets every call through, `once()` asks for approval the first time in a session, `always()` asks every time, and `auto()` uses an evaluation model to allow routine calls and ask about dangerous or unclear effects. The pause and resume is the same human-in-the-loop flow covered in [Tools](/docs/tools).
+`never()` lets every call through, `once()` asks for approval the first time in a session, `always()` asks every time, and `auto()` uses a decision model to allow routine calls and ask about dangerous or unclear effects. The pause and resume is the same human-in-the-loop flow covered in [Tools](/docs/tools).
 
 For connection tools that can create, modify, delete, transmit, purchase, message, or access sensitive data, use approval, allow-lists, or other safeguards appropriate to the action.
 

package/docs/dynamic-configuration/meta.json

@@ -1,5 +1,5 @@
 {
   "title": "Dynamic Capabilities",
   "defaultOpen": false,
-  "pages": ["../guides/dynamic-capabilities", "../guides/evaluate"]
+  "pages": ["../guides/dynamic-capabilities", "../guides/decide"]
 }

package/docs/evals/judge.mdx

@@ -1,9 +1,9 @@
 ---
 title: "Judge"
-description: "Grade evals with evaluation models using criteria, typed questions, or batches, and set thresholds on each assertion."
+description: "Grade evals with decision models using criteria, typed questions, or batches, and set thresholds on each assertion."
 ---
 
-Use `t.judge(...)` when a deterministic [assertion](./assertions) cannot capture what a good response looks like. It calls [`evaluate` from `eve/ai`](../guides/evaluate#evaluate-inside-a-tool) and defaults to `typesafe-ai/jev`, TypeSafe AI's [Jev evaluation model](https://vercel.com/i/what-is-jev). The judge is separate from the agent under test and is used only for scoring.
+Use `t.judge(...)` when a deterministic [assertion](./assertions) cannot capture what a good response looks like. It calls [`decide` from `eve/ai`](../guides/decide#decide-inside-a-tool) and defaults to `typesafe-ai/jev`, TypeSafe AI's [Jev decision model](https://vercel.com/i/what-is-jev). The judge is separate from the agent under test and is used only for scoring.
 
 ```ts
 import { defineEval } from "eve/evals";
@@ -17,7 +17,7 @@ export default defineEval({
 });
 ```
 
-No judge configuration is required. Configure credentials for the evaluator as described under [Configuring the judge model](#configuring-the-judge-model).
+No judge configuration is required. Configure credentials for the decider as described under [Configuring the judge model](#configuring-the-judge-model).
 
 ## The graders
 
@@ -41,11 +41,11 @@ t.judge({
   .atLeast(0.75);
 ```
 
-Choice questions require an `expected` option key. eve uses that expectation locally for scoring; it does not send it to the evaluator. Instructions and rubric descriptions accept strings, JSON objects, or JSON arrays. Descriptions can also be `null`.
+Choice questions require an `expected` option key. eve uses that expectation locally for scoring; it does not send it to the decider. Instructions and rubric descriptions accept strings, JSON objects, or JSON arrays. Descriptions can also be `null`.
 
 ## Choose the value to grade
 
-By default, the evaluator receives `{ input, output }`: the latest prompt and assistant message from the session whose turn most recently settled. Approval responses and stream reads preserve that prompt. For multipart messages, including `session.sendFile()`, the prompt contains the text parts.
+By default, the decider receives `{ input, output }`: the latest prompt and assistant message from the session whose turn most recently settled. Approval responses and stream reads preserve that prompt. For multipart messages, including `session.sendFile()`, the prompt contains the text parts.
 
 Pass `on` to replace the output. JSON values stay structured rather than being converted to strings:
 
@@ -66,9 +66,9 @@ t.judge("The assistant remembers the user's favorite word across turns.", {
 
 The transcript contains user and assistant messages in turn order, excluding reasoning, tool calls, and tool results. See [Multi-turn evals](./cases#multi-turn-evals).
 
-## Evaluate several questions together
+## Decide several questions together
 
-A batch makes one evaluation request against one shared state. Pass `state` to replace the default `{ input, output }` completely. Batch calls use `state` instead of `on`.
+A batch makes one decision request against one shared state. Pass `state` to replace the default `{ input, output }` completely. Batch calls use `state` instead of `on`.
 
 ```ts
 const judgments = t.judge({
@@ -120,9 +120,9 @@ Model settings resolve in this order:
 1. Per-call: `t.judge("…", { model, modelOptions })`.
 2. Per-eval: `defineEval({ judge: { model, modelOptions }, test })`.
 3. Project default: `defineEvalConfig({ judge: { model, modelOptions } })`.
-4. The default model used by `evaluate`, currently `typesafe-ai/jev`.
+4. The default model used by `decide`, currently `typesafe-ai/jev`.
 
-A per-eval `judge` replaces the project's judge configuration. Per-call fields override the resolved configuration. `judge` and its `model` are optional; deterministic evals make no evaluation requests.
+A per-eval `judge` replaces the project's judge configuration. Per-call fields override the resolved configuration. `judge` and its `model` are optional; deterministic evals make no decision requests.
 
 ```ts title="evals/evals.config.ts"
 import { defineEvalConfig } from "eve/evals";
@@ -132,30 +132,30 @@ export default defineEvalConfig({
 });
 ```
 
-String IDs resolve through the AI SDK default provider, or Vercel AI Gateway when none is configured. Gateway uses `AI_GATEWAY_API_KEY` or Vercel OIDC credentials; eve's existing local Gateway connection is also honored by `evaluate`. An explicit provider evaluation model uses that provider's credentials:
+String IDs resolve through the AI SDK default provider, or Vercel AI Gateway when none is configured. Gateway uses `AI_GATEWAY_API_KEY` or Vercel OIDC credentials; eve's existing local Gateway connection is also honored by `decide`. An explicit provider decision model uses that provider's credentials:
 
 ```ts
 import { openai } from "@ai-sdk/openai";
 
 t.judge("The response addresses the request.", {
-  model: openai.evaluationModel("gpt-6-luna"),
+  model: openai.decisionModel("gpt-6-luna"),
   modelOptions: { providerOptions: { openai: { reasoningEffort: "high" } } },
 });
 ```
 
-Use the provider's `evaluationModel` factory, not a language model instance. AI SDK supplies evaluation adapters for supported language models. Provider support and the evaluation contract are experimental; see [AI SDK evaluation](https://ai-sdk.dev/docs/ai-sdk-core/evaluation).
+Use the provider's `decisionModel` factory, not a language model instance. AI SDK supplies decision adapters for supported language models. Provider support and the decision contract are experimental; see [AI SDK decision](https://ai-sdk.dev/docs/ai-sdk-core/decisions).
 
-String model IDs resolve through the default provider's evaluation API. Gateway accepts native evaluation models such as `typesafe-ai/jev`; passing a language model ID such as `openai/gpt-6-luna` does not automatically select the OpenAI adapter. Use an evaluation-model instance as shown above for language models.
+String model IDs resolve through the default provider's decision API. Gateway accepts native decision models such as `typesafe-ai/jev`; passing a language model ID such as `openai/gpt-6-luna` does not automatically select the OpenAI adapter. Use a decision-model instance as shown above for language models.
 
-Missing credentials, invalid answers, unsupported question types, and provider errors become failed gates even for tracked-only judgments. They do not silently skip the eval or select another model. Validation, authentication, and retries use the shared `evaluate` implementation.
+Missing credentials, invalid answers, unsupported question types, and provider errors become failed gates even for tracked-only judgments. They do not silently skip the eval or select another model. Validation, authentication, and retries use the shared `decide` implementation.
 
 ## Diagnostics and migration
 
-Reports use `judge.boolean`, `judge.score`, and `judge.choice`; batch assertion names also include their question key. Diagnostics include the captured state, question, and raw answer. Assertion metadata retains the normalized score, model identity, token usage, warnings, and available provider and response metadata. Usage for a batch is marked as shared across its assertions, not a separate charge for each question. Evaluation models do not promise a prose rationale.
+Reports use `judge.boolean`, `judge.score`, and `judge.choice`; batch assertion names also include their question key. Diagnostics include the captured state, question, and raw answer. Assertion metadata retains the normalized score, model identity, token usage, warnings, and available provider and response metadata. Usage for a batch is marked as shared across its assertions, not a separate charge for each question. Decision models do not promise a prose rationale.
 
 The autoevals graders have been removed. Replace `t.judge.autoevals.closedQA(criteria, options)` with `t.judge(criteria, options)`. Scores now represent a probability rather than a binary yes/no answer, so review thresholds against your examples. For factuality, summaries, or SQL equivalence, write an explicit question and include the reference in shared state. No old grader buckets are preserved.
 
-Change configured language model instances to evaluation model instances. `modelOptions.providerOptions`, assertion labels, and threshold methods remain available. [Braintrust reporting](./reporters) continues to accept judge scores independently of the grader implementation.
+Change configured language model instances to decision model instances. `modelOptions.providerOptions`, assertion labels, and threshold methods remain available. [Braintrust reporting](./reporters) continues to accept judge scores independently of the grader implementation.
 
 ## What to read next
 

package/docs/evals/overview.mdx

@@ -56,7 +56,7 @@ export default defineEvalConfig({
 });
 ```
 
-Everything is optional. `judge` sets the default model for [LLM-as-judge](./judge) assertions (`t.judge(...)`); omit it to use the default evaluator, `typesafe-ai/jev`. Deterministic evals make no judge requests. `reporters`, `maxConcurrency`, and `timeoutMs` round out the defaults. Config `reporters` observe every eval in the run, so set one `Braintrust()` here instead of adding it to each eval. CLI flags (`--max-concurrency`, `--timeout`) and per-eval values take precedence over the config defaults.
+Everything is optional. `judge` sets the default model for [LLM-as-judge](./judge) assertions (`t.judge(...)`); omit it to use the default decider, `typesafe-ai/jev`. Deterministic evals make no judge requests. `reporters`, `maxConcurrency`, and `timeoutMs` round out the defaults. Config `reporters` observe every eval in the run, so set one `Braintrust()` here instead of adding it to each eval. CLI flags (`--max-concurrency`, `--timeout`) and per-eval values take precedence over the config defaults.
 
 ### Run setup and teardown
 

package/docs/guides/{evaluate.md → decide.md}

@@ -1,21 +1,21 @@
 ---
 title: Automatic Model Selection
-description: "Choose agent models automatically or evaluate typed questions in your tools and application code."
+description: "Choose agent models automatically or ask typed questions in your tools and application code."
 ---
 
 Use `auto` from `eve/models` 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. Use `evaluate` from `eve/ai` to ask typed questions in
+inference begins. It uses the [AI SDK decision API](https://ai-sdk.dev/docs/ai-sdk-core/decisions),
+so the decider can be a Vercel AI Gateway model ID or a decision model from
+an installed provider. Use `decide` from `eve/ai` to ask typed questions in
 your own tools or application code.
 
-The AI SDK evaluation model specification is experimental and can change in
+The AI SDK decision model specification is experimental and can change in
 patch releases.
 
 ## Choose from Gateway models
 
-By default, `auto` evaluates with `typesafe-ai/jev`, TypeSafe AI's
-[Jev evaluation model](https://vercel.com/i/what-is-jev). Like other AI SDK
+By default, `auto` decides with `typesafe-ai/jev`, TypeSafe AI's
+[Jev decision model](https://vercel.com/i/what-is-jev). Like other AI SDK
 model strings, it uses Vercel AI Gateway unless the application has configured a
 different global default provider.
 
@@ -35,13 +35,13 @@ export default defineAgent({
 
 Configure Gateway authentication as you would for any other AI SDK model. eve
 does not add a TypeSafe credential or transport layer. During `eve dev`, a
-Gateway evaluator uses the same connection selected through `/login` as Gateway
+Gateway decider 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 `auto`, then adds the resolved model for the current turn, such as
 `dynamic model · openai/gpt-6-luna`.
 
-Set `fallback` to keep the turn running when the evaluator is unavailable or
+Set `fallback` to keep the turn running when the decider is unavailable or
 returns an error. The fallback can be a Gateway model ID, an AI SDK language
 model instance, or an object with `model` and a `reasoning` override:
 
@@ -60,15 +60,15 @@ export default defineAgent({
 });
 ```
 
-The fallback applies only to evaluator failures. eve logs a warning with the
-evaluator error and fallback identity when it switches models. Invalid prompts,
+The fallback applies only to decider failures. eve logs a warning with the
+decider error and fallback identity when it switches models. Invalid prompts,
 including requests without user text or with a latest message over the routing
-limit, still fail before evaluator I/O. Cancelling the turn also aborts routing
+limit, still fail before decider I/O. Cancelling the turn also aborts routing
 instead of selecting the fallback.
 
 ## Use a provider directly
 
-Install the provider package yourself and pass its evaluation model. The provider
+Install the provider package yourself and pass its decision model. The provider
 owns its credentials and settings.
 
 ```sh
@@ -82,7 +82,7 @@ import { auto } from "eve/models";
 
 export default defineAgent({
   model: auto({
-    model: typeSafeAi.evaluationModel("jev-latest"),
+    model: typeSafeAi.decisionModel("jev-latest"),
     options: {
       "openai/gpt-6-sol": "Difficult reasoning and engineering tasks",
       "openai/gpt-6-luna": "Routine tasks where fast completion matters",
@@ -91,12 +91,12 @@ export default defineAgent({
 });
 ```
 
-Any provider that implements the AI SDK `Experimental_EvaluationModel` contract
+Any provider that implements the AI SDK `Experimental_DecisionModel` contract
 works here.
 
 ## Route to provider models and set reasoning
 
-An option's key is the value shown to the evaluator. A string value describes a
+An option's key is the value shown to the decider. A string value describes a
 Gateway model whose ID is the key. Use the object form when the selected model is
 a provider instance, an alias, or needs a reasoning override.
 
@@ -120,7 +120,7 @@ export default defineAgent({
 });
 ```
 
-The evaluator sees option keys, descriptions, and recent text messages. It never
+The decider sees option keys, descriptions, and recent text messages. It never
 receives provider credentials or serialized language model instances. When it
 selects `my_secret_model`, eve resolves the key back to the authored Anthropic
 model.
@@ -129,16 +129,16 @@ 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
+## Decide inside a tool
 
-Use `evaluate` to ask choice, score, or boolean questions about the state you pass to it.
+Use `decide` 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 `auto`,
 including the Gateway connection selected through `/login` during `eve dev`.
-Pass `model` to use another evaluation model ID or a provider instance. A configured
+Pass `model` to use another decision 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/ai";
+import { decide } from "eve/ai";
 import { defineTool } from "eve/tools";
 import { z } from "zod";
 
@@ -146,7 +146,7 @@ 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({
+    const result = await decide({
       state: { request },
       questions: {
         team: {
@@ -169,23 +169,23 @@ The choice above is typed as `"billing" | "support"`. Each question appears unde
 its authored key in `result.answers`. Results also include token usage, warnings,
 provider metadata, and response metadata. To use that choice to delegate while keeping specialist subagents out of the parent model's tools, see [Route to a hidden subagent with Jev](/docs/tools/workflows#route-to-a-hidden-subagent-with-jev).
 
-`evaluate` accepts AI SDK evaluation options, including `maxRetries`, `headers`,
+`decide` accepts AI SDK decision 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. `auto` uses this function
+You can also call `decide` outside a tool; it does not require an active eve
+session. Each call performs its own decision. `auto` uses this function
 and adds the per-turn routing behavior described below.
 
 ## Judge eval results
 
-Eval authors can use `t.judge(...)` to turn evaluation answers into scored assertions, including batches of questions sharing one state. It uses this same `evaluate` implementation and default model. See [Judge](../evals/judge) for criteria, rubrics, and thresholds.
+Eval authors can use `t.judge(...)` to turn decision answers into scored assertions, including batches of questions sharing one state. It uses this same `decide` implementation and default model. See [Judge](../evals/judge) for criteria, rubrics, and thresholds.
 
-## Evaluate tool approvals
+## Decide tool approvals
 
-Use `auto({ model? })` when an evaluation model should decide whether a
+Use `auto({ model? })` when a decision 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
+AI SDK decision model strings and provider instances described above and
 defaults to `typesafe-ai/jev`:
 
 ```ts title="agent/tools/deploy.ts"
@@ -201,7 +201,7 @@ export default defineTool({
 });
 ```
 
-The evaluation model reviews the tool name and input for dangerous effects. A
+The decision 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, and the
@@ -210,17 +210,17 @@ guide for an end-to-end walkthrough.
 
 ## Runtime behavior
 
-`auto` evaluates at the first `step.started` event, after the incoming prompt
+`auto` decides at the first `step.started` event, after the incoming prompt
 is available and before the selected language model runs. It reuses that choice
 for later tool-loop steps in the same turn. A new turn makes a new choice, and
 child sessions route from their own prompts.
 
-The evaluator receives up to eight recent user and assistant text messages,
+The decider receives up to eight recent user and assistant text messages,
 capped at 16,000 characters. Requests without user text and latest messages over
 the limit fail before provider I/O.
 
-Evaluation validation, retries, provider errors, and model resolution follow AI
-SDK semantics. Without `fallback`, an evaluator error fails the turn. With
+Decision validation, retries, provider errors, and model resolution follow AI
+SDK semantics. Without `fallback`, a decider error fails the turn. With
 `fallback`, eve uses and retains that model for the rest of the turn. Cancelling
-the active turn aborts evaluation and prevents a routed or fallback choice from
+the active turn aborts decision and prevents a routed or fallback choice from
 being retained.

package/docs/guides/dynamic-capabilities.md

@@ -362,7 +362,7 @@ A dynamic connection, tool, or skill whose name matches an **authored** one **ov
 
 At `turn.started`, model, tool, skill, and subagent resolvers receive the visible conversation history and incoming message in `ctx.messages`, oldest first. Request context is included, and history projection still applies. Read these messages from the handler's second argument; the event itself contains turn metadata. Instruction resolvers use the separate snapshot described under [Dynamic instructions](#dynamic-instructions).
 
-A message that steers a held turn, or waits behind its session-limit prompt, joins that turn instead of starting one, as does a completed sign-in, so `turn.started` resolvers do not see it; `step.started` resolvers do. When memory recall runs, its results appear in the projected snapshot before incoming input.
+A message that steers a held turn joins it without another `turn.started`, as does a completed sign-in, so `turn.started` resolvers do not see it; `step.started` resolvers do. A message sent while a session-limit prompt waits starts its own turn, so `turn.started` resolvers see it, and that turn waits for the prompt's answer before the model runs. When memory recall runs, its results appear in the projected snapshot before incoming input.
 
 ### Execution order
 

package/docs/guides/frontend/overview.mdx

@@ -174,7 +174,9 @@ supplied `session` remains externally owned and is never replaced by prewarming
 
 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 `task.started` for the call, `agent.started` with the child's `sessionId`, and `task.settled` with the call's result, failure, or cancellation. The default reducer settles the subagent's tool part from `task.settled`, so the part shows the call's outcome rather than its start receipt. `data.tasks[taskId].calls[callId]` records each call's `status`, `output`, and `error`, and `data.agents[sessionId]` records each session a call opened, with its `taskId` and opening `callId`. These records come from the root stream alone.
+A tool part's `state` comes from the shared lifecycle interpretation of the event stream. Its events supply input, output, and error text. A call waiting on an approval or a question reads `approval-requested` until the stream settles the request. An answer you submit doesn't change the part until then. `toolCallState(conversation, callId)` reads tool-call status, including task cancellation and calls interrupted without a result. The full event projection remains internal; `ConversationState` retains its messages, turns, inputs, tasks, and agent sessions.
+
+When the root agent delegates, its stream emits `task.started` for the call, `agent.started` with the child's `sessionId`, and `task.settled` with the call's result, failure, or cancellation. The default reducer keeps the subagent's tool part running until `task.settled` arrives and then settles it with the call's outcome; the start receipt never settles it. `data.tasks[taskId].calls[callId]` records each call's `status`, `output`, and `error`, and `data.agents[sessionId]` records each session a call opened, with its `taskId` and opening `callId`. These records come from the root stream alone.
 
 Detailed child progress lives on the child session's stream, not in the root `data.messages`. Pass `followSubagents: true` to follow the session each subagent call reaches while the component is mounted; following is off by default. Narrow `data.agents[sessionId].observation.status` before reading its `conversation`: `"not-followed"` has no child detail, `"following"` has live detail, and `"idle"` has everything the calls so far produced and resumes when another call reaches the task. `"unavailable"` means the stream failed, not that the child failed. Calls that continue a task with its `taskId` reach the same session, so one session's `conversation.messages`, `inputs`, and `turns` span all of them. Sessions that a custom task opens with `ctx.agent` are recorded but not followed.
 

package/docs/guides/hooks.md

@@ -227,7 +227,7 @@ The remaining subscribers for the event still run. Then eve cancels the turn the
 
 Subagents may carry their own `agent/hooks/` directory. Subagent hooks fire only inside the subagent scope. Parent-agent hooks do not fire for subagent turns, and subagent hooks see only the subagent's own context.
 
-Interactive events such as `input.requested` and `authorization.required` are also published on the parent stream. Parent hooks observe these events after the parent channel handler and stream write, with the parent's session, agent, and channel context. The event retains the child's turn coordinates, so `event.data.turnId` can differ from `ctx.session.turn.id`. The parent follows a proxied `input.requested` or `authorization.required` with `turn.waiting` for its own open turn, which stays open until the running call finishes. A proxied `authorization.completed` is not followed by a parent turn event. These parent events also invoke parent hooks; they do not resolve pending input requests.
+Interactive events such as `input.requested` and `authorization.required` are also published on the parent stream. Parent hooks observe these events after the parent channel handler and stream write, with the parent's session, agent, and channel context. The event retains the child's turn coordinates, so `event.data.turnId` can differ from `ctx.session.turn.id`. A proxied `input.requested` also carries `event.data.callId`, the parent call that waits on it. The parent follows a proxied `input.requested` or `authorization.required` with `turn.waiting` for its own open turn, which stays open until the running call finishes. A proxied `authorization.completed` is not followed by a parent turn event. These parent events also invoke parent hooks; they do not resolve pending input requests.
 
 ## Hook vs tool vs provider