@agent-native/core 0.210.0-nightly-20261019153056 → 0.210.0

package/docs/content/template-chat-features.mdx

@@ -0,0 +1,158 @@
+---
+title: "Chat: Features"
+description: "Every feature that ships with Chat, including conversations, connecting a model, the example action, agent settings, teams, and the admin pages, with setup steps for each."
+---
+
+# Features
+
+Every feature that ships with Chat: how it works, and how to set it up. See
+[Chat](/docs/template-chat) for the overview and
+[Talk to the Agent](/docs/template-chat-agent) for prompts to try.
+
+## Conversations
+
+After you sign in, Chat opens on the **Get started** page, which has a message box and a few links. Send a message there and the conversation opens full page. **New Chat** starts a fresh conversation under the heading "How can I help?" The box stays centered until you send your first message, then moves to the bottom as the conversation grows.
+
+The sidebar lists your conversations in two groups. **Pinned** chats stay at
+the top, and **Recents** shows everything else, newest first. A chat that's
+still working shows a spinner next to its title, so you can start another
+conversation without losing track of the first.
+
+- **Start a new chat** with **New Chat** at the top of the sidebar.
+- **Reopen** any chat by selecting it in the list.
+- **Rename, pin, or archive** a chat from the options menu on its row.
+  Archiving removes it from the list.
+- **Collapse the sidebar** when you want more room for the conversation.
+
+<Steps>
+
+### Rename a chat
+
+Open the options menu on the chat's row and choose **Rename Chat**. Type the
+new title and press Enter. Titles can be up to 160 characters.
+
+### Pin a chat you come back to
+
+Choose **Pin Chat** from the same menu. The chat moves to **Pinned** until
+you choose **Unpin Chat**.
+
+### Archive a chat you're done with
+
+Choose **Archive Chat**. If the archive fails, a message appears and the chat
+stays where it is.
+
+</Steps>
+
+## Connect a model
+
+The agent needs a model to answer. Until one is connected, the message box
+reads "Connect AI to start chatting..." Choose **Use Builder.io** for free
+credits, or **Add your own keys** to use a provider key of your own. Then the
+agent can answer right away.
+
+To change the model later, open **Settings** and choose **Model**. That page
+sets the default model and the providers the app can use.
+
+<Callout tone="info">
+
+Chat doesn't pick a model for you. Which models you can choose from depends
+on the provider you connect.
+
+</Callout>
+
+## Voice input
+
+The message box includes a microphone button. Select it to dictate a message
+instead of typing, then send it like any other. Language and dictation
+options live under **Settings → Preferences**.
+
+## The example action
+
+Chat includes one example action called **hello**. An action is a single
+thing the app can do, like greeting someone, creating a note, or looking up a
+record. Each action has a name, a description of what it does, and the details
+it needs to run. The agent reads those descriptions to decide which action to
+use for your request.
+
+Ask the agent to greet someone, such as "Call the hello action for Alex", and
+it runs hello with that name and shows the result. It exists so you can see
+the full loop once, from your message to the agent running an action and
+showing what came back, before you write your own.
+
+Actions are the shared surface of an agent-native app. The agent uses them,
+and so can the app's own screens, so a new action works in both places with
+no extra setup. Developers add their own actions as the app grows. See
+[Actions](/docs/actions-overview) for how they work and
+[Defining Actions](/docs/actions-defining) to write one.
+
+## Shape the agent in Settings
+
+Open **Settings** and look under the **Agent** group. These pages control how
+the agent behaves in every chat.
+
+| Page                | What it controls                                              |
+| ------------------- | ------------------------------------------------------------- |
+| **Model**           | The default model and provider keys.                          |
+| **Instructions**    | Standing guidance the agent follows in every chat.            |
+| **Personalization** | Your own custom instructions and memory preferences.          |
+| **Memory**          | Things the agent has learned and remembers across chats.      |
+| **Skills**          | Reusable how-to guides the agent can load for a kind of task. |
+| **Files**           | Reference files the agent can read.                           |
+| **Sub-agents**      | Helper agents the main agent can hand work to.                |
+
+The **Connections** group holds **Integrations** and **API keys**, and the
+**Account** group holds **Profile**, **Preferences**, and **Security**.
+
+<Steps>
+
+### Open Settings
+
+Select the search button at the bottom of the sidebar and choose
+**Settings**.
+
+### Pick a page
+
+Choose a page from the list on the left. Changes apply to your next message.
+
+</Steps>
+
+## Sign-in and teams
+
+Chat requires sign-in. Login, signup, and sessions are set up from the first
+run, and sign-in methods, members, and roles are managed under the
+**Organization** group in Settings.
+
+The organization switcher at the bottom of the sidebar shows which
+organization you're working in and lets you switch. Keep a single
+organization per workspace and add people to it as members. Credentials you
+connect are saved per organization, so a second organization doesn't see the
+keys connected under the first.
+
+## Database and Observability
+
+Two admin pages ship with Chat. They aren't linked from the sidebar, so open
+them by address.
+
+- **Database** at `/database` shows the app's tables and lets you browse the
+  rows the agent and the app have saved.
+- **Observability** at `/observability` shows what the agent has been doing,
+  with tabs for an overview, conversations, evals, experiments, and feedback.
+
+Both are for the person running the app. They're mounted whether or not you
+ever open them.
+
+## Mini-apps
+
+Chat can run **Extensions**, small sandboxed tools like a calculator or a
+checklist. They're switched off in Chat. There's no Extensions page in
+Settings, and the agent can't build them. A developer turns them on in two
+places. See [Extensions](/docs/extensions) for what they are and how to enable
+them.
+
+## What's next
+
+- [**Talk to the Agent**](/docs/template-chat-agent) — what the agent can see, and prompts to try
+- [**Chat in a Multi-App Workspace**](/docs/template-chat-integrations) — connecting Chat to Dispatch and other apps
+- [**Developer Guide**](/docs/template-chat-developers) — quick start, actions, the chat route, and adding your first feature
+- [**Chat**](/docs/template-chat) — the overview
+- [**Extensions**](/docs/extensions) — how mini-apps are built and shared

