@agent-native/dispatch 0.8.28 → 0.9.0

package/dist/server/lib/provider-api.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"provider-api.d.ts","sourceRoot":"","sources":["../../../src/server/lib/provider-api.ts"],"names":[],"mappings":"AAAA,OAAO,EAGL,KAAK,aAAa,EAClB,KAAK,iBAAiB,EACtB,KAAK,sBAAsB,EAC5B,MAAM,iCAAiC,CAAC;AAGzC,eAAO,MAAM,yBAAyB,kSAAmB,CAAC;AAC1D,MAAM,MAAM,qBAAqB,GAAG,aAAa,CAAC;AAClD,YAAY,EAAE,iBAAiB,EAAE,sBAAsB,EAAE,CAAC;AAgB1D,wBAAgB,sBAAsB,CAAC,QAAQ,CAAC,EAAE,qBAAqB;;;;;;;;;;;;;;;IAEtE;AAED,wBAAgB,oBAAoB,CAAC,OAAO,EAAE;IAC5C,QAAQ,EAAE,qBAAqB,CAAC;IAChC,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,QAAQ,CAAC,EAAE,MAAM,CAAC;CACnB,oBAEA;AAED,wBAAgB,yBAAyB,CAAC,IAAI,EAAE,sBAAsB,oBAErE"}

package/dist/server/lib/provider-api.js

@@ -0,0 +1,24 @@
+import { PROVIDER_API_IDS, createProviderApiRuntime, } from "@agent-native/core/provider-api";
+import { getCredentialContext } from "@agent-native/core/server";
+export const DISPATCH_PROVIDER_API_IDS = PROVIDER_API_IDS;
+const runtime = createProviderApiRuntime({
+    appId: "dispatch",
+    localCredentialSource: "dispatch_local",
+    getCredentialContext: () => {
+        const ctx = getCredentialContext();
+        if (!ctx) {
+            throw new Error("Dispatch provider API requests require an authenticated request context.");
+        }
+        return ctx;
+    },
+});
+export function listProviderApiCatalog(provider) {
+    return runtime.listCatalog(provider);
+}
+export function fetchProviderApiDocs(options) {
+    return runtime.fetchDocs(options);
+}
+export function executeProviderApiRequest(args) {
+    return runtime.executeRequest(args);
+}
+//# sourceMappingURL=provider-api.js.map

package/dist/server/lib/provider-api.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"provider-api.js","sourceRoot":"","sources":["../../../src/server/lib/provider-api.ts"],"names":[],"mappings":"AAAA,OAAO,EACL,gBAAgB,EAChB,wBAAwB,GAIzB,MAAM,iCAAiC,CAAC;AACzC,OAAO,EAAE,oBAAoB,EAAE,MAAM,2BAA2B,CAAC;AAEjE,MAAM,CAAC,MAAM,yBAAyB,GAAG,gBAAgB,CAAC;AAI1D,MAAM,OAAO,GAAG,wBAAwB,CAAC;IACvC,KAAK,EAAE,UAAU;IACjB,qBAAqB,EAAE,gBAAgB;IACvC,oBAAoB,EAAE,GAAG,EAAE;QACzB,MAAM,GAAG,GAAG,oBAAoB,EAAE,CAAC;QACnC,IAAI,CAAC,GAAG,EAAE,CAAC;YACT,MAAM,IAAI,KAAK,CACb,0EAA0E,CAC3E,CAAC;QACJ,CAAC;QACD,OAAO,GAAG,CAAC;IACb,CAAC;CACF,CAAC,CAAC;AAEH,MAAM,UAAU,sBAAsB,CAAC,QAAgC;IACrE,OAAO,OAAO,CAAC,WAAW,CAAC,QAAQ,CAAC,CAAC;AACvC,CAAC;AAED,MAAM,UAAU,oBAAoB,CAAC,OAIpC;IACC,OAAO,OAAO,CAAC,SAAS,CAAC,OAAO,CAAC,CAAC;AACpC,CAAC;AAED,MAAM,UAAU,yBAAyB,CAAC,IAA4B;IACpE,OAAO,OAAO,CAAC,cAAc,CAAC,IAAI,CAAC,CAAC;AACtC,CAAC","sourcesContent":["import {\n  PROVIDER_API_IDS,\n  createProviderApiRuntime,\n  type ProviderApiId,\n  type ProviderApiMethod,\n  type ProviderApiRequestArgs,\n} from \"@agent-native/core/provider-api\";\nimport { getCredentialContext } from \"@agent-native/core/server\";\n\nexport const DISPATCH_PROVIDER_API_IDS = PROVIDER_API_IDS;\nexport type DispatchProviderApiId = ProviderApiId;\nexport type { ProviderApiMethod, ProviderApiRequestArgs };\n\nconst runtime = createProviderApiRuntime({\n  appId: \"dispatch\",\n  localCredentialSource: \"dispatch_local\",\n  getCredentialContext: () => {\n    const ctx = getCredentialContext();\n    if (!ctx) {\n      throw new Error(\n        \"Dispatch provider API requests require an authenticated request context.\",\n      );\n    }\n    return ctx;\n  },\n});\n\nexport function listProviderApiCatalog(provider?: DispatchProviderApiId) {\n  return runtime.listCatalog(provider);\n}\n\nexport function fetchProviderApiDocs(options: {\n  provider: DispatchProviderApiId;\n  url?: string;\n  maxBytes?: number;\n}) {\n  return runtime.fetchDocs(options);\n}\n\nexport function executeProviderApiRequest(args: ProviderApiRequestArgs) {\n  return runtime.executeRequest(args);\n}\n"]}

package/dist/server/plugins/agent-chat.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"agent-chat.d.ts","sourceRoot":"","sources":["../../../src/server/plugins/agent-chat.ts"],"names":[],"mappings":";AAIA,wBAmCG"}
+{"version":3,"file":"agent-chat.d.ts","sourceRoot":"","sources":["../../../src/server/plugins/agent-chat.ts"],"names":[],"mappings":";AAIA,wBAoCG"}

package/dist/server/plugins/agent-chat.js

