@agent-native/core 0.0.0-beta-20260820115430 → 0.0.0-beta-20260820150521

package/corpus/templates/macros/netlify.toml

@@ -12,3 +12,8 @@ NPM_CONFIG_PRODUCTION = "false"
 
 [context.production.environment]
 AGENT_NATIVE_HOSTED_HARNESS = "true"
+# Macros owns its schema at release time (`migrate:production` above), so
+# production request functions must not probe the database for migrations.
+# Preview functions still run request-path migrations because previews do not
+# run the production release migration step.
+AGENT_NATIVE_RELEASE_MIGRATIONS = "1"

package/dist/action.js

@@ -415,6 +415,22 @@ const PROVIDER_SUPPORTED_FORMATS = new Set([
     "ipv6",
     "uuid",
 ]);
+/**
+ * Anthropic's function-schema validator rejects regex lookaround -- `(?=`,
+ * `(?!`, `(?<=`, `(?<!` -- inside a `pattern`, with "Invalid JSON schema: regex
+ * lookaround is not supported", and it rejects the WHOLE request, before a
+ * token is generated. Interactive chat surfaces that as an error; a background
+ * run just dies with `http_400` in `agent_runs.error_detail` while the UI says
+ * nothing, which is how a scout can be down for days looking merely idle.
+ *
+ * Zod 4's `z.string().email()` compiles to two negative lookaheads, and it is
+ * written in ~35 action schemas across core, the templates, and the apps -- so
+ * this is answered here rather than by retyping every one of them, the same way
+ * typeless schemas and unsupported `format` values are. `pattern` is a hint for
+ * the model; the action's own zod schema still validates the value server-side,
+ * so dropping it widens nothing that was actually enforced.
+ */
+const LOOKAROUND_IN_PATTERN = /\(\?<?[=!]/;
 /**
  * Keywords that only ever CONSTRAIN a value and that OpenAI's validator rejects
  * outright. Removing a constraint can never make a previously-valid document
@@ -440,6 +456,10 @@ export function stripUnsupportedSchemaKeywords(node) {
         !PROVIDER_SUPPORTED_FORMATS.has(obj.format)) {
         delete obj.format;
     }
+    if (typeof obj.pattern === "string" &&
+        LOOKAROUND_IN_PATTERN.test(obj.pattern)) {
+        delete obj.pattern;
+    }
     for (const key of SUBSCHEMA_VALUE_KEYS) {
         // `items`/`additionalItems` may also be an array of subschemas.
         const value = obj[key];

package/dist/agent/production-agent.js

@@ -759,6 +759,14 @@ const VISIBLE_RETRY_THRESHOLD_MS = 10_000;
  * < MODEL_STREAM_NO_PROGRESS_TIMEOUT_MS      (90s, above)
  * < RUN_NO_PROGRESS_HARD_TIMEOUT_MS          (150s, run-manager.ts)
  *
+ * Ordering alone is NOT sufficient between the last two, because they do not
+ * measure the same events: the bounds above watch engine-stream frames, while
+ * the run-manager backstop watches events this loop FORWARDS. Extended
+ * thinking produces the first without the second, so the 150s bound sat inside
+ * the working distribution and killed live runs. What keeps them consistent is
+ * the `model_stream` start/end bracket around the engine call, which suspends
+ * the outer backstop while these inner bounds are the ones on duty.
+ *
  * Background-function runs (proven 15-min budget, no ~40s wall) are likewise
  * unaffected — they keep the full 90s window for every event, first or not.
  */
@@ -3464,6 +3472,27 @@ export async function runAgentLoop(opts) {
                 const activeToolInputs = new Map();
                 let zeroByteToolInputRestart;
                 let endedForNoProgress = false;
+                // Bracket the engine call for the run manager's no-progress backstop
+                // (`inFlightWorkDelta` in run-manager.ts). That backstop measures the
+                // events this loop FORWARDS; extended thinking forwards none for
+                // minutes while the frames arriving here prove the stream is alive, so
+                // without the bracket a healthy generation reads as a wedged run and is
+                // killed mid-stream. Closing is idempotent and MUST happen in a
+                // `finally`: a leaked open suspends the backstop for the rest of the
+                // run, which is worse than the stall it exists to catch.
+                let modelStreamBracketOpen = false;
+                const openModelStreamBracket = () => {
+                    if (modelStreamBracketOpen)
+                        return;
+                    modelStreamBracketOpen = true;
+                    send({ type: "model_stream", status: "start" });
+                };
+                const closeModelStreamBracket = () => {
+                    if (!modelStreamBracketOpen)
+                        return;
+                    modelStreamBracketOpen = false;
+                    send({ type: "model_stream", status: "end" });
+                };
                 let lastModelStreamProgressAt = Date.now();
                 // FIX 2: true once a real (non-heartbeat) engine-stream event has been
                 // retrieved for THIS model call — gates
@@ -3540,6 +3569,10 @@ export async function runAgentLoop(opts) {
                 const checkpointNoProgress = () => {
                     if (endedForNoProgress)
                         return;
+                    // The stream is over as far as this loop is concerned, so end the
+                    // bracket before the boundary event rather than after it in the
+                    // `finally` — the checkpoint stays the last event of the chunk.
+                    closeModelStreamBracket();
                     send({
                         type: "auto_continue",
                         reason: "no_progress",
@@ -3637,6 +3670,7 @@ export async function runAgentLoop(opts) {
                 };
                 const eventIterator = eventStream[Symbol.asyncIterator]();
                 let eventIteratorDone = false;
+                openModelStreamBracket();
                 try {
                     while (true) {
                         const nextEvent = await nextEngineEventWithNoProgressTimeout(eventIterator);
@@ -3700,11 +3734,7 @@ export async function runAgentLoop(opts) {
                             });
                             sendToolInputActivity(event.name, key, undefined, true);
                             if (noteZeroByteToolInputStart(event.name)) {
-                                send({
-                                    type: "auto_continue",
-                                    reason: "no_progress",
-                                });
-                                endedForNoProgress = true;
+                                checkpointNoProgress();
                                 break;
                             }
                         }
@@ -3745,11 +3775,7 @@ export async function runAgentLoop(opts) {
                             if (startedZeroByteInput &&
                                 toolName &&
                                 noteZeroByteToolInputStart(toolName)) {
-                                send({
-                                    type: "auto_continue",
-                                    reason: "no_progress",
-                                });
-                                endedForNoProgress = true;
+                                checkpointNoProgress();
                                 break;
                             }
                         }
@@ -3814,6 +3840,7 @@ export async function runAgentLoop(opts) {
                     }
                 }
                 finally {
+                    closeModelStreamBracket();
                     if (!eventIteratorDone) {
                         await requestEventIteratorReturn(eventIterator, !eventIteratorReturnRequested);
                     }

package/dist/agent/run-manager.d.ts

@@ -103,11 +103,22 @@ export declare const DEFAULT_BACKGROUND_RUN_SOFT_TIMEOUT_MS: number;
  * with the client watching keepalives. This backstop covers every segment by
  * construction: if no REAL progress event (see `shouldBumpProgressForEvent`;
  * keepalives and zero-byte prep activity don't count) lands for this long —
- * and no tool call is in flight (tool execution legitimately emits nothing
- * for minutes and has its own 12-min timeout) — the run manager emits
+ * and no unit of work is in flight (see `inFlightWorkDelta`: tool calls,
+ * cross-app calls, and the model stream all legitimately emit nothing for
+ * minutes and each carry a bound of their own) — the run manager emits
  * `auto_continue { reason: "no_progress" }` and aborts the chunk, exactly
  * like the soft timeout, so the normal continuation machinery recovers it.
  *
+ * Being numerically larger than the in-loop watchdogs is NOT what keeps this
+ * from killing a healthy run, and treating it that way is what made it do so:
+ * this clock and the loop's `lastModelStreamProgressAt` measure DIFFERENT
+ * events. An extended-thinking phase bumps the inner clock on every engine
+ * frame while forwarding nothing, so the inner watchdog correctly stayed quiet
+ * and this one saw pure silence — runs whose worst gap crossed 150s died while
+ * still streaming, some by a single second. Ordering between two clocks only
+ * means something when they watch the same events; suspending on in-flight
+ * work is what actually makes the two agree.
+ *
  * This is now only the CEILING, not the value: `resolveRunNoProgressTimeoutMs`
  * clamps the foreground backstop to a fraction of the chunk's soft timeout
  * (~30s at a 40s chunk), which is BELOW the 90s in-loop watchdogs rather than

package/dist/agent/run-manager.js

@@ -78,11 +78,22 @@ export const DEFAULT_BACKGROUND_RUN_SOFT_TIMEOUT_MS = BACKGROUND_SOFT_TIMEOUT_CE
  * with the client watching keepalives. This backstop covers every segment by
  * construction: if no REAL progress event (see `shouldBumpProgressForEvent`;
  * keepalives and zero-byte prep activity don't count) lands for this long —
- * and no tool call is in flight (tool execution legitimately emits nothing
- * for minutes and has its own 12-min timeout) — the run manager emits
+ * and no unit of work is in flight (see `inFlightWorkDelta`: tool calls,
+ * cross-app calls, and the model stream all legitimately emit nothing for
+ * minutes and each carry a bound of their own) — the run manager emits
  * `auto_continue { reason: "no_progress" }` and aborts the chunk, exactly
  * like the soft timeout, so the normal continuation machinery recovers it.
  *
+ * Being numerically larger than the in-loop watchdogs is NOT what keeps this
+ * from killing a healthy run, and treating it that way is what made it do so:
+ * this clock and the loop's `lastModelStreamProgressAt` measure DIFFERENT
+ * events. An extended-thinking phase bumps the inner clock on every engine
+ * frame while forwarding nothing, so the inner watchdog correctly stayed quiet
+ * and this one saw pure silence — runs whose worst gap crossed 150s died while
+ * still streaming, some by a single second. Ordering between two clocks only
+ * means something when they watch the same events; suspending on in-flight
+ * work is what actually makes the two agree.
+ *
  * This is now only the CEILING, not the value: `resolveRunNoProgressTimeoutMs`
  * clamps the foreground backstop to a fraction of the chunk's soft timeout
  * (~30s at a 40s chunk), which is BELOW the 90s in-loop watchdogs rather than
@@ -161,6 +172,36 @@ export function resolveRunNoProgressTimeoutMs(params) {
         return ceiling;
     return override === 0 ? 0 : Math.min(override, ceiling);
 }
+/**
+ * Work-tracking transition for one event: `1` opens a unit of in-flight work,
+ * `-1` closes one, `0` is not a work-tracking event.
+ *
+ * Every pair listed here suspends the no-progress backstop for as long as it is
+ * open, so each one MUST be bounded by a watchdog of its own — tool calls by
+ * the per-tool timeout, cross-app calls by the A2A poll timeout, the model
+ * stream by `MODEL_STREAM_NO_PROGRESS_TIMEOUT_MS`, which the agent loop races
+ * against every wait for the next engine frame. A pair added here without such
+ * a bound turns the backstop off for the rest of the run, which is strictly
+ * worse than the stall it was meant to catch.
+ *
+ * Note what that leaves: the model-stream bound covers waiting for the engine,
+ * not a hang while the loop processes a frame it already has. Nothing here
+ * covers that segment, so a suspension is only ever as tight as the chunk's own
+ * soft timeout. Keep the pairs narrow around genuinely blocking work.
+ */
+function inFlightWorkDelta(event) {
+    switch (event.type) {
+        case "tool_start":
+            return 1;
+        case "tool_done":
+            return -1;
+        case "agent_call":
+        case "model_stream":
+            return event.status === "start" ? 1 : -1;
+        default:
+            return 0;
+    }
+}
 /**
  * Default SQL retention for completed run event logs (24 hours).
  *
@@ -829,9 +870,10 @@ export function startRun(runId, threadId, runFn, onComplete, options) {
     // ── No-progress backstop (see RUN_NO_PROGRESS_HARD_TIMEOUT_MS) ──────────
     // Timer-driven and independent of the agent loop, so it fires even when the
     // stall is in a segment the in-loop watchdogs never see (engine-call
-    // establishment, setup, a wedged transport emitting keepalives). Tool calls
-    // and sub-agent calls in flight suspend it — tool execution legitimately
-    // emits nothing for minutes and carries its own 12-min timeout.
+    // establishment, setup, a wedged transport emitting keepalives). Tool calls,
+    // sub-agent calls, and the model stream in flight suspend it — each
+    // legitimately emits nothing for minutes and each carries a bound of its own
+    // (see `inFlightWorkDelta`).
     let lastRealProgressAt = Date.now();
     let inFlightWorkCount = 0;
     let inFlightMarkerSince = null;
@@ -854,24 +896,11 @@ export function startRun(runId, threadId, runFn, onComplete, options) {
         });
     };
     const trackInFlightWork = (event) => {
+        const delta = inFlightWorkDelta(event);
+        if (delta === 0)
+            return; // Not a work-tracking event — no transition.
         const wasIdle = inFlightWorkCount === 0;
-        if (event.type === "tool_start") {
-            inFlightWorkCount += 1;
-        }
-        else if (event.type === "tool_done") {
-            inFlightWorkCount = Math.max(0, inFlightWorkCount - 1);
-        }
-        else if (event.type === "agent_call") {
-            if (event.status === "start") {
-                inFlightWorkCount += 1;
-            }
-            else {
-                inFlightWorkCount = Math.max(0, inFlightWorkCount - 1);
-            }
-        }
-        else {
-            return; // Not a work-tracking event — no transition possible.
-        }
+        inFlightWorkCount = Math.max(0, inFlightWorkCount + delta);
         // Mirror the 0<->N transition into SQL so a stale reaper running in a
         // DIFFERENT isolate (a client's SQL-subscription poll, a sibling
         // isolate's opportunistic cleanup, a fresh boot's startup sweep) can
@@ -882,6 +911,14 @@ export function startRun(runId, threadId, runFn, onComplete, options) {
         // keep failures observable and preserve transition order. See
         // `setRunInFlightMarker` / `IN_FLIGHT_RUN_STALE_GRACE_MS` in run-store.ts
         // for the full reasoning and bounded-grace derivation.
+        //
+        // A model stream in flight mirrors the marker too, deliberately: a long
+        // thinking phase is exactly when another isolate's reaper would call this
+        // run stale, and the stream is as demonstrably alive as a tool call. It
+        // cannot latch a corpse — the grace clause additionally requires the
+        // liveness basis to be fresh within `IN_FLIGHT_GRACE_MAX_LIVENESS_GAP_MS`,
+        // so a marker left set by a dead producer buys nothing. The cost is one
+        // extra set/clear pair per model call on the way to each tool call.
         if (wasIdle && inFlightWorkCount > 0) {
             mirrorInFlightMarker(true);
         }
@@ -924,7 +961,8 @@ export function startRun(runId, threadId, runFn, onComplete, options) {
             return;
         if (Date.now() - lastRealProgressAt < noProgressTimeoutMs)
             return;
-        console.error(`[run-manager] no real progress for ${noProgressTimeoutMs}ms with no tool in flight — ` +
+        console.error(`[run-manager] no real progress for ${noProgressTimeoutMs}ms with no tool ` +
+            `or model stream in flight — ` +
             `checkpointing run for continuation`, runId);
         // Mirror the soft-timeout semantics exactly: the chunk completes (not
         // aborts) at an auto_continue boundary, so the continuation machinery —

package/dist/agent/types.d.ts

@@ -276,6 +276,27 @@ export type AgentChatEvent = {
     text: string;
 } | {
     type: "stream_keepalive";
+} | {
+    /**
+     * Lifecycle bracket around ONE engine (model) call, emitted by the agent
+     * loop when the stream is established and again — from a `finally` — when
+     * it ends, returns, or throws.
+     *
+     * Exists so the run manager's no-progress backstop can tell "the model is
+     * generating" from "nothing is happening". An extended-thinking phase
+     * emits frames that keep the loop's own 90s model-stream watchdog fresh
+     * without producing any forwarded event, so the backstop's clock saw pure
+     * silence and killed demonstrably-alive runs at 150s. `trackInFlightWork`
+     * counts this pair exactly like `tool_start`/`tool_done`: an engine call
+     * in flight suspends the backstop, bounded by the in-loop watchdog the
+     * same way a tool call is bounded by its own timeout.
+     *
+     * Deliberately NOT a keepalive: a keepalive proves the transport is up,
+     * this proves the loop is inside a model call it will be held accountable
+     * for by `MODEL_STREAM_NO_PROGRESS_TIMEOUT_MS`.
+     */
+    type: "model_stream";
+    status: "start" | "end";
 } | {
     type: "tool_start";
     tool: string;

package/dist/catalog.json

@@ -14,6 +14,7 @@
   "@tiptap/extension-collaboration": "3.30.1",
   "@tiptap/extension-collaboration-caret": "3.30.1",
   "@tiptap/extension-color": "3.30.1",
+  "@tiptap/extension-floating-menu": "3.30.1",
   "@tiptap/extension-horizontal-rule": "3.30.1",
   "@tiptap/extension-image": "3.30.1",
   "@tiptap/extension-link": "3.30.1",

package/dist/collab/awareness.d.ts

@@ -62,11 +62,11 @@ export declare const postAwareness: import("h3").EventHandlerWithFetch<import("h
     error: string;
     states?: undefined;
 } | {
-    error?: undefined;
     states: {
         clientId: number;
         state: string;
     }[];
+    error?: undefined;
 }>>;
 /**
  * GET /_agent-native/collab/:docId/users
@@ -77,9 +77,9 @@ export declare const getActiveUsers: import("h3").EventHandlerWithFetch<import("
     error: string;
     users?: undefined;
 } | {
-    error?: undefined;
     users: {
         clientId: number;
         lastSeen: number;
     }[];
+    error?: undefined;
 }>>;

package/dist/collab/routes.d.ts

@@ -26,8 +26,8 @@ export declare const getCollabState: import("h3").EventHandlerWithFetch<import("
  * Body: { update: string (base64), requestSource?: string }
  */
 export declare const postCollabUpdate: import("h3").EventHandlerWithFetch<import("h3").EventHandlerRequest, Promise<{
-    error: string;
     ok?: undefined;
+    error: string;
 } | {
     error?: undefined;
     ok: boolean;

package/dist/framework-tools.d.ts

@@ -14,7 +14,7 @@ import { type DatabaseToolsOption } from "./scripts/db/tool-mode.js";
  * when it names them in `initialToolNames`. They stay in the searchable registry
  * either way.
  */
-export declare const FRAMEWORK_TOOL_GROUPS: readonly ["sharing", "review", "history", "featureFlags", "localization", "audit", "contextXray", "userProfile", "automation", "docs", "resources", "web", "workspaceApps", "chat", "email"];
+export declare const FRAMEWORK_TOOL_GROUPS: readonly ["sharing", "review", "history", "featureFlags", "localization", "audit", "contextXray", "userProfile", "automation", "docs", "resources", "web", "workspaceApps", "chat", "email", "emailCatalog", "workspaceUserGroups", "orgServiceTokens"];
 export type FrameworkToolGroup = (typeof FRAMEWORK_TOOL_GROUPS)[number];
 /**
  * Per-group switches for the framework's own agent tools. Every group defaults
@@ -73,6 +73,21 @@ export interface FrameworkToolsOption {
     chat?: boolean;
     /** `core-send-email`. */
     email?: boolean;
+    /** The read-only transactional-email catalog (`list-transactional-emails`,
+     *  `list-email-log`, `list-email-activity`, …). Separate from `email`, which
+     *  owns the SEND capability: Dispatch asks any app what it sends without that
+     *  app opting into sending from the agent, so these default to on. */
+    emailCatalog?: boolean;
+    /** Reusable workspace member lists (`list-workspace-user-groups`,
+     *  `upsert-workspace-user-group`, `bulk-update-workspace-user-groups`,
+     *  `delete-workspace-user-group`). Their UI is the Team page and the share
+     *  dialog; an app with neither has no use for them. */
+    workspaceUserGroups?: boolean;
+    /** `create-org-service-token`, `list-org-service-tokens`,
+     *  `revoke-org-service-token`. Minting a credential is a real capability:
+     *  `mcp.enabled` decides whether the ROUTES exist, this decides whether the
+     *  model can call them. */
+    orgServiceTokens?: boolean;
     /** `"minimal"` turns every group above off, for voice-first and
      *  single-purpose apps that want the template's own actions and nothing else.
      *  Any explicit group key wins over the preset, so

package/dist/framework-tools.js

@@ -30,6 +30,9 @@ export const FRAMEWORK_TOOL_GROUPS = [
     "workspaceApps",
     "chat",
     "email",
+    "emailCatalog",
+    "workspaceUserGroups",
+    "orgServiceTokens",
 ];
 function normalizeFrameworkToolsConfig(config) {
     if (config === "minimal")
@@ -152,6 +155,18 @@ export const CORE_ACTION_GROUPS = {
     "get-resource-version": "history",
     "restore-resource-version": "history",
     "list-resource-history": "history",
+    "list-transactional-emails": "emailCatalog",
+    "render-transactional-email-preview": "emailCatalog",
+    "list-email-log": "emailCatalog",
+    "list-email-activity": "emailCatalog",
+    "list-email-engagement": "emailCatalog",
+    "list-workspace-user-groups": "workspaceUserGroups",
+    "upsert-workspace-user-group": "workspaceUserGroups",
+    "bulk-update-workspace-user-groups": "workspaceUserGroups",
+    "delete-workspace-user-group": "workspaceUserGroups",
+    "create-org-service-token": "orgServiceTokens",
+    "list-org-service-tokens": "orgServiceTokens",
+    "revoke-org-service-token": "orgServiceTokens",
     "list-review-comments": "review",
     "create-review-comment": "review",
     "reply-review-comment": "review",

package/dist/jobs/background-automation-runner.js

@@ -10,6 +10,7 @@ import { resolveAutomationExecutionIdentity, } from "../automations/service.js";
 import { createThread, getThread, updateThreadData, withThreadDataLock, } from "../chat-threads/store.js";
 import { queryOrgMembers } from "../org/context.js";
 import { organizationIdFromResourceOwner, organizationResourceOwner, } from "../resources/store.js";
+import { captureError } from "../server/capture-error.js";
 import { runWithRequestContext, } from "../server/request-context.js";
 import { attachAutomationRunThread, finishAutomationRun, startAutomationRun, } from "./run-history.js";
 const BACKGROUND_RUN_STUCK_MS = 10 * 60_000;
@@ -177,11 +178,32 @@ export async function runBackgroundAutomation(options, deps) {
         }
     }
     let result;
+    // Populated as soon as the run id exists, so a failure that never returns a
+    // result can still be joined to its LLM trace (`aiTraceId` -> $ai_trace_id).
+    const runIdRef = { current: null };
     try {
-        result = await executeBackgroundAutomation(options, deps, historyId);
+        result = await executeBackgroundAutomation(options, deps, historyId, runIdRef);
     }
     catch (err) {
         const message = err instanceof Error ? err.message : String(err);
+        // Both callers (recurring-jobs scheduler, trigger dispatcher) record this
+        // onto the automation's own metadata and console.error it, and neither
+        // reports it. A failure visible only in a resource field and stdout is not
+        // a failure anyone sees: the run-level no-progress cutoff killed
+        // automations across two releases without ever raising an issue.
+        captureError(err, {
+            tags: {
+                area: "background-automation",
+                automation: automation.name,
+                scope: options.orgId ? "organization" : "personal",
+            },
+            extra: {
+                automationPath: automation.resource.path,
+                appId: deps.appId,
+                historyId,
+            },
+            ...(runIdRef.current ? { aiTraceId: runIdRef.current } : {}),
+        });
         await recordRunOutcome(historyId, "error", `${message}. No delivery was confirmed.`);
         throw err;
     }
@@ -289,7 +311,7 @@ async function recordRunOutcome(historyId, status, error) {
         console.error(`[automations] Could not record run ${historyId} as ${status}:`, err);
     }
 }
-async function executeBackgroundAutomation(options, deps, historyId) {
+async function executeBackgroundAutomation(options, deps, historyId, runIdRef) {
     const { automation, ownerEmail, orgId, prompt, threadTitle, usageLabel } = options;
     return runWithRequestContext({
         ...options.requestContext,
@@ -335,6 +357,8 @@ async function executeBackgroundAutomation(options, deps, historyId) {
             orgId: orgId ?? null,
         });
         const runId = createRunId(options.runIdPrefix);
+        if (runIdRef)
+            runIdRef.current = runId;
         await recordRunThread(historyId, thread.id, runId);
         // Scheduled work is background work: it has no synchronous serverless
         // caller waiting on it, so it must not inherit the interactive clamp

package/dist/mcp/screen-memory-stdio.d.ts

@@ -137,13 +137,13 @@ export declare function screenMemoryMcpToolDefinitions(): ({
     inputSchema: {
         type: string;
         properties: {
+            count?: undefined;
             query?: undefined;
             minutes?: undefined;
             limit?: undefined;
             clientHint?: undefined;
             timestamp?: undefined;
             chapterId?: undefined;
-            count?: undefined;
             startAt?: undefined;
             endAt?: undefined;
             reason?: undefined;
@@ -159,6 +159,7 @@ export declare function screenMemoryMcpToolDefinitions(): ({
     inputSchema: {
         type: string;
         properties: {
+            count?: undefined;
             query: {
                 type: string;
                 description: string;
@@ -174,7 +175,6 @@ export declare function screenMemoryMcpToolDefinitions(): ({
             clientHint?: undefined;
             timestamp?: undefined;
             chapterId?: undefined;
-            count?: undefined;
             startAt?: undefined;
             endAt?: undefined;
             reason?: undefined;
@@ -190,6 +190,7 @@ export declare function screenMemoryMcpToolDefinitions(): ({
     inputSchema: {
         type: string;
         properties: {
+            count?: undefined;
             minutes: {
                 type: string;
                 description: string;
@@ -199,7 +200,6 @@ export declare function screenMemoryMcpToolDefinitions(): ({
             clientHint?: undefined;
             timestamp?: undefined;
             chapterId?: undefined;
-            count?: undefined;
             startAt?: undefined;
             endAt?: undefined;
             reason?: undefined;
@@ -216,6 +216,7 @@ export declare function screenMemoryMcpToolDefinitions(): ({
         type: string;
         required: string[];
         properties: {
+            count?: undefined;
             query: {
                 type: string;
                 description: string;
@@ -234,7 +235,6 @@ export declare function screenMemoryMcpToolDefinitions(): ({
             };
             timestamp?: undefined;
             chapterId?: undefined;
-            count?: undefined;
             startAt?: undefined;
             endAt?: undefined;
             reason?: undefined;
@@ -250,6 +250,7 @@ export declare function screenMemoryMcpToolDefinitions(): ({
         type: string;
         required: string[];
         properties: {
+            count?: undefined;
             query?: undefined;
             minutes?: undefined;
             limit?: undefined;
@@ -263,7 +264,6 @@ export declare function screenMemoryMcpToolDefinitions(): ({
                 description: string;
             };
             chapterId?: undefined;
-            count?: undefined;
             startAt?: undefined;
             endAt?: undefined;
             includeMicrophone?: undefined;
@@ -314,13 +314,13 @@ export declare function screenMemoryMcpToolDefinitions(): ({
         type: string;
         required: string[];
         properties: {
+            count?: undefined;
             query?: undefined;
             minutes?: undefined;
             limit?: undefined;
             clientHint?: undefined;
             timestamp?: undefined;
             chapterId?: undefined;
-            count?: undefined;
             startAt: {
                 type: string;
                 description: string;
@@ -349,13 +349,13 @@ export declare function screenMemoryMcpToolDefinitions(): ({
         type: string;
         required: string[];
         properties: {
+            count?: undefined;
             query?: undefined;
             minutes?: undefined;
             limit?: undefined;
             clientHint?: undefined;
             timestamp?: undefined;
             chapterId?: undefined;
-            count?: undefined;
             startAt?: undefined;
             endAt?: undefined;
             reason?: undefined;

package/dist/notifications/routes.d.ts

@@ -11,23 +11,23 @@
  *   DELETE /_agent-native/notifications/:id         — delete
  */
 export declare function createNotificationsHandler(): import("h3").EventHandlerWithFetch<import("h3").EventHandlerRequest, Promise<"" | import("./types.js").Notification[] | {
-    error?: undefined;
     count: number;
     updated?: undefined;
     ok?: undefined;
-} | {
     error?: undefined;
+} | {
+    count?: undefined;
     updated: number;
     ok?: undefined;
-    count?: undefined;
+    error?: undefined;
 } | {
+    count?: undefined;
     updated?: undefined;
     error: string;
     ok?: undefined;
-    count?: undefined;
 } | {
-    error?: undefined;
+    count?: undefined;
     updated?: undefined;
     ok: boolean;
-    count?: undefined;
+    error?: undefined;
 }>>;

package/dist/observability/traces.js

@@ -24,6 +24,17 @@ function costUsdFromCenticents(value) {
     return Math.round((value / 10_000) * 1_000_000) / 1_000_000;
 }
 const MAX_TRACKED_GENERATION_TOOL_CALLS = 50;
+/**
+ * `auto_continue` reasons the server PLANNED, which must not read as failures.
+ *
+ * A hosted foreground chunk ends at `run_timeout` roughly every 40s by design —
+ * counting those as errors would bury the boundaries that mean something under
+ * the ones that mean "working as intended". Every other reason is a boundary
+ * something forced on the run: recoverable, but not normal, and it stays
+ * visible as an error carrying its reason as the terminal code. Moving a reason
+ * across this line changes what the error rate means, so move it deliberately.
+ */
+const EXPECTED_CONTINUATION_REASONS = new Set(["run_timeout", "auto_continue"]);
 const MAX_TOOL_ERROR_MESSAGE_LENGTH = 500;
 const STANDALONE_API_KEY_PATTERN = /\b(?:sk-(?:proj-|ant-)?[A-Za-z0-9_-]{8,}|(?:sk|rk)_(?:live|test)_[A-Za-z0-9]{8,}|AIza[A-Za-z0-9_-]{16,}|gh[pousr]_[A-Za-z0-9]{16,})\b/g;
 function truncateToolErrorMessage(value) {
@@ -333,6 +344,11 @@ export async function instrumentAgentLoop(opts) {
     let errorMessage = null;
     let runMetadata = opts.metadata ?? null;
     let terminalOutcome;
+    // The `auto_continue` boundary this run ended at, if any. A cut-off never
+    // reaches the loop's outcome classification (`runAgentLoop` returns early at
+    // the checkpoint), so without this the run reports no terminal state at all
+    // and the reason is recoverable only from `agent_run_events` in Postgres.
+    let cutOffReason = null;
     const instrumentedOutcome = (outcome) => {
         terminalOutcome = outcome;
         if (outcome.state === "completed") {
@@ -377,6 +393,15 @@ export async function instrumentAgentLoop(opts) {
             if (event.type === "clear" || event.type === "done") {
                 runStatus = "success";
                 errorMessage = null;
+                cutOffReason = null;
+            }
+            else if (event.type === "auto_continue") {
+                const reason = event.reason || "auto_continue";
+                cutOffReason = reason;
+                if (!EXPECTED_CONTINUATION_REASONS.has(reason)) {
+                    runStatus = "error";
+                    errorMessage = `Agent run was cut off before finishing (${reason}).`;
+                }
             }
             else if (event.type === "error") {
                 runStatus = "error";
@@ -635,6 +660,20 @@ export async function instrumentAgentLoop(opts) {
             }
         }
         catch { }
+        // A cut-off run never reaches the loop's outcome classification, so stand in
+        // for it here rather than reporting no terminal state at all. `failed` +
+        // `retryable` is the honest encoding available in `AgentLoopOutcome`: the
+        // turn did not finish, and the continuation machinery is expected to
+        // recover it. A real reported outcome always wins.
+        const effectiveTerminalOutcome = terminalOutcome ??
+            (cutOffReason && !EXPECTED_CONTINUATION_REASONS.has(cutOffReason)
+                ? {
+                    state: "failed",
+                    code: cutOffReason,
+                    retryable: true,
+                    message: `Agent run was cut off before finishing (${cutOffReason}).`,
+                }
+                : undefined);
         let llmCallCount = 0;
         if (usage || runStatus === "error") {
             llmCallCount =
@@ -716,7 +755,7 @@ export async function instrumentAgentLoop(opts) {
                     .sort(([a], [b]) => a - b)
                     .map(([, detail]) => detail),
                 toolsTruncated: toolInvocationCounter > MAX_TRACKED_GENERATION_TOOL_CALLS,
-                terminalOutcome,
+                terminalOutcome: effectiveTerminalOutcome,
                 delegation: opts.delegation,
                 createdAt: runStart,
                 experimentAssignments: opts.experimentAssignments,
@@ -752,13 +791,13 @@ export async function instrumentAgentLoop(opts) {
         try {
             const aiError = runStatus === "error"
                 ? toAiErrorDetail(errorMessage, {
-                    state: terminalOutcome?.state,
-                    code: terminalOutcome?.state === "failed" ||
-                        terminalOutcome?.state === "input_required"
-                        ? terminalOutcome.code
+                    state: effectiveTerminalOutcome?.state,
+                    code: effectiveTerminalOutcome?.state === "failed" ||
+                        effectiveTerminalOutcome?.state === "input_required"
+                        ? effectiveTerminalOutcome.code
                         : undefined,
-                    retryable: terminalOutcome?.state === "failed"
-                        ? terminalOutcome.retryable
+                    retryable: effectiveTerminalOutcome?.state === "failed"
+                        ? effectiveTerminalOutcome.retryable
                         : undefined,
                 })
                 : undefined;
@@ -792,6 +831,10 @@ export async function instrumentAgentLoop(opts) {
                     source: "agent_observability",
                     run_id: runId,
                     thread_id: threadId,
+                    // Present for planned boundaries too, which are not errors: the ratio
+                    // of run_timeout to no_progress is the signal, and it is unreadable
+                    // if only one side of it is recorded.
+                    ...(cutOffReason ? { terminal_reason: cutOffReason } : {}),
                     // A truncated run must not read as a complete one.
                     ...(droppedToolSpans > 0
                         ? {
@@ -897,10 +940,10 @@ export async function instrumentAgentLoop(opts) {
                     "agent.input_tokens": usage?.inputTokens ?? 0,
                     "agent.output_tokens": usage?.outputTokens ?? 0,
                     "agent.cost_cents_x100": costCentsX100,
-                    "agent.terminal_state": terminalOutcome?.state,
-                    "agent.terminal_code": terminalOutcome?.state === "failed" ||
-                        terminalOutcome?.state === "input_required"
-                        ? terminalOutcome.code
+                    "agent.terminal_state": effectiveTerminalOutcome?.state,
+                    "agent.terminal_code": effectiveTerminalOutcome?.state === "failed" ||
+                        effectiveTerminalOutcome?.state === "input_required"
+                        ? effectiveTerminalOutcome.code
                         : undefined,
                 },
             });

package/dist/resources/handlers.d.ts

@@ -51,8 +51,8 @@ export declare function handleDeleteResource(event: any): Promise<{
     error: string;
     ok?: undefined;
 } | {
-    ok: boolean;
     error?: undefined;
+    ok: boolean;
 }>;
 /** POST /_agent-native/resources/upload — upload a file as a resource */
 export declare function handleUploadResource(event: any): Promise<import("./store.js").Resource | {
@@ -73,10 +73,10 @@ export declare function handleUploadResource(event: any): Promise<import("./stor
     runId: string | null;
     expiresAt: number | null;
     metadata: string | null;
+    error?: undefined;
     url: string;
     provider: string;
     storageSetupRequired?: undefined;
-    error?: undefined;
 } | {
     error: string;
     storageSetupRequired: boolean;

package/dist/server/action-discovery.d.ts

@@ -86,10 +86,17 @@ export { CORE_ACTION_GROUPS };
  * Core actions with no `frameworkTools` switch, and why:
  *
  * - `upload-image` is load-bearing for ordinary work.
- * - The email catalog is mounted everywhere on purpose so Dispatch can ask any
- *   app what it sends without that app opting in (see its comment below). It is
- *   a read surface, not the `email` group's send capability.
- * - MCP tools and org service tokens are already governed by `mcp.enabled`.
+ * - MCP tools and the hosted-harness routes never enter the model's action
+ *   surface at all (`agentTool: false`), so a switch would gate nothing.
+ *
+ * Membership is expensive in a way that is easy to miss: an untagged action is
+ * also in every app's DEFAULT first-request tool list (see
+ * `resolveInitialToolNames`), so each entry here is a schema every app pays for
+ * on turn one whether or not it has the surface. The email catalog, the
+ * workspace user groups, and the org service tokens each sat here for that
+ * reason alone and now answer to `emailCatalog`, `workspaceUserGroups`, and
+ * `orgServiceTokens` — all defaulting to on, so availability is unchanged, but
+ * reachable through `tool-search` instead of riding along in every request.
  */
 export declare const ALWAYS_ON_CORE_ACTIONS: ReadonlySet<string>;
 export declare function mergeCoreSharingActions(registry: Record<string, ActionEntry>): Promise<void>;

package/dist/server/action-discovery.js

@@ -508,25 +508,20 @@ export { CORE_ACTION_GROUPS };
  * Core actions with no `frameworkTools` switch, and why:
  *
  * - `upload-image` is load-bearing for ordinary work.
- * - The email catalog is mounted everywhere on purpose so Dispatch can ask any
- *   app what it sends without that app opting in (see its comment below). It is
- *   a read surface, not the `email` group's send capability.
- * - MCP tools and org service tokens are already governed by `mcp.enabled`.
+ * - MCP tools and the hosted-harness routes never enter the model's action
+ *   surface at all (`agentTool: false`), so a switch would gate nothing.
+ *
+ * Membership is expensive in a way that is easy to miss: an untagged action is
+ * also in every app's DEFAULT first-request tool list (see
+ * `resolveInitialToolNames`), so each entry here is a schema every app pays for
+ * on turn one whether or not it has the surface. The email catalog, the
+ * workspace user groups, and the org service tokens each sat here for that
+ * reason alone and now answer to `emailCatalog`, `workspaceUserGroups`, and
+ * `orgServiceTokens` — all defaulting to on, so availability is unchanged, but
+ * reachable through `tool-search` instead of riding along in every request.
  */
 export const ALWAYS_ON_CORE_ACTIONS = new Set([
     "upload-image",
-    "list-workspace-user-groups",
-    "upsert-workspace-user-group",
-    "bulk-update-workspace-user-groups",
-    "delete-workspace-user-group",
-    "list-transactional-emails",
-    "render-transactional-email-preview",
-    "list-email-log",
-    "list-email-activity",
-    "list-email-engagement",
-    "create-org-service-token",
-    "list-org-service-tokens",
-    "revoke-org-service-token",
     "list-mcp-tools",
     "call-mcp-tool",
     // Hosted harness capability/policy routes are UI-facing and deliberately

package/dist/server/agent-chat/mcp-options.js

@@ -36,10 +36,25 @@ export function resolveAgentChatMcpOptions(input) {
     // otherwise `disableMcp: true` + `enabled: false` would read as a conflict.
     const legacyEnabled = input?.disableMcp === undefined ? undefined : !input.disableMcp;
     const enabled = pick("enabled", "disableMcp", legacyEnabled, mcp.enabled);
+    const connectorCatalog = pick("connectorCatalog", "connectorCatalog", input?.connectorCatalog, mcp.connectorCatalog);
+    // `catalogMode: "app"` short-circuits `connectorCatalogActive` in
+    // `build-server.ts`, so declaring both served the app's FULL registry while
+    // the allow-list sat in the config looking authoritative. That is the same
+    // unexplainable-report shape `pick` throws on, minus the legacy/nested pair:
+    // an allow-list is written to keep something off the external surface, and
+    // silently ignoring it hands every action schema to every connector client.
+    if (mcp.catalog === "app" &&
+        connectorCatalog &&
+        connectorCatalog.length > 0) {
+        throw new Error(`[agent-native] Conflicting agent-chat options: \`mcp.catalog: "app"\` serves this ` +
+            `app's entire action registry flat, which makes \`mcp.connectorCatalog\` ` +
+            `(${connectorCatalog.length} name(s)) inert. Keep \`connectorCatalog\` for a curated ` +
+            `external surface, or drop it and keep \`catalog: "app"\` — not both.`);
+    }
     return {
         enabled: enabled ?? true,
         catalog: mcp.catalog,
-        connectorCatalog: pick("connectorCatalog", "connectorCatalog", input?.connectorCatalog, mcp.connectorCatalog),
+        connectorCatalog,
         externalAgents: pick("externalAgents", "externalAgents", input?.externalAgents, mcp.externalAgents),
         builtinCrossAppTools: mcp.builtinCrossAppTools,
         title: pick("title", "mcpServerInfo.title", legacyInfo?.title, mcp.title),

package/docs/content/external-agents-catalog.mdx

@@ -201,6 +201,8 @@ export default createAgentChatPlugin({
 
 The builtin cross-app tools (`list_apps`, `open_app`, `ask_app`, `create_embed_session`, `create_workspace_app`, `list_templates`) are always included regardless of the declared list.
 
+`mcp.catalog: "app"` is the opposite choice: it serves this app's entire action registry flat, with no compact or connector trimming. The two are mutually exclusive — declaring both throws at plugin init rather than silently ignoring the allow-list, since an allow-list exists to keep something off the external surface.
+
 ## Tool exposure once connected {#tool-exposure}
 
 Once an agent is connected, it sees the [compact catalog](#catalog-tiers) by default: template-declared app actions plus the builtin cross-app verbs (`list_apps`, `open_app`, `ask_app`, and the app-only embed helper). Use `ask_app` to route a natural-language task through an app agent (the same cross-app entry point [A2A](/docs/a2a-protocol) uses).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.0.0-beta-20260820115430",
+  "version": "0.0.0-beta-20260820150521",
   "description": "Framework for agent-native application development — where AI agents and UI share SQL state, actions, and context",
   "homepage": "https://github.com/BuilderIO/agent-native#readme",
   "bugs": {
@@ -428,7 +428,7 @@
     "yjs": "^13.6.32",
     "zod": "^4.3.6",
     "@agent-native/recap-cli": "0.5.5",
-    "@agent-native/toolkit": "^0.16.7"
+    "@agent-native/toolkit": "^0.0.0-beta-20260820150521"
   },
   "devDependencies": {
     "@ai-sdk/anthropic": "^3.0.71",