Unclassified

IntegrateWise Microfrontends

Status: Implementation reference
Date: 2026-08-02
Authority: INTEGRATEWISE_ARCHITECTURE.md
Visual companion: final-architecture.html

Canonical principle

IntegrateWise owns the Platform Kernel (Spine, ADK, Discovery Engine, Capability Resolver, Loader, Normalizer, Projection Engine). Everything else — authentication, connectors, tools, models, agents, skills, workflow runtimes — is inherited from the connected host.

Three host-neutral, composable microfrontends provide invokable surfaces. Any host (IntegrateWise Web, Platform, ChatGPT, Claude, MCP Client, Agent Runtime, External App) can invoke them.

OneAuth → Total Continuity

The core product vision. One connection per host. Entire ecosystem discovers. No N×M re-connections.

The problem

Today, every host (ChatGPT, Claude, DIA, etc.) requires its own set of OAuth connections. If ChatGPT is connected to 50 apps and Claude is connected to 50 apps, the user must authenticate separately for each host × each app. This is N×M complexity.

The solution

User connects once (e.g. via ChatGPT: 50 apps)
  → OneAuth establishes identity + host context
  → Spine hydrates
  → Discovery Engine discovers all 50 connected apps from host
  → Connectors projected (not re-connected)
  → User sees data from all 50 apps immediately

User connects again (e.g. via Claude: different 50 apps)
  → Same OneAuth, same Spine
  → Claude's 50 apps also discovered
  → DIA's 3-4 apps also discovered

Result: N hosts × M apps = N+M connections (not N×M)
  → One connection per host, entire ecosystem discovers

Core principles

PrincipleMeaning
Connectors are projectionsIntegrateWise owns zero connectors. They are projections of the host environment
OneAuth = single entryOne identity → Spine hydrates → all host connections discovered
Spine = communication layerClaude's data accessible via Spine. ChatGPT's work visible via Spine. Agent-to-agent through Spine
User sees workbench onlyBehind the scene: agents, Spine, discovery, memory, tool data — all invisible
Twin = context on clickUser clicks → Twin already has context → surfaces evidence instantly
OODA + Pipeline = search/fetchPipeline stages in Spine Cache determine how to search, fetch, surface

How it works end-to-end