package/docs/content/template-chat-integrations.mdx

@@ -0,0 +1,66 @@
+---
+title: "Chat in a Multi-App Workspace"
+description: "How Chat connects to Dispatch and other apps, and how its agent finds the apps in a workspace and asks them to do work."
+---
+
+# Chat in a Multi-App Workspace
+
+Chat is one app among many in a [Dispatch](/docs/template-dispatch)
+workspace. This page covers what that means in practice: how the connection
+works, and how Chat's agent can reach the other apps around it. See
+[Chat](/docs/template-chat) for the overview.
+
+## How Chat connects to Dispatch
+
+Whether this is automatic depends on how Chat and Dispatch were set up
+together, not on whether either one is hosted or running locally.
+
+### Same workspace: automatic
+
+If Chat and Dispatch were generated or added together into one Agent-Native
+workspace (via `create` or `add-app`) and deployed as one unit, they already
+share one `.env`, one `A2A_SECRET`, and one workspace registry. Discovery and
+authenticated A2A calling both just work, with nothing to set up, whether
+that workspace is running on your machine or in production.
+
+### Separate deployments: one manual step
+
+If Chat and Dispatch are two independently created Agent-Native projects,
+they don't share a secret and can't call each other yet. Connecting them
+takes one manual step on each side: add a `remote-agents/<id>.json` resource
+with a shared secret, from Settings → Agent → Sub-agents (Connect agent), or
+Dispatch → Agents → Add external agent. See
+[A2A Protocol](/docs/a2a-protocol) for the full walkthrough.
+
+To check which situation you're in, ask either app's agent "what apps can you
+see?" If Chat is missing from Dispatch's answer, you're in the second case.
+
+## Integration strategies
+
+**Asking other apps for help.** Chat's agent can look up which apps are in the
+workspace and what each one can do. It can then ask one of them to run a
+specific action and use the answer in the conversation. For example, in a
+workspace with Calendar, you could ask Chat "what's on my calendar tomorrow?"
+and the agent hands that question to Calendar instead of guessing. Chat
+doesn't need to hold Calendar's connection to Google. Calendar already has
+it.
+
+**Chat as a front door.** Because every app's agent is reachable the same
+way, a conversation in Chat is a natural place to start work that lives in
+other apps. You describe what you want in one place, and the agent decides
+which app should handle it. Chat works well here because it has no domain of
+its own to get in the way.
+
+**Staying decoupled.** Chat never needs another app's credentials, and no
+other app needs Chat's. Each app keeps its own connections and its own data.
+Chat only passes along a request and receives an answer.
+
+## What's next
+
+- [**Chat**](/docs/template-chat) — the overview
+- [**Features**](/docs/template-chat-features) — conversations, the example action, teams, and admin pages
+- [**Talk to the Agent**](/docs/template-chat-agent) — what the agent can see, and prompts to try
+- [**Developer Guide**](/docs/template-chat-developers) — quick start, actions, the chat route, and adding your first feature
+- [**Dispatch**](/docs/template-dispatch) — the workspace control plane these patterns run under
+- [**A2A Protocol**](/docs/a2a-protocol) — how apps discover, authenticate with, and call each other
+- [**Multi-App Workspace**](/docs/multi-app-workspace) — the general pattern of composing first-party apps instead of nesting them

