@tangle-network/agent-integrations 0.25.1 → 0.25.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -25,6 +25,7 @@ provider SDK.
25
25
  - [Product Adoption](#product-adoption)
26
26
  - [Provider Strategy](#provider-strategy)
27
27
  - [Executable Coverage](#executable-coverage)
28
+ - [Product Hub Ownership](#product-hub-ownership)
28
29
  - [Examples](#examples)
29
30
  - [Security Model](#security-model)
30
31
  - [Development](#development)
@@ -48,9 +49,9 @@ provider SDK.
48
49
  executable backend state explicit.
49
50
  - A canonical registry that deduplicates overlapping catalogs, keeps support
50
51
  tiers explicit, and reports auth/category conflicts.
51
- - App/agent manifests, grants, and sandbox bundles so Builder, generated apps,
52
- domain agents, Blueprint Agent, and executor-backed runtimes can reuse the
53
- same user-owned connections safely.
52
+ - App/agent manifests, grants, and sandbox bundles so generated apps, domain
53
+ agents, and executor-backed runtimes can reuse the same user-owned
54
+ connections safely.
54
55
  - Workflow trigger installation and normalized event dispatch for non-agent UI
55
56
  automation, sync jobs, webhooks, and product workflows.
56
57
  - Approval persistence, audit events, healthchecks, credential resolution,
@@ -246,7 +247,7 @@ Generated app code should use the tiny client instead of raw provider tokens:
246
247
 
247
248
  ```ts
248
249
  const integrations = createTangleIntegrationsClient({
249
- endpoint: 'https://id.tangle.tools',
250
+ endpoint: 'https://integrations.example.com',
250
251
  env: process.env,
251
252
  })
252
253
 
@@ -273,6 +274,16 @@ agent runs.
273
274
  For a full product checklist, see
274
275
  [External Product Integration](./docs/external-product-integration.md).
275
276
 
277
+ ## Product Hub Ownership
278
+
279
+ Use a hosted hub when multiple apps intentionally share identity, billing,
280
+ consent, and connection custody. Use a product-owned hub when a standalone
281
+ deployment needs its own customer boundary, OAuth branding, vault, policy, or
282
+ data residency. Both modes use the same package contracts.
283
+
284
+ See [Product Hub Ownership](./docs/product-hub-ownership.md) for the
285
+ deployment model and launch gates.
286
+
276
287
  ## Provider Strategy
277
288
 
278
289
  The package deliberately avoids vendor lock-in.
@@ -63,7 +63,7 @@ import {
63
63
 
64
64
  const provider = createTangleCatalogExecutorProvider({
65
65
  executeAction: createTangleCatalogHttpExecutor({
66
- endpoint: 'https://id.tangle.tools/integration-runtime',
66
+ endpoint: 'https://integrations.example.com/integration-runtime',
67
67
  secret: process.env.TANGLE_CATALOG_RUNTIME_SECRET,
68
68
  }),
69
69
  })
@@ -0,0 +1,126 @@
1
+ # Integration Hub Ownership
2
+
3
+ Status: deployment guidance
4
+
5
+ This document describes where integration custody should live when a product
6
+ uses `@tangle-network/agent-integrations`.
7
+
8
+ ## Decision
9
+
10
+ Use one contract everywhere, not one deployment everywhere.
11
+
12
+ - Products that share identity, billing, and consent can use a hosted platform
13
+ hub.
14
+ - Standalone products can run a product-owned hub.
15
+ - Both modes must use `@tangle-network/agent-integrations` contracts:
16
+ `IntegrationSpec`, `IntegrationManifest`, `IntegrationGrant`, capability
17
+ bundles, `/v1/integrations/invoke`, approvals, healthchecks, audit, webhooks,
18
+ and provider/runtime adapters.
19
+ - Product-owned hubs may federate to a hosted platform hub when the deployment
20
+ wants a shared connection wallet.
21
+
22
+ The package defines the shared protocol. Each deployment decides where to store
23
+ connections, secrets, grants, approvals, audit records, and workflow state.
24
+
25
+ ## Ownership Modes
26
+
27
+ | Mode | Use When | Owns OAuth, Vault, Audit | Invocation Path |
28
+ |---|---|---:|---|
29
+ | Hosted platform hub | Multiple apps share account, consent, billing, and connection custody | Platform service | App/sandbox calls platform hub or product proxy with scoped capability |
30
+ | Product-owned hub | Standalone SaaS, private deployment, or customer-owned data boundary | Product app | App/sandbox calls product `/v1/integrations/invoke` |
31
+ | Federated product hub | Product wants local policy with remote connection custody | Product policy + hosted custody | Product issues local grants over remote platform connections |
32
+
33
+ The important invariant: sandboxes and generated apps never receive provider
34
+ refresh tokens, API keys, or raw OAuth credentials in any mode.
35
+
36
+ ## Where Duplication Is Bad
37
+
38
+ Fully duplicating hubs is bad when apps are intentionally part of the same
39
+ account system:
40
+
41
+ - Users reconnect Gmail, Slack, GitHub, and Drive in every app.
42
+ - OAuth app verification, scopes, redirect configuration, and consent review
43
+ are repeated.
44
+ - Revocation, audit, healthchecks, and billing attribution fragment.
45
+ - Generated apps cannot inherit a user's already-approved connection.
46
+
47
+ For those deployments, use a hosted hub as the connection source of truth and
48
+ pass scoped grants down to apps, sandboxes, and agents.
49
+
50
+ ## Where Centralization Is Bad
51
+
52
+ Forcing every deployment through a hosted platform hub is bad when the product
53
+ needs a separate customer, compliance, or operational boundary:
54
+
55
+ - The buyer may not want shared identity or billing in their end-user flow.
56
+ - Enterprise deployments may require product-branded OAuth apps, product-owned
57
+ vaults, customer-managed keys, private networking, or data residency.
58
+ - Product-specific subscriptions and compliance boundaries may not match the
59
+ platform account model.
60
+ - A central platform outage should not necessarily take down a standalone app.
61
+
62
+ For those products, run a product-owned hub using the same package contracts.
63
+ Optionally add federation to a hosted platform hub as a deployment choice.
64
+
65
+ ## Execution Checklist
66
+
67
+ - [x] One stable contract for specs, manifests, grants, capabilities, invocation,
68
+ approvals, healthchecks, webhooks, audit, and bridge payloads.
69
+ - [x] Long-tail connector contracts and runtime-backed execution path are
70
+ represented without leaking external catalog names into product UX.
71
+ - [x] External product adoption guide documents product-owned deployment.
72
+ - [x] This ownership decision documents platform versus product-owned custody.
73
+
74
+ ### Hosted Hub Bar
75
+
76
+ - [ ] The hosted hub has production stores for connections, grants, approvals,
77
+ audit, healthchecks, workflows, webhook events, and idempotency.
78
+ - [ ] The hosted hub vault/KMS stores raw OAuth/API-key credentials behind
79
+ secret refs.
80
+ - [ ] The hosted hub exposes connect, callback, revoke, rotate, approve, audit,
81
+ healthcheck, and `/v1/integrations/invoke`.
82
+ - [ ] Sandbox and generated-app launches receive
83
+ `buildIntegrationBridgeEnvironment()` output.
84
+ - [ ] Browser E2E covers connect, consent, preview, invoke read, approval write,
85
+ revoke, expired token recovery, and missing-connection recovery.
86
+
87
+ ### Product-Owned Hub Bar
88
+
89
+ - [ ] The product chooses local hub or federated platform hub per deployment.
90
+ - [ ] Local hubs use `IntegrationHub`; custom provider switch statements are
91
+ removed or wrapped as `IntegrationProvider` implementations.
92
+ - [ ] The product stores connections, grants, approvals, audit, healthchecks,
93
+ workflows, events, and idempotency in its own database.
94
+ - [ ] The product uses its own vault/KMS or explicitly delegates secret custody
95
+ to a hosted hub.
96
+ - [ ] The product has live OAuth/API-key setup UI generated from
97
+ `IntegrationSpec`.
98
+ - [ ] The product has browser E2E personas using real product UX and live
99
+ integration secrets where available.
100
+
101
+ ## Product E2E Gates
102
+
103
+ Run these before launch for every product adopting integrations:
104
+
105
+ 1. Existing connection: user asks for a task requiring Gmail, Calendar, Slack,
106
+ GitHub, Drive, Sheets, or CRM data; agent detects the existing connection and
107
+ uses it without asking for manual copy/paste.
108
+ 2. Missing connection: user asks for the same task without a connection; product
109
+ renders connect/consent in flow, resumes the task after OAuth, and does not
110
+ lose conversation state.
111
+ 3. Generated app preview: generated software declares an
112
+ `IntegrationManifest`; preview requests user consent, receives scoped
113
+ capabilities, and reads provider data through the invoke endpoint.
114
+ 4. Write approval: generated app or agent proposes a write/send/update action;
115
+ product requires approval, records audit, and executes once with idempotency.
116
+ 5. Revocation: user revokes a connection; existing grants fail closed and the UI
117
+ explains how to reconnect.
118
+ 6. Healthcheck failure: expired or revoked upstream credentials surface in admin
119
+ UI and task UX without exposing secrets in logs or traces.
120
+
121
+ ## Recommendation
122
+
123
+ Do not fork integration semantics by product. Make hub custody a deployment
124
+ choice while keeping the protocol stable. Hosted hubs, product-owned hubs, and
125
+ federated hubs should all expose the same manifest, grant, capability, approval,
126
+ audit, webhook, and invocation shapes.
@@ -74,9 +74,9 @@ Use gateway-backed coverage for the next large tranche:
74
74
  - long-tail CRM/support/helpdesk systems
75
75
  - vendor-specific workflow triggers
76
76
 
77
- This gives Agent Builder useful breadth immediately without forcing us to own
78
- hundreds of OAuth apps, refresh-token edge cases, webhook subscription models,
79
- rate-limit policies, and provider-specific APIs on day one.
77
+ This gives products useful breadth immediately without forcing every team to
78
+ own hundreds of OAuth apps, refresh-token edge cases, webhook subscription
79
+ models, rate-limit policies, and provider-specific APIs on day one.
80
80
 
81
81
  ## When To Roll Our Own
82
82
 
@@ -12,8 +12,8 @@ const consent = renderConsentSummary(manifest, { appName: 'Exercise Planner' })
12
12
 
13
13
  console.log(consent.body)
14
14
 
15
- // In production this bundle comes from id.tangle.tools after the user grants
16
- // the generated app access to their Google Calendar connection.
15
+ // In production this bundle comes from the product integration hub after the
16
+ // user grants the generated app access to their Google Calendar connection.
17
17
  const bundle: IntegrationSandboxBundle = {
18
18
  manifestId: manifest.id,
19
19
  subject: { type: 'sandbox', id: 'sandbox_preview_1' },
@@ -64,7 +64,7 @@ const bundle: IntegrationSandboxBundle = {
64
64
 
65
65
  const env = buildIntegrationBridgeEnvironment(bundle)
66
66
  const client = createTangleIntegrationsClient({
67
- endpoint: 'https://id.tangle.tools',
67
+ endpoint: 'https://integrations.example.com',
68
68
  env,
69
69
  })
70
70
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@tangle-network/agent-integrations",
3
- "version": "0.25.1",
3
+ "version": "0.25.2",
4
4
  "description": "Vendor-neutral integration contracts and runtime helpers for sandbox and agent apps.",
5
5
  "homepage": "https://github.com/tangle-network/agent-integrations#readme",
6
6
  "repository": {
@@ -38,15 +38,6 @@
38
38
  "publishConfig": {
39
39
  "access": "public"
40
40
  },
41
- "scripts": {
42
- "build": "tsup",
43
- "dev": "tsup --watch",
44
- "audit:execution": "pnpm build >/dev/null && node scripts/audit-integration-execution.mjs",
45
- "prepare": "tsup",
46
- "test": "vitest run",
47
- "test:watch": "vitest",
48
- "typecheck": "tsc --noEmit"
49
- },
50
41
  "devDependencies": {
51
42
  "@types/node": "^25.6.0",
52
43
  "tsup": "^8.0.0",
@@ -57,5 +48,12 @@
57
48
  "node": ">=20"
58
49
  },
59
50
  "license": "MIT",
60
- "packageManager": "pnpm@10.28.0"
61
- }
51
+ "scripts": {
52
+ "build": "tsup",
53
+ "dev": "tsup --watch",
54
+ "audit:execution": "pnpm build >/dev/null && node scripts/audit-integration-execution.mjs",
55
+ "test": "vitest run",
56
+ "test:watch": "vitest",
57
+ "typecheck": "tsc --noEmit"
58
+ }
59
+ }