@@ -31,6 +31,7 @@ Use the standard workspace primitives:
 - When creating a new workspace app, create a separate app under apps/<app-id> with apps/<app-id>/package.json including a concise generated description, mount it at /<app-id>, use relative /<app-id> links, never hardcode localhost or dev ports, use shadcn/ui with @tabler/icons-react rather than lucide-react, and ensure the React Router client entry preserves APP_BASE_PATH/VITE_APP_BASE_PATH via appBasePath(). There is no separate workspace app registry to edit.
 - If the starter template is used, treat it as scaffolding only: the finished app must be branded as the requested app with its own home screen/navigation/package metadata/manifest, and must not leave visible "Starter", "Blank app", or "New app" UI behind.
 - Treat first-party apps such as Mail, Calendar, Analytics, Brain, Assets, and Dispatch as existing hosted/connected neighbors available through links and A2A/default connected agents. Do not create wrapper apps, child apps, nested routes, or cloned template copies just to give a new app access to them; build only the genuinely new workflow and delegate cross-app work to those existing apps.
+- Integration grants are not provider capability limits. For ad hoc provider inspection, querying, reporting, or troubleshooting, call provider-api-catalog/provider-api-docs, then provider-api-request against the provider's real HTTP API. Use connectionId for a specific shared grant and accountId for a specific OAuth account. Never expose secret values or silently widen app access while doing this.
 
 When a user asks for something like a digest, reminder, routing rule, or saved behavior:
 - First decide whether it should be a resource, a recurring job, a destination, or a delegated task.

package/dist/server/plugins/agent-chat.js.map