package/docs/content/template-chat.mdx

@@ -1,22 +1,13 @@
 ---
 title: "Chat"
-description: "A minimal chat-first agent-native app: durable chat threads, actions, application state, live sync, auth, and room to add your own UI."
+description: "A developer starter for building your own AI chat app. It ships a working chat with saved conversations, sign-in, and one example action for the agent, ready to extend with your own screens and tools."
 ---
 
 # Chat
 
-Chat is the plainest agent-native starting point: a ChatGPT-style shell with
-chat at the center, a thread list, auth, and one example action, nothing
-domain-specific. It's for developers who want a real, deployable app to build
-their own agent and screens on top of, not a finished product for a specific
-job.
+Chat is a developer starter for building your own agent. Create the app and you get a working conversation screen, saved chat history, and sign-in, with a single example action the agent can already use. It replaces the weeks of wiring a chat interface, conversation storage, and login onto a model by hand, so you start with a deployable app and spend your time on what your agent actually does.
 
-If you want a finished domain product shape, start from
-[Calendar](/docs/template-calendar), [Mail](/docs/template-mail),
-[Content](/docs/template-content), [Forms](/docs/template-forms),
-[Analytics](/docs/template-analytics), or another domain template. If you
-truly do not need a browser UI yet, see [Automation-First
-Apps](/docs/pure-agent-apps).
+Chat is not a finished product for a specific job. If you're not a developer, or you want something ready to use today, start with [Clips](/docs/template-clips) for screen recordings, [Slides](/docs/template-slides) for decks, or [Design](/docs/template-design) for interactive prototypes.
 
 <Cards columns={1}>
 
@@ -26,160 +17,39 @@ See Chat live: start a real conversation with the agent, no setup required.
 
 </Cards>
 