1. User arrives from Host X (ChatGPT, Claude, DIA, Web, Platform, etc.)
2. OneAuth establishes identity + host context
3. Spine hydrates (canonical truth loaded)
4. Discovery Engine discovers host's connected apps
5. Connector tray = projections from host (not a catalog)
6. User works in workbench — sees data from all connected apps
7. Twin has context of everything — surfaces on click
8. Agent-to-agent communication via Spine (Claude's work visible to ChatGPT)
9. Tool memory, tool data surfaced through Spine Cache
10. User never sees the infrastructure — only the workbench

What IntegrateWise owns vs inherits

IntegrateWise ownsInherited from host
OneAuth (identity)OAuth connections
Spine (canonical truth)Provider credentials
ADK (agent contracts)Tool implementations
Discovery EngineConnected apps
Capability ResolverTool capabilities
Loader + NormalizerProvider data formats
Projection EngineHost-specific UI
OrchestratorAgent runtimes
Agent MemoryTool memory
SkillsHost-native skills

Connection model

Host A (ChatGPT: 50 apps)
  → OneAuth → Spine → Discovery → 50 connectors projected

Host B (Claude: 50 apps)
  → Same OneAuth → Same Spine → 50 more connectors projected

Host C (DIA: 3 apps)
  → Same OneAuth → Same Spine → 3 more connectors projected

Total: 3 hosts, 103 apps, 3 connections (not 309)

Three microfrontends

#Packagenpm nameRoleStatus
1packages/auth-connectors-mfe@integratewise/auth-connectors-mfeUniversal identity, grants, discovery, connector tray, capability matrices✅ Scaffolded
2packages/auth-onboarding-mfe@integratewise/auth-onboarding-mfeLogin / signup / onboarding flow✅ Scaffolded
3packages/platform-mfe@integratewise/platform-mfePlatform Control Board — all kernel features✅ Scaffolded

1. Auth + Connectors MFE

Purpose: Universal identity, connection management, discovery, and capability-access layer.

Not bound to the platform — consumable by any host:

  • apps/web, apps/platform
  • Twin Orchestrator, platform agents
  • ChatGPT, Claude, MCP clients
  • Plugin hosts, external applications
  • Agent runtimes

Surfaces

SurfaceDescription
/authLogin, signup, OAuth, session management
/connectorsConnector tray — projections from connected host
/marketplaceConnector marketplace (browsable unauthenticated)
/discoveryHost discovery results
/grantsScoped access grants
/capabilitiesCapability matrix, connected-tool matrix, tool-capability matrix
/spineBusiness context with connected/tool-capability matrices

Architecture

Host connection context
  → One Auth establishes identity + host
  → Discovery Engine discovers host resources
  → Connector tray = projections from host
  → Capabilities resolved from host tools
  → User sees only what host provides

Host is detected during onboarding, not selected at runtime.

Key components

  • AuthConnectorsProvider — context provider with auth + connector state
  • AuthConnectorsShell — main container
  • LoginForm / SignUpForm — authentication forms
  • OAuthButtons — Google, GitHub, Microsoft, Slack
  • ConnectorCatalog — host-projected connector grid
  • ConnectorCard — individual connector display
  • ConnectorInstallModal — OAuth/API key installation flow
  • OnboardingFlow — multi-step wizard with host detection
  • UserAvatar — user display component
  • AuthGuard — route protection

Hooks

  • useAuth() — authentication state and actions
  • useConnectors() — connector state and actions
  • useOnboarding() — onboarding state
  • useHostEnvironment() — host environment (admin-only, not user-facing)

2. Auth + Onboarding MFE

Purpose: Simplified login/signup/onboarding flow, independent of connector management.

Key components

  • AuthOnboardingProvider — simplified auth context (no connectors)
  • LoginForm / SignUpForm / OAuthButtons — authentication
  • OnboardingFlow — multi-step wizard
  • AuthGuard — route protection

Hooks

  • useAuth() — authentication state
  • useOnboarding() — onboarding state

3. Platform MFE

Purpose: Platform Control Board — the complete control plane surface.

Kernel views (IntegrateWise-owned)

ViewComponentDescription
Spine FabricSpineFabricViewOperational DB fabric: cache ↔ canonical ↔ KV ↔ R2 ↔ Redis ↔ AI Search ↔ Omni Router
Spine NetworkSpineNetworkViewVisual graph of Spine nodes and edges
OODA PipelineOODAPipelineViewObserve → Orient → Decide → Act pipeline
Agent StatusAgentStatusView5 bounded agents + Co-worker status
Memory QueuesMemoryQueuesViewMemory Queue + Approval Queue + Promotion Queue + 10 memory categories
Tool CapabilityToolCapabilityMatrixViewHost-connected tools → capabilities → workspace projection
ConfigurationConfigurationManagerViewTenant, schema, connector, projection configuration
ActivationActivationManagerViewActivation status, blockers, go-live checklist

Platform kernel (what IntegrateWise owns)

IntegrateWise Platform Kernel
├── Spine (canonical tenant truth)
├── Spine Schema
├── Business Context
├── ADK (Agent Development Kit)
├── Discovery Engine
├── Capability Resolver
├── Loader
├── Normalizer
├── Schema Mapping
├── Reconciliation
├── Projection Engine
└── Workspace Composition

Agents (5 bounded)

AgentRoleUser-facing
TwinCommunicator + Orchestrator✅ Yes
TriageCommunicator + Router✅ Yes (through Twin)
Schema GeneratorInternal — schema proposals❌ Internal
Schema OrchestratorInternal — schema lifecycle❌ Internal
Auto-TunerInternal — system optimization❌ Internal
Co-workerExecution worker❌ Internal

Memory system (10 categories)

CategoryAuthorityRetention
OperationalSpine canonical writerDurable
Event / EpisodicEvent runtimeDurable / policy
Work / ContinuityContinuity runtimeUntil closure + policy
TwinMemory serviceVersioned, revocable
SessionTwin runtimeRetention-controlled
OrganizationalTriage/promotion + governanceDurable, versioned
KnowledgeKnowledge serviceRebuildable from sources
AuditGovernanceAppend-only, high retention
ArtifactObject storageRetention / classification
Retrieval / CacheProjection / runtimeDisposable, rebuildable

Spine Fabric

The operational database fabric connecting:

  • Spine Cache — operational DB (hot data)
  • Canonical Spine — source of truth
  • KV Store — configuration and session state
  • R2 Storage — object blobs (documents, artifacts)
  • Redis — hot cache and pub/sub
  • AI Search — vector + FTS (1536 dimensions)
  • Omni Router — multi-protocol routing

Data flow tunnel

Host Tools → Loader → Normalizer → Spine Cache → Canonical Spine → Projection Engine → Workspace

Design tokens

All three MFEs use packages/*/src/lib/design-tokens.ts as the single source of truth for colors, spacing, typography, and shadows. Derived from apps/web/src/integratewise-figma-tokens.json.

Color palette

TokenValueUsage
primary#5b814f (Forest Green)Actions, links, active states
background#f7f6f2 (Paper)Page background
foreground#0c0c0c (Ink)Primary text
card#f0ede7 (Paper Warm)Card backgrounds
border#c8c3b8 (Rule)Borders and dividers
goldAccent#b8943f (Gold)Complementary accent
destructive#d03131 (Red)Errors and warnings

Host detection architecture

The host is identified during onboarding/activation, not selected at runtime:

  1. User arrives from Host X (ChatGPT, Claude, Web, Platform, MCP Client, etc.)
  2. One Auth establishes identity + host context
  3. Discovery Engine runs against Host X
  4. Connector tray = projections from Host X
  5. User sees only what Host X provides

The HostSelector component exists for admin/configuration use only — visible in the Configuration Manager, not to end users.

Composition

Composed surfaces (microfrontend + platform):

  • Platform + Web (Customer Zero workbench)
  • Platform + Ops (operational view)
  • Web standalone (marketing + business app)
  • MCP Client thin client
  • ChatGPT/Claude plugin host

Each is a microfrontend if not a separate deployment.

Build order

  1. Phase 1 — Contracts & shell: workspace route, projection-driven sidebar, Home, My Work, Twin drawer
  2. Phase 2 — Operational UI: Configuration Manager, Activation Manager, Discovery Engine, Capability Explorer
  3. Phase 3 — Network visualization: Spine Network, Agent Communication, Tool Execution Graph
  4. Phase 4 — Workbench integration: contextual capability dock, invocation, approval cards
  5. Phase 5 — Cross-repo SDK: @integratewise/* packages so channel repos consume, never copy