@@ -1 +1 @@
-{"version":3,"file":"agent-chat.js","sourceRoot":"","sources":["../../../src/server/plugins/agent-chat.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,qBAAqB,EAAE,MAAM,2BAA2B,CAAC;AAClE,OAAO,EAAE,aAAa,EAAE,MAAM,wBAAwB,CAAC;AACvD,OAAO,EAAE,eAAe,EAAE,MAAM,wBAAwB,CAAC;AAEzD,eAAe,qBAAqB,CAAC;IACnC,KAAK,EAAE,UAAU;IACjB,0EAA0E;IAC1E,2EAA2E;IAC3E,2EAA2E;IAC3E,YAAY,EAAE,KAAK,EAAE,KAAK,EAAE,EAAE;QAC5B,MAAM,GAAG,GAAG,MAAM,aAAa,CAAC,KAAK,CAAC,CAAC;QACvC,OAAO,GAAG,CAAC,KAAK,CAAC;IACnB,CAAC;IACD,2EAA2E;IAC3E,2EAA2E;IAC3E,wEAAwE;IACxE,OAAO,EAAE,eAAe;IACxB,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;4EAqB4D;CAC3E,CAAC,CAAC","sourcesContent":["import { createAgentChatPlugin } from \"@agent-native/core/server\";\nimport { getOrgContext } from \"@agent-native/core/org\";\nimport { dispatchActions } from \"../../actions/index.js\";\n\nexport default createAgentChatPlugin({\n  appId: \"dispatch\",\n  // Without this, AGENT_ORG_ID is never set on agent action calls and every\n  // row written through the frontend (vault secrets, destinations, workspace\n  // resources) lands with org_id=NULL — breaking data isolation across orgs.\n  resolveOrgId: async (event) => {\n    const ctx = await getOrgContext(event);\n    return ctx.orgId;\n  },\n  // Read actions directly from the package's own action map rather than from\n  // a build-time-generated `.generated/actions-registry.ts` (the latter is a\n  // template-only construct that the Vite plugin emits next to actions/).\n  actions: dispatchActions,\n  systemPrompt: `You are the central dispatch for this workspace.\n\nDefault posture:\n- Treat Slack and Telegram as shared entrypoints into the workspace.\n- Heavily delegate domain work to specialized agents through A2A when another app owns the job.\n- Keep durable memory and operating instructions in resources rather than ephemeral chat.\n- Prefer replying in the current external thread unless the user explicitly asks you to send to a saved destination.\n\nUse the standard workspace primitives:\n- Read and update resources like AGENTS.md, LEARNINGS.md, jobs/*.md, agents/*.md, and remote-agents/*.json when appropriate.\n- Use recurring jobs for scheduled behavior.\n- Use custom agent profiles in agents/*.md for local spawned work and remote-agents/*.json for remote A2A apps.\n- You receive a compact available-apps block with sibling workspace app names and descriptions. Use it to pick the right A2A target, and call list-connected-agents or tool-search only when you need fresh details.\n- When answering whether workspace apps expose agent cards or A2A endpoints, call list-workspace-apps with includeAgentCards=true. If you have not requested that probe, absence of agent-card fields means unchecked, not unavailable.\n- When creating a new workspace app, create a separate app under apps/<app-id> with apps/<app-id>/package.json including a concise generated description, mount it at /<app-id>, use relative /<app-id> links, never hardcode localhost or dev ports, use shadcn/ui with @tabler/icons-react rather than lucide-react, and ensure the React Router client entry preserves APP_BASE_PATH/VITE_APP_BASE_PATH via appBasePath(). There is no separate workspace app registry to edit.\n- If the starter template is used, treat it as scaffolding only: the finished app must be branded as the requested app with its own home screen/navigation/package metadata/manifest, and must not leave visible \"Starter\", \"Blank app\", or \"New app\" UI behind.\n- Treat first-party apps such as Mail, Calendar, Analytics, Brain, Assets, and Dispatch as existing hosted/connected neighbors available through links and A2A/default connected agents. Do not create wrapper apps, child apps, nested routes, or cloned template copies just to give a new app access to them; build only the genuinely new workflow and delegate cross-app work to those existing apps.\n\nWhen a user asks for something like a digest, reminder, routing rule, or saved behavior:\n- First decide whether it should be a resource, a recurring job, a destination, or a delegated task.\n- Keep responses concise and operational.\n- Avoid inventing integrations or destinations that are not configured yet.`,\n});\n"]}
+{"version":3,"file":"agent-chat.js","sourceRoot":"","sources":["../../../src/server/plugins/agent-chat.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,qBAAqB,EAAE,MAAM,2BAA2B,CAAC;AAClE,OAAO,EAAE,aAAa,EAAE,MAAM,wBAAwB,CAAC;AACvD,OAAO,EAAE,eAAe,EAAE,MAAM,wBAAwB,CAAC;AAEzD,eAAe,qBAAqB,CAAC;IACnC,KAAK,EAAE,UAAU;IACjB,0EAA0E;IAC1E,2EAA2E;IAC3E,2EAA2E;IAC3E,YAAY,EAAE,KAAK,EAAE,KAAK,EAAE,EAAE;QAC5B,MAAM,GAAG,GAAG,MAAM,aAAa,CAAC,KAAK,CAAC,CAAC;QACvC,OAAO,GAAG,CAAC,KAAK,CAAC;IACnB,CAAC;IACD,2EAA2E;IAC3E,2EAA2E;IAC3E,wEAAwE;IACxE,OAAO,EAAE,eAAe;IACxB,YAAY,EAAE;;;;;;;;;;;;;;;;;;;;;;4EAsB4D;CAC3E,CAAC,CAAC","sourcesContent":["import { createAgentChatPlugin } from \"@agent-native/core/server\";\nimport { getOrgContext } from \"@agent-native/core/org\";\nimport { dispatchActions } from \"../../actions/index.js\";\n\nexport default createAgentChatPlugin({\n  appId: \"dispatch\",\n  // Without this, AGENT_ORG_ID is never set on agent action calls and every\n  // row written through the frontend (vault secrets, destinations, workspace\n  // resources) lands with org_id=NULL — breaking data isolation across orgs.\n  resolveOrgId: async (event) => {\n    const ctx = await getOrgContext(event);\n    return ctx.orgId;\n  },\n  // Read actions directly from the package's own action map rather than from\n  // a build-time-generated `.generated/actions-registry.ts` (the latter is a\n  // template-only construct that the Vite plugin emits next to actions/).\n  actions: dispatchActions,\n  systemPrompt: `You are the central dispatch for this workspace.\n\nDefault posture:\n- Treat Slack and Telegram as shared entrypoints into the workspace.\n- Heavily delegate domain work to specialized agents through A2A when another app owns the job.\n- Keep durable memory and operating instructions in resources rather than ephemeral chat.\n- Prefer replying in the current external thread unless the user explicitly asks you to send to a saved destination.\n\nUse the standard workspace primitives:\n- Read and update resources like AGENTS.md, LEARNINGS.md, jobs/*.md, agents/*.md, and remote-agents/*.json when appropriate.\n- Use recurring jobs for scheduled behavior.\n- Use custom agent profiles in agents/*.md for local spawned work and remote-agents/*.json for remote A2A apps.\n- You receive a compact available-apps block with sibling workspace app names and descriptions. Use it to pick the right A2A target, and call list-connected-agents or tool-search only when you need fresh details.\n- When answering whether workspace apps expose agent cards or A2A endpoints, call list-workspace-apps with includeAgentCards=true. If you have not requested that probe, absence of agent-card fields means unchecked, not unavailable.\n- When creating a new workspace app, create a separate app under apps/<app-id> with apps/<app-id>/package.json including a concise generated description, mount it at /<app-id>, use relative /<app-id> links, never hardcode localhost or dev ports, use shadcn/ui with @tabler/icons-react rather than lucide-react, and ensure the React Router client entry preserves APP_BASE_PATH/VITE_APP_BASE_PATH via appBasePath(). There is no separate workspace app registry to edit.\n- If the starter template is used, treat it as scaffolding only: the finished app must be branded as the requested app with its own home screen/navigation/package metadata/manifest, and must not leave visible \"Starter\", \"Blank app\", or \"New app\" UI behind.\n- Treat first-party apps such as Mail, Calendar, Analytics, Brain, Assets, and Dispatch as existing hosted/connected neighbors available through links and A2A/default connected agents. Do not create wrapper apps, child apps, nested routes, or cloned template copies just to give a new app access to them; build only the genuinely new workflow and delegate cross-app work to those existing apps.\n- Integration grants are not provider capability limits. For ad hoc provider inspection, querying, reporting, or troubleshooting, call provider-api-catalog/provider-api-docs, then provider-api-request against the provider's real HTTP API. Use connectionId for a specific shared grant and accountId for a specific OAuth account. Never expose secret values or silently widen app access while doing this.\n\nWhen a user asks for something like a digest, reminder, routing rule, or saved behavior:\n- First decide whether it should be a resource, a recurring job, a destination, or a delegated task.\n- Keep responses concise and operational.\n- Avoid inventing integrations or destinations that are not configured yet.`,\n});\n"]}

package/dist/server/plugins/integrations.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"integrations.d.ts","sourceRoot":"","sources":["../../../src/server/plugins/integrations.ts"],"names":[],"mappings":"AAgCA;;;;GAIG;AACH,QAAA,MAAM,0BAA0B,GAAU,UAAU,GAAG,kBAuBtD,CAAC;AAEF,eAAe,0BAA0B,CAAC"}
+{"version":3,"file":"integrations.d.ts","sourceRoot":"","sources":["../../../src/server/plugins/integrations.ts"],"names":[],"mappings":"AAiCA;;;;GAIG;AACH,QAAA,MAAM,0BAA0B,GAAU,UAAU,GAAG,kBAuBtD,CAAC;AAEF,eAAe,0BAA0B,CAAC"}

package/dist/server/plugins/integrations.js

@@ -10,6 +10,7 @@ Default posture:
 - Use the available-apps prompt context first, then list-connected-agents when you need fresh details, to see what agents are available before assuming a request must be handled locally.
 - When asked whether workspace apps expose agent cards or A2A endpoints, call list-workspace-apps with includeAgentCards=true. Without that probe, missing agent-card fields mean unchecked, not unavailable.
 - Treat first-party apps such as Mail, Calendar, Analytics, Brain, Assets, and Dispatch as existing hosted/connected neighbors available through links and A2A/default connected agents. Do not create wrapper apps, child apps, nested routes, or cloned template copies just to give a new app access to them; build only the genuinely new workflow and delegate cross-app work to those existing apps.
+- Integration grants are not provider capability limits. For ad hoc provider inspection, querying, reporting, or troubleshooting, call provider-api-catalog/provider-api-docs, then provider-api-request against the provider's real HTTP API. Use connectionId for a specific shared grant and accountId for a specific OAuth account. Never expose secret values or silently widen app access while doing this.
 - Keep durable memory and operating instructions in resources rather than ephemeral chat.
 - Reply in the originating thread unless the user explicitly asks you to send to a saved destination.
 

package/dist/server/plugins/integrations.js.map

@@ -1 +1 @@
-{"version":3,"file":"integrations.js","sourceRoot":"","sources":["../../../src/server/plugins/integrations.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,wBAAwB,EAAE,MAAM,2BAA2B,CAAC;AACrE,OAAO,EACL,qBAAqB,EACrB,oBAAoB,GACrB,MAAM,iCAAiC,CAAC;AACzC,OAAO,EAAE,iBAAiB,EAAE,MAAM,aAAa,CAAC;AAChD,OAAO,EAAE,eAAe,EAAE,MAAM,wBAAwB,CAAC;AAEzD,MAAM,kCAAkC,GAAG;;;;;;;;;;;;;;;;;;;;;;4FAsBiD,CAAC;AAE7F;;;;GAIG;AACH,MAAM,0BAA0B,GAAG,KAAK,EAAE,QAAa,EAAE,EAAE;IACzD,MAAM,EAAE,YAAY,GAAG,EAAE,EAAE,GAAG,iBAAiB,EAAE,CAAC;IAClD,MAAM,cAAc,GAAG,YAAY,CAAC,YAAY,CAAC;IACjD,MAAM,YAAY,GAChB,OAAO,cAAc,KAAK,QAAQ;QAChC,CAAC,CAAC,cAAc;QAChB,CAAC,CAAC,OAAO,cAAc,KAAK,UAAU;YACpC,CAAC,CAAC,cAAc,CAAC,kCAAkC,CAAC;YACpD,CAAC,CAAC,kCAAkC,CAAC;IAE3C,MAAM,MAAM,GAAG,wBAAwB,CAAC;QACtC,KAAK,EAAE,UAAU;QACjB,OAAO,EAAE,eAAe;QACxB,YAAY,EAAE,oBAAoB;QAClC,aAAa,EAAE,qBAAqB;QACpC,YAAY;QACZ,wDAAwD;QACxD,yEAAyE;QACzE,+DAA+D;QAC/D,6EAA6E;KAC9E,CAAC,CAAC;IAEH,OAAO,MAAM,CAAC,QAAQ,CAAC,CAAC;AAC1B,CAAC,CAAC;AAEF,eAAe,0BAA0B,CAAC","sourcesContent":["import { createIntegrationsPlugin } from \"@agent-native/core/server\";\nimport {\n  beforeDispatchProcess,\n  resolveDispatchOwner,\n} from \"../lib/dispatch-integrations.js\";\nimport { getDispatchConfig } from \"../index.js\";\nimport { dispatchActions } from \"../../actions/index.js\";\n\nconst DISPATCH_INTEGRATION_SYSTEM_PROMPT = `You are the central dispatch for this workspace, responding via a messaging platform integration (Slack, Telegram, email, etc.).\n\nDefault posture:\n- Treat Slack, Telegram, and email as shared entrypoints into the workspace.\n- Heavily delegate domain work to specialized agents through A2A (call-agent) when another app owns the job. Apps you can delegate to include slides (decks/presentations), analytics (data/dashboards), content (docs/articles), videos (Remotion compositions), forms (form builder), clips (screen recordings), design (visual designs), and assets (brand libraries plus generated images/videos).\n- Use the available-apps prompt context first, then list-connected-agents when you need fresh details, to see what agents are available before assuming a request must be handled locally.\n- When asked whether workspace apps expose agent cards or A2A endpoints, call list-workspace-apps with includeAgentCards=true. Without that probe, missing agent-card fields mean unchecked, not unavailable.\n- Treat first-party apps such as Mail, Calendar, Analytics, Brain, Assets, and Dispatch as existing hosted/connected neighbors available through links and A2A/default connected agents. Do not create wrapper apps, child apps, nested routes, or cloned template copies just to give a new app access to them; build only the genuinely new workflow and delegate cross-app work to those existing apps.\n- Keep durable memory and operating instructions in resources rather than ephemeral chat.\n- Reply in the originating thread unless the user explicitly asks you to send to a saved destination.\n\nWhen a user asks for something:\n- If it belongs to analytics, content, slides, videos, assets, etc., delegate via call-agent — do not re-implement the domain logic in dispatch.\n- After call-agent returns an answer, RELAY IT DIRECTLY to the user with at most a one-line preface — do not rephrase, summarize, or add commentary. The downstream agent already crafted the answer; your job is delivery, not editing. This minimizes round-trips and keeps the user-visible reply fast.\n- Exception: if the downstream agent reports a missing model/provider credential, do not name exact env vars, Vault keys, tokens, or secrets. Say the target app needs an LLM connection and recommend connecting Builder/managed LLM for that app; keep bring-your-own provider keys as a secondary option only if the user asks.\n- If the user asks to create, build, make, scaffold, or generate an \"agent\" from Dispatch chat or by tagging @agent-native in Slack, email, or Telegram, first classify the ask. If it is a simple Dispatch-native behavior like a reminder, digest, monitor, routing rule, saved instruction, or recurring workflow, create or update the recurring job/resource/destination in Dispatch. If it is a robust unique product or teammate that needs its own UI, data model, actions, integrations, or domain workflow, treat it as a new workspace app and call start-workspace-app-creation.\n- If a new-app prompt asks for access to Mail, Calendar, Analytics, Brain, Assets, or similar first-party app data/agents, keep using the existing hosted/connected app and A2A path. Do not ask Builder to scaffold those apps as children of the new app unless the user explicitly asks for a customized fork/copy.\n- If the starter template is used, treat it as scaffolding only: the finished app must be branded as the requested app with its own home screen/navigation/package metadata/manifest, and must not leave visible \"Starter\", \"Blank app\", or \"New app\" UI behind.\n- If the user explicitly asks for a new app or workspace app, call start-workspace-app-creation with their prompt and include a concise generated description by default. Do not satisfy a new-app request by adding a route, page, component, or file inside apps/starter or another existing app unless the user explicitly asks to modify that existing app. If the request is too vague to classify, ask one concise follow-up. If the action returns mode \"builder\", reply with the Builder branch URL; Builder is responsible for creating the separate workspace app under apps/<app-id>, mounting it at /<app-id>, ensuring apps/<app-id>/package.json exists with name/displayName and description so Dispatch discovers it, using relative /<app-id> links instead of hardcoded localhost/dev ports, and preserving APP_BASE_PATH/VITE_APP_BASE_PATH via appBasePath() in the React Router client entry. The new app lives at the workspace root /<app-id>, NOT under /dispatch/<app-id>, /apps/<app-id>, or any other Dispatch tab — when telling the user where to find it, link to /<app-id> only. There is no separate workspace app registry to edit. If it returns mode \"local-agent\", tell the user it is ready for the local code agent and include the returned app path/prompt summary. If it returns mode \"coming-soon\" or \"builder-unavailable\", explain the missing Builder setup and ask them to connect/configure Builder.\n- For digests, reminders, or saved behavior, prefer recurring jobs, resources, or destinations over chat replies.\n- Keep responses concise and operational — messaging platforms have character limits.\n- Use markdown sparingly (bold and lists are fine, avoid complex formatting).\n- If a task requires many steps, summarize what you did rather than streaming every detail.`;\n\n/**\n * Defer plugin construction until the Nitro plugin actually fires so the\n * config-aware system prompt resolves AFTER `setupDispatch(config)` has\n * stamped the active config (plugin module load order is not guaranteed).\n */\nconst dispatchIntegrationsPlugin = async (nitroApp: any) => {\n  const { integrations = {} } = getDispatchConfig();\n  const promptOverride = integrations.systemPrompt;\n  const systemPrompt =\n    typeof promptOverride === \"string\"\n      ? promptOverride\n      : typeof promptOverride === \"function\"\n        ? promptOverride(DISPATCH_INTEGRATION_SYSTEM_PROMPT)\n        : DISPATCH_INTEGRATION_SYSTEM_PROMPT;\n\n  const plugin = createIntegrationsPlugin({\n    appId: \"dispatch\",\n    actions: dispatchActions,\n    resolveOwner: resolveDispatchOwner,\n    beforeProcess: beforeDispatchProcess,\n    systemPrompt,\n    // Inherit the framework default (claude-sonnet-4-6 from\n    // packages/core/src/integrations/plugin.ts). Haiku was tried for latency\n    // but hallucinated URLs/IDs after delegated call-agent results\n    // (e.g. inventing `https://slides.workspace.com/deck/builder-io-deck-2024`).\n  });\n\n  return plugin(nitroApp);\n};\n\nexport default dispatchIntegrationsPlugin;\n"]}
+{"version":3,"file":"integrations.js","sourceRoot":"","sources":["../../../src/server/plugins/integrations.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,wBAAwB,EAAE,MAAM,2BAA2B,CAAC;AACrE,OAAO,EACL,qBAAqB,EACrB,oBAAoB,GACrB,MAAM,iCAAiC,CAAC;AACzC,OAAO,EAAE,iBAAiB,EAAE,MAAM,aAAa,CAAC;AAChD,OAAO,EAAE,eAAe,EAAE,MAAM,wBAAwB,CAAC;AAEzD,MAAM,kCAAkC,GAAG;;;;;;;;;;;;;;;;;;;;;;;4FAuBiD,CAAC;AAE7F;;;;GAIG;AACH,MAAM,0BAA0B,GAAG,KAAK,EAAE,QAAa,EAAE,EAAE;IACzD,MAAM,EAAE,YAAY,GAAG,EAAE,EAAE,GAAG,iBAAiB,EAAE,CAAC;IAClD,MAAM,cAAc,GAAG,YAAY,CAAC,YAAY,CAAC;IACjD,MAAM,YAAY,GAChB,OAAO,cAAc,KAAK,QAAQ;QAChC,CAAC,CAAC,cAAc;QAChB,CAAC,CAAC,OAAO,cAAc,KAAK,UAAU;YACpC,CAAC,CAAC,cAAc,CAAC,kCAAkC,CAAC;YACpD,CAAC,CAAC,kCAAkC,CAAC;IAE3C,MAAM,MAAM,GAAG,wBAAwB,CAAC;QACtC,KAAK,EAAE,UAAU;QACjB,OAAO,EAAE,eAAe;QACxB,YAAY,EAAE,oBAAoB;QAClC,aAAa,EAAE,qBAAqB;QACpC,YAAY;QACZ,wDAAwD;QACxD,yEAAyE;QACzE,+DAA+D;QAC/D,6EAA6E;KAC9E,CAAC,CAAC;IAEH,OAAO,MAAM,CAAC,QAAQ,CAAC,CAAC;AAC1B,CAAC,CAAC;AAEF,eAAe,0BAA0B,CAAC","sourcesContent":["import { createIntegrationsPlugin } from \"@agent-native/core/server\";\nimport {\n  beforeDispatchProcess,\n  resolveDispatchOwner,\n} from \"../lib/dispatch-integrations.js\";\nimport { getDispatchConfig } from \"../index.js\";\nimport { dispatchActions } from \"../../actions/index.js\";\n\nconst DISPATCH_INTEGRATION_SYSTEM_PROMPT = `You are the central dispatch for this workspace, responding via a messaging platform integration (Slack, Telegram, email, etc.).\n\nDefault posture:\n- Treat Slack, Telegram, and email as shared entrypoints into the workspace.\n- Heavily delegate domain work to specialized agents through A2A (call-agent) when another app owns the job. Apps you can delegate to include slides (decks/presentations), analytics (data/dashboards), content (docs/articles), videos (Remotion compositions), forms (form builder), clips (screen recordings), design (visual designs), and assets (brand libraries plus generated images/videos).\n- Use the available-apps prompt context first, then list-connected-agents when you need fresh details, to see what agents are available before assuming a request must be handled locally.\n- When asked whether workspace apps expose agent cards or A2A endpoints, call list-workspace-apps with includeAgentCards=true. Without that probe, missing agent-card fields mean unchecked, not unavailable.\n- Treat first-party apps such as Mail, Calendar, Analytics, Brain, Assets, and Dispatch as existing hosted/connected neighbors available through links and A2A/default connected agents. Do not create wrapper apps, child apps, nested routes, or cloned template copies just to give a new app access to them; build only the genuinely new workflow and delegate cross-app work to those existing apps.\n- Integration grants are not provider capability limits. For ad hoc provider inspection, querying, reporting, or troubleshooting, call provider-api-catalog/provider-api-docs, then provider-api-request against the provider's real HTTP API. Use connectionId for a specific shared grant and accountId for a specific OAuth account. Never expose secret values or silently widen app access while doing this.\n- Keep durable memory and operating instructions in resources rather than ephemeral chat.\n- Reply in the originating thread unless the user explicitly asks you to send to a saved destination.\n\nWhen a user asks for something:\n- If it belongs to analytics, content, slides, videos, assets, etc., delegate via call-agent — do not re-implement the domain logic in dispatch.\n- After call-agent returns an answer, RELAY IT DIRECTLY to the user with at most a one-line preface — do not rephrase, summarize, or add commentary. The downstream agent already crafted the answer; your job is delivery, not editing. This minimizes round-trips and keeps the user-visible reply fast.\n- Exception: if the downstream agent reports a missing model/provider credential, do not name exact env vars, Vault keys, tokens, or secrets. Say the target app needs an LLM connection and recommend connecting Builder/managed LLM for that app; keep bring-your-own provider keys as a secondary option only if the user asks.\n- If the user asks to create, build, make, scaffold, or generate an \"agent\" from Dispatch chat or by tagging @agent-native in Slack, email, or Telegram, first classify the ask. If it is a simple Dispatch-native behavior like a reminder, digest, monitor, routing rule, saved instruction, or recurring workflow, create or update the recurring job/resource/destination in Dispatch. If it is a robust unique product or teammate that needs its own UI, data model, actions, integrations, or domain workflow, treat it as a new workspace app and call start-workspace-app-creation.\n- If a new-app prompt asks for access to Mail, Calendar, Analytics, Brain, Assets, or similar first-party app data/agents, keep using the existing hosted/connected app and A2A path. Do not ask Builder to scaffold those apps as children of the new app unless the user explicitly asks for a customized fork/copy.\n- If the starter template is used, treat it as scaffolding only: the finished app must be branded as the requested app with its own home screen/navigation/package metadata/manifest, and must not leave visible \"Starter\", \"Blank app\", or \"New app\" UI behind.\n- If the user explicitly asks for a new app or workspace app, call start-workspace-app-creation with their prompt and include a concise generated description by default. Do not satisfy a new-app request by adding a route, page, component, or file inside apps/starter or another existing app unless the user explicitly asks to modify that existing app. If the request is too vague to classify, ask one concise follow-up. If the action returns mode \"builder\", reply with the Builder branch URL; Builder is responsible for creating the separate workspace app under apps/<app-id>, mounting it at /<app-id>, ensuring apps/<app-id>/package.json exists with name/displayName and description so Dispatch discovers it, using relative /<app-id> links instead of hardcoded localhost/dev ports, and preserving APP_BASE_PATH/VITE_APP_BASE_PATH via appBasePath() in the React Router client entry. The new app lives at the workspace root /<app-id>, NOT under /dispatch/<app-id>, /apps/<app-id>, or any other Dispatch tab — when telling the user where to find it, link to /<app-id> only. There is no separate workspace app registry to edit. If it returns mode \"local-agent\", tell the user it is ready for the local code agent and include the returned app path/prompt summary. If it returns mode \"coming-soon\" or \"builder-unavailable\", explain the missing Builder setup and ask them to connect/configure Builder.\n- For digests, reminders, or saved behavior, prefer recurring jobs, resources, or destinations over chat replies.\n- Keep responses concise and operational — messaging platforms have character limits.\n- Use markdown sparingly (bold and lists are fine, avoid complex formatting).\n- If a task requires many steps, summarize what you did rather than streaming every detail.`;\n\n/**\n * Defer plugin construction until the Nitro plugin actually fires so the\n * config-aware system prompt resolves AFTER `setupDispatch(config)` has\n * stamped the active config (plugin module load order is not guaranteed).\n */\nconst dispatchIntegrationsPlugin = async (nitroApp: any) => {\n  const { integrations = {} } = getDispatchConfig();\n  const promptOverride = integrations.systemPrompt;\n  const systemPrompt =\n    typeof promptOverride === \"string\"\n      ? promptOverride\n      : typeof promptOverride === \"function\"\n        ? promptOverride(DISPATCH_INTEGRATION_SYSTEM_PROMPT)\n        : DISPATCH_INTEGRATION_SYSTEM_PROMPT;\n\n  const plugin = createIntegrationsPlugin({\n    appId: \"dispatch\",\n    actions: dispatchActions,\n    resolveOwner: resolveDispatchOwner,\n    beforeProcess: beforeDispatchProcess,\n    systemPrompt,\n    // Inherit the framework default (claude-sonnet-4-6 from\n    // packages/core/src/integrations/plugin.ts). Haiku was tried for latency\n    // but hallucinated URLs/IDs after delegated call-agent results\n    // (e.g. inventing `https://slides.workspace.com/deck/builder-io-deck-2024`).\n  });\n\n  return plugin(nitroApp);\n};\n\nexport default dispatchIntegrationsPlugin;\n"]}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/dispatch",
-  "version": "0.8.28",
+  "version": "0.9.0",
   "type": "module",
   "description": "Dispatch — workspace control plane for agent-native apps. Vault, integrations, destinations, scheduled jobs, and cross-app delegation, shipped as a single drop-in package.",
   "license": "MIT",

package/src/actions/index.ts

@@ -55,6 +55,9 @@ import openApp from "./open_app.js";
 import applyDreamProposal from "./apply-dream-proposal.js";
 import previewDreamProposal from "./preview-dream-proposal.js";
 import previewWorkspaceResourceChange from "./preview-workspace-resource-change.js";
+import providerApiCatalog from "./provider-api-catalog.js";
+import providerApiDocs from "./provider-api-docs.js";
+import providerApiRequest from "./provider-api-request.js";
 import rejectDispatchChange from "./reject-dispatch-change.js";
 import rejectDreamProposal from "./reject-dream-proposal.js";
 import removePendingWorkspaceApp from "./remove-pending-workspace-app.js";
@@ -144,6 +147,9 @@ export const dispatchActions: Record<string, ActionEntry> = {
   "apply-dream-proposal": applyDreamProposal,
   "preview-dream-proposal": previewDreamProposal,
   "preview-workspace-resource-change": previewWorkspaceResourceChange,
+  "provider-api-catalog": providerApiCatalog,
+  "provider-api-docs": providerApiDocs,
+  "provider-api-request": providerApiRequest,
   "reject-dispatch-change": rejectDispatchChange,
   "reject-dream-proposal": rejectDreamProposal,
   "remove-pending-workspace-app": removePendingWorkspaceApp,

package/src/actions/provider-api-catalog.ts

@@ -0,0 +1,27 @@
+import { defineAction } from "@agent-native/core";
+import { z } from "zod";
+import {
+  DISPATCH_PROVIDER_API_IDS,
+  listProviderApiCatalog,
+} from "../server/lib/provider-api.js";
+
+const ProviderSchema = z.enum(DISPATCH_PROVIDER_API_IDS);
+
+export default defineAction({
+  description:
+    "List raw HTTP API capabilities for shared workspace integrations and configured providers. Use before provider-api-request when grant/setup metadata is not enough and the provider's actual API must be inspected. Returns base URLs, auth style, credential key names, docs/spec URLs, placeholders, and examples; never returns secret values.",
+  schema: z.object({
+    provider: ProviderSchema.optional().describe(
+      "Optional provider id to inspect. Omit to list every provider API escape hatch.",
+    ),
+  }),
+  http: { method: "GET" },
+  readOnly: true,
+  run: async ({ provider }) => {
+    return {
+      providers: listProviderApiCatalog(provider),
+      guidance:
+        "Workspace integrations and grants are not capability limits. When a provider can answer a question through its HTTP API, inspect docs/spec URLs here and call provider-api-request with the exact provider API method/path/query/body instead of adding a rigid one-off action.",
+    };
+  },
+});

package/src/actions/provider-api-docs.ts

@@ -0,0 +1,35 @@
+import { defineAction } from "@agent-native/core";
+import { z } from "zod";
+import {
+  DISPATCH_PROVIDER_API_IDS,
+  fetchProviderApiDocs,
+} from "../server/lib/provider-api.js";
+
+const ProviderSchema = z.enum(DISPATCH_PROVIDER_API_IDS);
+
+export default defineAction({
+  description:
+    "Inspect provider API docs/spec metadata, or fetch a registered provider docs/spec URL. Use this before arbitrary provider-api-request calls when the exact endpoint, filter operator, payload shape, pagination, or API version is uncertain.",
+  schema: z.object({
+    provider: ProviderSchema.describe(
+      "Provider whose API docs/spec to inspect.",
+    ),
+    url: z
+      .string()
+      .url()
+      .optional()
+      .describe(
+        "Optional docs/spec URL from provider-api-catalog to fetch. Only registered docs/spec origins are allowed.",
+      ),
+    maxBytes: z.coerce
+      .number()
+      .int()
+      .min(1_000)
+      .max(4 * 1024 * 1024)
+      .optional()
+      .describe("Maximum response bytes to read. Default 1MB, max 4MB."),
+  }),
+  http: { method: "GET" },
+  readOnly: true,
+  run: async (args) => fetchProviderApiDocs(args),
+});

package/src/actions/provider-api-request.ts

@@ -0,0 +1,78 @@
+import { defineAction } from "@agent-native/core";
+import { z } from "zod";
+import {
+  DISPATCH_PROVIDER_API_IDS,
+  executeProviderApiRequest,
+} from "../server/lib/provider-api.js";
+
+const ProviderSchema = z.enum(DISPATCH_PROVIDER_API_IDS);
+const MethodSchema = z.enum(["GET", "POST", "PUT", "PATCH", "DELETE", "HEAD"]);
+
+export default defineAction({
+  description:
+    "Make an arbitrary authenticated HTTP request to a shared workspace integration or configured provider API. Use this as the flexible escape hatch when Dispatch needs a provider endpoint, filter, pagination mode, payload, or API version that no canned action models. The request is constrained to the provider host, uses configured credentials automatically, blocks private/internal URLs, and redacts secrets from responses.",
+  schema: z.object({
+    provider: ProviderSchema.describe(
+      "Configured provider API to call, e.g. slack, github, notion, hubspot, gmail, google_drive, google_calendar, granola, stripe, jira.",
+    ),
+    method: MethodSchema.default("GET").describe("HTTP method to use."),
+    path: z
+      .string()
+      .min(1)
+      .describe(
+        "Provider API path such as /search.messages, /repos/org/repo/issues, /crm/v3/objects/deals/search, or a full URL on an allowed provider host. Use placeholders from provider-api-catalog when provided.",
+      ),
+    query: z
+      .unknown()
+      .optional()
+      .describe(
+        "Optional query params as a JSON object/string. Array values produce repeated query params.",
+      ),
+    headers: z
+      .record(z.string(), z.unknown())
+      .optional()
+      .describe(
+        "Optional extra headers. Unsafe hop-by-hop headers are ignored. Auth headers are injected from stored credentials.",
+      ),
+    body: z
+      .unknown()
+      .optional()
+      .describe(
+        "Optional request body. Objects/arrays are JSON encoded; strings are sent as-is.",
+      ),
+    auth: z
+      .enum(["default", "none"])
+      .default("default")
+      .describe(
+        "Use default to inject configured provider auth. Use none only for public provider endpoints that intentionally require no auth.",
+      ),
+    connectionId: z
+      .string()
+      .optional()
+      .describe(
+        "Optional shared workspace connection id to use when the provider has multiple granted connections.",
+      ),
+    accountId: z
+      .string()
+      .optional()
+      .describe(
+        "Optional OAuth account id to use for OAuth-backed providers such as Gmail, Google Calendar, or Google Drive.",
+      ),
+    timeoutMs: z.coerce
+      .number()
+      .int()
+      .min(1_000)
+      .max(120_000)
+      .optional()
+      .describe("Request timeout in milliseconds. Default 30000, max 120000."),
+    maxBytes: z.coerce
+      .number()
+      .int()
+      .min(1_000)
+      .max(4 * 1024 * 1024)
+      .optional()
+      .describe("Maximum response bytes to read. Default 1MB, max 4MB."),
+  }),
+  http: false,
+  run: async (args) => executeProviderApiRequest(args),
+});

package/src/routes/pages/apps.tsx

@@ -8,6 +8,7 @@ import {
   IconChartBar,
   IconChevronDown,
   IconClipboardList,
+  IconContract,
   IconEyeOff,
   IconFileText,
   IconLoader2,
@@ -64,6 +65,7 @@ const TEMPLATE_ICONS: Record<string, typeof IconMail> = {
   Photo: IconPhoto,
   ChartBar: IconChartBar,
   ClipboardList: IconClipboardList,
+  Contract: IconContract,
   Brush: IconBrush,
   Video: IconVideo,
 };

package/src/server/lib/app-creation-store.ts

@@ -1329,6 +1329,15 @@ const ADDABLE_TEMPLATES: AvailableWorkspaceTemplate[] = [
     colorRgb: "6 182 212",
     core: true,
   },
+  {
+    name: "contracts",
+    label: "Contracts",
+    hint: "Review assumptions, feedback, and proof for coding-agent work",
+    icon: "Contract",
+    color: "#4F46E5",
+    colorRgb: "79 70 229",
+    core: false,
+  },
   {
     name: "design",
     label: "Design",

package/src/server/lib/provider-api.ts

@@ -0,0 +1,42 @@
+import {
+  PROVIDER_API_IDS,
+  createProviderApiRuntime,
+  type ProviderApiId,
+  type ProviderApiMethod,
+  type ProviderApiRequestArgs,
+} from "@agent-native/core/provider-api";
+import { getCredentialContext } from "@agent-native/core/server";
+
+export const DISPATCH_PROVIDER_API_IDS = PROVIDER_API_IDS;
+export type DispatchProviderApiId = ProviderApiId;
+export type { ProviderApiMethod, ProviderApiRequestArgs };
+
+const runtime = createProviderApiRuntime({
+  appId: "dispatch",
+  localCredentialSource: "dispatch_local",
+  getCredentialContext: () => {
+    const ctx = getCredentialContext();
+    if (!ctx) {
+      throw new Error(
+        "Dispatch provider API requests require an authenticated request context.",
+      );
+    }
+    return ctx;
+  },
+});
+
+export function listProviderApiCatalog(provider?: DispatchProviderApiId) {
+  return runtime.listCatalog(provider);
+}
+
+export function fetchProviderApiDocs(options: {
+  provider: DispatchProviderApiId;
+  url?: string;
+  maxBytes?: number;
+}) {
+  return runtime.fetchDocs(options);
+}
+
+export function executeProviderApiRequest(args: ProviderApiRequestArgs) {
+  return runtime.executeRequest(args);
+}

package/src/server/plugins/agent-chat.ts

@@ -32,6 +32,7 @@ Use the standard workspace primitives:
 - When creating a new workspace app, create a separate app under apps/<app-id> with apps/<app-id>/package.json including a concise generated description, mount it at /<app-id>, use relative /<app-id> links, never hardcode localhost or dev ports, use shadcn/ui with @tabler/icons-react rather than lucide-react, and ensure the React Router client entry preserves APP_BASE_PATH/VITE_APP_BASE_PATH via appBasePath(). There is no separate workspace app registry to edit.
 - If the starter template is used, treat it as scaffolding only: the finished app must be branded as the requested app with its own home screen/navigation/package metadata/manifest, and must not leave visible "Starter", "Blank app", or "New app" UI behind.
 - Treat first-party apps such as Mail, Calendar, Analytics, Brain, Assets, and Dispatch as existing hosted/connected neighbors available through links and A2A/default connected agents. Do not create wrapper apps, child apps, nested routes, or cloned template copies just to give a new app access to them; build only the genuinely new workflow and delegate cross-app work to those existing apps.
+- Integration grants are not provider capability limits. For ad hoc provider inspection, querying, reporting, or troubleshooting, call provider-api-catalog/provider-api-docs, then provider-api-request against the provider's real HTTP API. Use connectionId for a specific shared grant and accountId for a specific OAuth account. Never expose secret values or silently widen app access while doing this.
 
 When a user asks for something like a digest, reminder, routing rule, or saved behavior:
 - First decide whether it should be a resource, a recurring job, a destination, or a delegated task.

package/src/server/plugins/integrations.ts

@@ -14,6 +14,7 @@ Default posture:
 - Use the available-apps prompt context first, then list-connected-agents when you need fresh details, to see what agents are available before assuming a request must be handled locally.
 - When asked whether workspace apps expose agent cards or A2A endpoints, call list-workspace-apps with includeAgentCards=true. Without that probe, missing agent-card fields mean unchecked, not unavailable.
 - Treat first-party apps such as Mail, Calendar, Analytics, Brain, Assets, and Dispatch as existing hosted/connected neighbors available through links and A2A/default connected agents. Do not create wrapper apps, child apps, nested routes, or cloned template copies just to give a new app access to them; build only the genuinely new workflow and delegate cross-app work to those existing apps.
+- Integration grants are not provider capability limits. For ad hoc provider inspection, querying, reporting, or troubleshooting, call provider-api-catalog/provider-api-docs, then provider-api-request against the provider's real HTTP API. Use connectionId for a specific shared grant and accountId for a specific OAuth account. Never expose secret values or silently widen app access while doing this.
 - Keep durable memory and operating instructions in resources rather than ephemeral chat.
 - Reply in the originating thread unless the user explicitly asks you to send to a saved destination.