-<WireframeBlock id="doc-block-chat1">
-  <Screen
-    surface="desktop"
-    html={
-      "<div style='min-height:560px;box-sizing:border-box;display:flex;align-items:center;justify-content:center;padding:56px 40px'><div style='display:flex;flex-direction:column;align-items:center;justify-content:center;gap:28px;width:min(700px,92%);min-height:430px'><div style='height:34px'></div><div style='text-align:center'><h1 style='margin:0'>How can I help?</h1><p class='wf-muted' style='margin:10px 0 0'>Chat about anything. Add actions, components, pages, jobs, or your own backend.</p></div><div class='wf-card' style='width:100%;min-height:150px;display:flex;flex-direction:column;gap:18px'><span class='wf-muted'>Message the agent...</span><div style='flex:1'></div><div style='display:flex;align-items:center;gap:10px'><span data-icon='plus' aria-label='Attach'></span><div style='flex:1'></div><span class='wf-pill'>GPT-6 Luna · High</span><span class='wf-pill'>Act</span><button class='primary'>↑</button></div></div><div style='height:34px'></div></div></div>"
-    }
-  />
-</WireframeBlock>
-
-## What ships {#what-ships}
-
-<Comparison>
-
-### :green: Included
-
-- Full-page chat on `/` using the framework chat surface and durable chat
-  threads
-- Thread list in the app sidebar to create, reopen, rename, pin, and archive
-  chats
-- The built-in app-agent loop, pre-configured for the chat plugin
-- Auth via Better Auth: login, signup, sessions, organizations
-- An actions directory with one example (`actions/hello.ts`) plus the
-  standard `view-screen` and `navigate` actions
-- The framework's core tables for chat threads, application state, settings,
-  sessions, resources, and run history, plus a Database admin page and an
-  Observability dashboard, mounted whether or not you ever open them
-- Live sync (`useDbSync`) already wired so the UI refreshes when the agent
-  writes to SQL
-- Extensions routes mounted by default, for sandboxed mini-apps your users
-  build inside chat later
-- AGENTS.md with chat-first guidance for adding actions, routes, skills, and
-  application state
-
-### :red: Not included
-
-- Domain tables or seed data
-- Dashboards, lists, charts, forms, or provider integrations
-- Domain-specific actions beyond the example stub
-
-</Comparison>
-
-That's the point. Chat is a thin, useful default shell for your own agent, not
-a domain product pretending to be generic.
-
-<Diagram id="doc-block-chat2" title="What ships in the Chat shell" summary={"A thin chat surface over the framework's standard runtime — actions, durable threads, live sync, and auth — with room to add your own UI."}>
-
-```html
-<div class="diagram-chat">
-  <div class="diagram-col left">
-    <div class="diagram-node">
-      Thread list<br /><small class="diagram-muted"
-        >create · reopen · pin · archive</small
-      >
-    </div>
-    <div class="diagram-node">
-      Full-page chat<br /><small class="diagram-muted"
-        >framework chat surface on /</small
-      >
-    </div>
-  </div>
-  <div class="diagram-arrow diagram-muted" aria-hidden="true">&rarr;</div>
-  <div class="diagram-panel center">
-    <span class="diagram-pill accent">Actions</span
-    ><small class="diagram-muted">hello.ts · view-screen · navigate</small>
-  </div>
-  <div class="diagram-arrow diagram-muted" aria-hidden="true">&rarr;</div>
-  <div class="diagram-col right">
-    <div class="diagram-box">
-      Core SQL tables<br /><small class="diagram-muted"
-        >threads · application_state · settings · sessions · runs</small
-      >
-    </div>
-    <div class="diagram-pill ok">Live sync &#8635;</div>
-    <div class="diagram-box">
-      Better Auth<br /><small class="diagram-muted"
-        >login · orgs · sessions</small
-      >
-    </div>
-  </div>
-</div>
-```
-
-```css
-.diagram-chat {
-  display: flex;
-  align-items: center;
-  gap: 12px;
-  flex-wrap: wrap;
-}
-.diagram-chat .diagram-col {
-  display: flex;
-  flex-direction: column;
-  gap: 10px;
-}
-.diagram-chat .diagram-arrow {
-  font-size: 22px;
-  line-height: 1;
-}
-.diagram-chat .center {
-  display: flex;
-  flex-direction: column;
-  align-items: center;
-  gap: 4px;
-}
-```
-
-</Diagram>
-
-## When to pick it {#when-to-pick}
-
-- **You want a basic app users can talk to immediately** and then extend with
-  actions and UI.
-- **You want the default Agent-Native on-ramp**: chat first, then actions,
-  native results, and app pages.
-- **You want to plug your own agent backend into a familiar chat UI** while
-  keeping Agent-Native's actions, state, auth, and deployment shape.
-- **You are prototyping a custom internal tool** that does not match a domain
-  template.
-
-## Get started {#get-started}
-
-```bash
-npx --yes @agent-native/core@latest create my-chat-app --standalone --template chat
-```
-
-See [Chat: Developer Guide](/docs/template-chat-developers#quick-start) for
-install, first run, and connecting an LLM. For automation-first work with no
-browser UI at all, scaffold with `--headless` instead:
-
-```bash
-npx --yes @agent-native/core@latest create my-agent --headless
-```
-
-Use it for scheduled jobs, queues, CLI loops, or external-agent workflows
-where chat and app pages are not useful yet. The key invariant stays the
-same: actions are the shared surface for chat, UI, HTTP, MCP, A2A, and CLI.
-See [Automation-First Apps](/docs/pure-agent-apps) for that path in depth.
+<Video
+  src="https://cdn.builder.io/o/assets%2FYJIGb4i01jvw0SRdL5Bt%2F4a4df15cbb41401389d5b2929945c3ac?alt=media&token=f4a7cfa8-6ecc-435b-9aa0-31c06ca1a6ee&apiKey=YJIGb4i01jvw0SRdL5Bt"
+  alt="A short screen recording of starting a conversation in the Chat app."
+  caption="A brief tour of the Chat application."
+  autoplay={true}
+  loop={true}
+/>
+
+## What you get
+
+After you sign in, Chat opens on a Get started page with a message box. Ask anything and the agent answers in a full-page conversation. The rest of what's included is deliberately small.
+
+- **A full-page chat.** Conversations take up the whole screen, with the message box centered until you send your first message.
+- **A conversation list.** The sidebar lists your chats so you can start a new one, reopen an old one, rename it, pin it, or archive it.
+- **A Get started page.** A short landing page with links to the guides for adding your first action and your first screen. You can edit it or replace it.
+- **Sign-in and teams.** Login, signup, and organizations work from the start.
+- **One example action.** The agent can already run a simple example, so you can see how an action works before writing your own.
+- **Admin pages.** A database viewer and an observability dashboard are included, whether or not you ever open them.
+- **Room for mini-apps.** Routes for small sandboxed tools called Extensions are included but switched off. A developer can switch them on.
+
+Chat leaves out anything specific to a business: no ready-made data, dashboards, forms, or connections to outside services. You add those.
+
+## Chat in a multi-app workspace
+
+If you're running Chat alongside other apps under [Dispatch](/docs/template-dispatch), it can act as the front door to your workspace. A single conversation can reach into the apps around it instead of living on its own. See [Chat in a Multi-App Workspace](/docs/template-chat-integrations) for how the connection works.
 
 ## What's next
 
-- [**Your First Feature in Chat**](/docs/template-chat-first-edits) — the
-  starter chat route, annotated, plus a full walkthrough of adding a real
-  feature
-- [**Chat: Developer Guide**](/docs/template-chat-developers) — quick start,
-  actions, core tables, auth, and the admin pages that ship by default
-- [**Getting Started**](/docs/getting-started) — build the chat-first path
-  from action to inline result to app page
-- [**Templates**](/docs/cloneable-saas) — the Cloneable SaaS model, and every
-  domain template to start from instead
-- [**Agent Surfaces**](/docs/agent-surfaces) — chat, inline UI, app pages,
-  embedded, automation, and external-agent patterns
-- [**Actions**](/docs/actions-overview) — the action system chat and UI both
-  call
-- [**Native Chat UI**](/docs/native-chat-ui) — chat surface primitives and
-  runtime options
-- [**Automation-First Apps**](/docs/pure-agent-apps) — no-browser workflows
-  for jobs, queues, scripts, and external agents
+- [**Features**](/docs/template-chat-features) — conversations, the example action, teams, and admin pages, with steps for each
+- [**Talk to the Agent**](/docs/template-chat-agent) — what the agent can see, and prompts to try
+- [**Chat in a Multi-App Workspace**](/docs/template-chat-integrations) — connecting Chat to Dispatch and other apps
+- [**Developer Guide**](/docs/template-chat-developers) — quick start, actions, the chat route, and adding your first feature
+- [**Clips**](/docs/template-clips), [**Slides**](/docs/template-slides), and [**Design**](/docs/template-design) — finished apps for people who want to start using an agent without building one
+- [**Templates**](/docs/cloneable-saas) — the Cloneable SaaS model, and every other template to start from
+- [**Getting Started**](/docs/getting-started) — the framework fundamentals: actions, application state, and live sync
+- [**Automation-First Apps**](/docs/pure-agent-apps) — agents with no browser screen, for jobs, queues, and scripts

package/docs/content/template-clips-developers.mdx

@@ -368,7 +368,7 @@ Team, member, and invitation rows live in the framework's own `organizations`, `
     },
     {
       path: "server/routes/api/agent-context.json.get.ts",
-      note: "the agent-readable endpoints, plus agent-transcript.json and agent-frame.jpg",
+      note: "the agent-readable endpoints, plus agent-transcript.json, agent-frame.jpg and agent-frames.jpg",
     },
     {
       path: "server/lib/google-calendar-client.ts",

package/docs/content/template-clips-integrations.mdx

@@ -29,11 +29,12 @@ Paste a public Clips share link into an agent, or use **Share → Copy** in the
 
 Most agents that can view images handle this on their own, including ChatGPT, Claude Code, Cursor, and Codex. A few text-only chats can read the transcript but not the frames, so open the clip in an image-capable agent for those.
 
-| Endpoint                                          | What agents get                                                                                                |
-| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
-| `/api/agent-context.json?id=<recordingId>`        | Clip metadata, transcript status, chapters, CTAs, recommended frames, and links to the transcript/frame APIs   |
-| `/api/agent-transcript.json?id=<recordingId>`     | Timestamped transcript segments with `startMs`, `endMs`, readable timestamps, text, and optional source labels |
-| `/api/agent-frame.jpg?id=<recordingId>&atMs=<ms>` | A JPEG frame extracted from the video at an original-video timestamp                                           |
+| Endpoint                                                                 | What agents get                                                                                                                      |
+| ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `/api/agent-context.json?id=<recordingId>`                               | Clip metadata, transcript status, chapters, CTAs, recommended frames, and links to the transcript/frame APIs                         |
+| `/api/agent-transcript.json?id=<recordingId>`                            | Timestamped transcript segments with `startMs`, `endMs`, readable timestamps, text, and optional source labels                       |
+| `/api/agent-frame.jpg?id=<recordingId>&atMs=<ms>`                        | A JPEG frame extracted from the video at an original-video timestamp                                                                 |
+| `/api/agent-frames.jpg?id=<recordingId>&startMs=<ms>&endMs=<ms>&fps=<n>` | One JPEG contact sheet of up to 36 consecutive frames from a time range, for watching an animation or a transition in a single image |
 
 The endpoints follow the same public/password/expiry rules as the share page, or accept the scoped `agent_access` token from a temporary agent link. Password-protected clips require the password once; successful responses return short-lived tokenized links so downstream agents do not need the plaintext password.
 
@@ -104,6 +105,50 @@ Returns clip metadata, transcript status, chapters, CTAs, recommended frames, an
 
 </Endpoint>
 
+<Endpoint id="doc-block-clips-agent-frames" title="Frame sheet for a time range" method="GET" path="/api/agent-frames.jpg" summary="Consecutive frames from a time range in one JPEG contact sheet" params={[
+  {
+    "name": "id",
+    "in": "query",
+    "type": "string",
+    "required": true,
+    "description": "Recording id"
+  },
+  {
+    "name": "startMs",
+    "in": "query",
+    "type": "integer",
+    "required": true,
+    "description": "Time of the first frame in milliseconds"
+  },
+  {
+    "name": "endMs",
+    "in": "query",
+    "type": "integer",
+    "required": false,
+    "description": "End of the range in milliseconds (exclusive); without it, the sheet holds up to 36 frames from startMs, stopping at 60 seconds or the end of the clip"
+  },
+  {
+    "name": "fps",
+    "in": "query",
+    "type": "number",
+    "required": false,
+    "description": "Frames per second, up to 60; without it, the video's own frame rate"
+  }
+]} responses={[
+  {
+    "status": "200",
+    "description": "image/jpeg sheet read left to right, then top to bottom; the X-Clips-Frame-Sheet-Times header lists each cell's time"
+  },
+  {
+    "status": "400",
+    "description": "failureKind=request when the range needs more than 36 frames or spans more than 60 seconds; nextStep names a request that fits"
+  }
+]}>
+
+Cell _i_ shows the frame on screen at `startMs + i × 1000 / fps`. Leave out `fps` to see every frame the video has.
+
+</Endpoint>
+
 If a transcript isn't ready yet, a well-behaved agent waits a bit and retries instead of giving up right away. Long recordings can take a few minutes. If transcription fails because Builder credits ran out, the agent should say so and point to [Transcription and AI metadata](/docs/template-clips-features#transcription-and-ai-metadata).
 
 ### Exporting to Brain

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.210.0-nightly-20261019153056",
+  "version": "0.210.0",
   "description": "The agentic application framework for building autonomous agents with intuitive UIs",
   "homepage": "https://github.com/BuilderIO/agent-native#readme",
   "bugs": {
@@ -711,8 +711,8 @@
     "yaml": "^2.9.0",
     "yjs": "^13.6.33",
     "zod": "^4.3.6",
-    "@agent-native/agentkit": "^0.210.0-nightly-20261019153056",
-    "@agent-native/recap-cli": "^0.5.74"
+    "@agent-native/agentkit": "^0.210.0",
+    "@agent-native/recap-cli": "^0.5.75"
   },
   "devDependencies": {
     "@ai-sdk/anthropic": "^3.0.71",
@@ -782,7 +782,7 @@
     "xlsx": "^0.18.5"
   },
   "peerDependencies": {
-    "@agent-native/core-corpus": "0.210.0-nightly-20261019153056",
+    "@agent-native/core-corpus": ">=0.196.0",
     "@ai-sdk/anthropic": ">=3",
     "@ai-sdk/cohere": ">=3",
     "@ai-sdk/google": ">=3",

package/src/templates/chat/.agents/skills/actions/SKILL.md

@@ -170,10 +170,10 @@ Everything else — CRUD, settings, search, list/detail reads, auth state, anyth
 - **Do** keep one action, one job; document a reusable action (when to use it, key args, return fields to preserve) in `AGENTS.md` once it's called from outside one narrow screen; promote workflow-heavy actions (provider-backed, cross-app, MCP/A2A, multi-step) into a skill.
 - **Do** use `fail(message, { errorCode, statusCode })` for user-friendly errors and import primitives from `@agent-native/core`(`/action`) instead of redefining them; use the core `upload-image` action or `uploadFile()` for durable images/files — never base64 into SQL, markdown, or action results.
 - **Do** signal failure by throwing, using `fail()` for expected caller-readable failures. Never return `{ error: ... }` as a failure result: a normal return is treated as a successful action. Reserve bare errors for unexpected internal faults.
-- **Do** use `fail()` rather than a bare `Error` for caller-readable failures. It carries the action's message, `errorCode`, and `details` to the browser; unexpected errors become a generic 500. Reserve bare throws for internal faults.
+- **Do** use `fail()` rather than a bare `Error` for caller-readable failures. It carries the action's message, `errorCode`, and `details` to the browser and to agents; unexpected errors become a generic 500. Reserve bare throws for internal faults.
 - **Do** give `fail()` the status that matches the cause: it defaults to `400`, and `useActionQuery` retries only `429`, `502`, `503`, and `504`. Mutations do not retry; use transient statuses only for retryable failures.
 - **Do** render `actionErrorMessage(error) ?? yourCopy` in UI, never bare `error.message`. The message keeps an `Action <name> failed:` prefix that belongs in a console, so a toast built from it reads "Action update-brand-kit failed: That name is taken." The helper returns only what the action wrote, and `undefined` when nothing did (network drop, proxy HTML page), which is why the fallback is not optional.
-- **Do** pass a real `errorCode` when the agent should branch on the failure rather than re-read it. Codes other than the default `action_failed` are appended to the tool result as `(errorCode: not_found)`, on both the in-app agent and MCP; `details` and the status never reach either.
+- **Do** pass a real `errorCode` when the agent should branch on the failure rather than re-read it. Codes other than the default `action_failed` are appended to the tool result as `(errorCode: not_found)`, on both the in-app agent and MCP. `details` follow as an `Error details: {...}` JSON line, and as `structuredContent.error` over MCP, capped at 2,000 characters, so keep them to what the agent acts on next: ids, limits, field names. The status never reaches either.
 - **Don't** re-export actions as REST — `/_agent-native/actions/:name` is already the REST surface; duplicating it under `/api/*` hides the operation from agents.
 - **Don't** reach for provider integrations, `outputSchema`, `authorize`, `needsApproval`, or `_agentImages` without checking `references/` first — each has sharp edges covered there, not here.
 

package/src/templates/chat/netlify.toml

@@ -12,7 +12,6 @@ NPM_CONFIG_PRODUCTION = "false"
 
 [context.production.environment]
 AGENT_NATIVE_HOSTED_HARNESS = "true"
-AGENT_NATIVE_ENABLE_KEEP_WARM = "1"
 AGENT_NATIVE_DISABLE_KEEP_WARM_BACKGROUND = "1"
 BETTER_AUTH_TRUSTED_ORIGINS = "https://starter.agent-native.com,https://chat.agent-native.com"
 # Production release migrations own schema setup; request functions must skip

package/src/templates/default/.agents/skills/actions/SKILL.md

@@ -170,10 +170,10 @@ Everything else — CRUD, settings, search, list/detail reads, auth state, anyth
 - **Do** keep one action, one job; document a reusable action (when to use it, key args, return fields to preserve) in `AGENTS.md` once it's called from outside one narrow screen; promote workflow-heavy actions (provider-backed, cross-app, MCP/A2A, multi-step) into a skill.
 - **Do** use `fail(message, { errorCode, statusCode })` for user-friendly errors and import primitives from `@agent-native/core`(`/action`) instead of redefining them; use the core `upload-image` action or `uploadFile()` for durable images/files — never base64 into SQL, markdown, or action results.
 - **Do** signal failure by throwing, using `fail()` for expected caller-readable failures. Never return `{ error: ... }` as a failure result: a normal return is treated as a successful action. Reserve bare errors for unexpected internal faults.
-- **Do** use `fail()` rather than a bare `Error` for caller-readable failures. It carries the action's message, `errorCode`, and `details` to the browser; unexpected errors become a generic 500. Reserve bare throws for internal faults.
+- **Do** use `fail()` rather than a bare `Error` for caller-readable failures. It carries the action's message, `errorCode`, and `details` to the browser and to agents; unexpected errors become a generic 500. Reserve bare throws for internal faults.
 - **Do** give `fail()` the status that matches the cause: it defaults to `400`, and `useActionQuery` retries only `429`, `502`, `503`, and `504`. Mutations do not retry; use transient statuses only for retryable failures.
 - **Do** render `actionErrorMessage(error) ?? yourCopy` in UI, never bare `error.message`. The message keeps an `Action <name> failed:` prefix that belongs in a console, so a toast built from it reads "Action update-brand-kit failed: That name is taken." The helper returns only what the action wrote, and `undefined` when nothing did (network drop, proxy HTML page), which is why the fallback is not optional.
-- **Do** pass a real `errorCode` when the agent should branch on the failure rather than re-read it. Codes other than the default `action_failed` are appended to the tool result as `(errorCode: not_found)`, on both the in-app agent and MCP; `details` and the status never reach either.
+- **Do** pass a real `errorCode` when the agent should branch on the failure rather than re-read it. Codes other than the default `action_failed` are appended to the tool result as `(errorCode: not_found)`, on both the in-app agent and MCP. `details` follow as an `Error details: {...}` JSON line, and as `structuredContent.error` over MCP, capped at 2,000 characters, so keep them to what the agent acts on next: ids, limits, field names. The status never reaches either.
 - **Don't** re-export actions as REST — `/_agent-native/actions/:name` is already the REST surface; duplicating it under `/api/*` hides the operation from agents.
 - **Don't** reach for provider integrations, `outputSchema`, `authorize`, `needsApproval`, or `_agentImages` without checking `references/` first — each has sharp edges covered there, not here.