Doctrine And Sales Narrative
EXTRACTED / NOT CANONICAL. This narrative is preserved as source material.
Its old product naming, Descope authority, storage and UI-layer claims must not
override../architecture/ARCHITECTURE_LOCK.md.
IntegrateWise
The Operational Continuity Platform
Canonical Doctrine, Architecture, and Sales Narrative — Final v2
The One Immutable Rule
Everything outside the Business Platforms is replaceable.
Everything inside the Business Platforms is versioned and contract-driven.
This sentence governs the entire system. It governs the product, the architecture, the company, and every decision that follows. If a new idea violates this rule, the idea is wrong. If a new tool violates this rule, the tool is replaced. If a new document violates this rule, the document is superseded.
Everything below this line is an expression of this rule.
Part I — The World That Broke
The promise that was never kept
Software was supposed to make work easier. Instead it made work fragmented.
Every tool you connect to — your CRM, your chat, your project tracker, your AI assistant — starts from zero. None of them know what the others know. Your context dies the moment you switch tabs. Your memory resets every time you open a new AI conversation. Your data is locked inside someone else’s schema, someone else’s platform, someone else’s business model.
So you do what every knowledge worker does today. You become the integration. You copy context from Salesforce into Slack. You re-brief your AI assistant from scratch every morning. You build the same understanding in three different tools because none of them share it. You spend your day not doing your job — you spend it being the human API between systems that should already know each other.
This is not a tooling problem. It is an architecture problem. And IntegrateWise solves it.
Three frustrations, one root cause
“I say the same thing to every AI again.”
No shared memory exists. Each AI starts blank. You spend your time re-briefing instead of building on what was already established. Every morning is Groundhog Day for your context.
“My context gets lost when I switch tools.”
Context is trapped inside each tool. Your CRM knows one thing. Your project tracker knows another. Your support desk knows a third. Nothing connects them. The understanding you need lives in the gaps between your tools, not in any one of them.
“I can’t move my data — I’m locked in.”
The data lives inside the platform, not with you. The moment you leave, your context vanishes. Every tool you adopt makes it harder to leave, not because the tool is good, but because your context is trapped inside it.
The root cause is the same every time: there is no shared memory layer. Tools connect to each other through point-to-point integrations or through you — the human doing the work of a bridge by hand.
What the industry is doing wrong
The current market solves the wrong problem at every level.
Automation players (Zapier, Make, n8n) connect apps. They move data from one place to another through triggers and automations. That is plumbing. It is useful, but it does not preserve context across time. A Zap passes a record; it does not remember why the record matters, what happened before it arrived, or what should happen next.
Enterprise integration players (Workato, Tray, MuleSoft, Boomi) go deeper. They orchestrate workflows across enterprise systems. But the intelligence is still in the workflow definition, not in the data. Change the workflow, lose the reasoning.
AI search players (Glean, Dashworks) index everything and let you ask questions. But they are readers, not actors. They can tell you what happened; they cannot propose what to do about it and wait for your approval.
Workspace players (Notion, Coda, Linear) give you a surface to work on. But the surface is disconnected from your operational tools. You still have to bring the context in by hand.
AI chat players (ChatGPT, Claude, Copilot) give you intelligence. But each conversation starts from zero. There is no persistent memory, no organizational context, no governance layer between the AI and your operations.
Connector platforms (Replit, Vercel) give you infrastructure to build and deploy. But they connect tools to code, not context to decisions. The developer is still the integration layer.
Every category solves a piece. None of them owns the layer between. The layer that carries context across tools, across time, across people, across AI providers. The layer that makes work continuous instead of fragmented.
That layer is IntegrateWise.
Part II — The Shift
The category that did not exist
The category is not automation. It is not AI search. It is not workspace. It is not integration. It is not a platform you build on.
The category is operational continuity — the infrastructure that preserves identity, context, memory, governance, and execution across every consumer in your organization.
IntegrateWise does not replace your tools. It does not replace your AI. It sits beneath all of them and makes them share the same truth.
They connect apps. IntegrateWise connects context.
The human shift
Part III — The Doctrine
Three sentences that govern everything
Truth you own.
The data in your workspace — your entities, your relationships, your history — belongs to your organization. It lives in the Spine. You can see it, manage it, export it. No tool locks it away. No provider owns it. The context stays with you forever.
AI you rent.
The reasoning layer — the model that reads your context and proposes actions — is replaceable by design. Today it might be GPT. Tomorrow it might be Claude, Gemini, Grok, or a model that does not exist yet. You swap models by configuration, not by migration. The AI serves your context; your context never serves the AI.
Approval in between.
Every action the AI proposes passes through a governance gate before it touches anything real. High-confidence actions auto-execute with a full audit trail. Medium-confidence actions surface on your desk for review. Low-confidence actions are discarded. You are always in control. The AI does not drift. It does not hallucinate into execution. It proposes within your boundaries and waits.
Truth you own. AI you rent. Approval in between.
The architecture doctrine
Build capabilities once. Experience them anywhere. Deploy them anywhere.
Capabilities are the reusable business contract. Experiences are the user-facing projections. Deployment Profiles are the runtime implementations. Everything else — models, clouds, databases, frameworks — is just an implementation choice behind those contracts.
The product doctrine
IntegrateWise has two user journeys — one to establish continuity, and one to operate with continuity. The first optimizes time-to-first-value. The second optimizes continuous operational value. They share one Continuity Platform that compounds every day.
The capability doctrine
Capabilities are resolved inside the Orient phase of the OODA loop. Users never select capabilities manually. The Twin resolves the right Platform Capability based on context. The user sees proposals, not menus.
The three scopes of doctrine
The single sentence that unifies all three:
You own the truth (Spine) over which any AI you rent (Twin) reasons — and every execution must pass through an approval token before it touches the outside world (Governance Gate).
Part IV — The Product
IntegrateWise
IntegrateWise is the Operational Continuity Platform — the infrastructure layer that preserves context, memory, and governance across every tool, every person, and every AI in your organization.
It is one platform. Not a connector marketplace. Not an automation engine. Not another AI chatbot with a plugin directory. It is the governed middle that sits beneath all your tools and all your AI providers, carrying context forward so nothing is forgotten and nothing executes without your approval.
The product promise: nothing important is forgotten.
You brief it once. It remembers everything. Every platform you use — every AI, every tool, every assistant — gets the same truth without you having to repeat yourself.
What customers buy — five promises
One Human Worksurface
Your workbench. One place where you see everything that matters — your customers, your deals, your tasks, your signals, your metrics — without switching tabs or re-querying tools. The workbench adapts to you: your role, your department, your industry, your connected tools. No two workbenches look the same, because no two people have the same context.
AI Home — Your Digital Twin
The Twin is not a chatbot you open when you have a question. It is a persistent reasoning engine that is always working, always grounded in your Spine, always governed by your approval rules. It observes. It proposes. It waits for your signal. It learns from every outcome. It lives in its own home within the platform — reasoning over your context, surfacing insights, proposing actions — while you work uninterrupted.
Shared Continuity
One Spine. One memory. Every tool reads from it, writes to it, and benefits from what the others contributed. The context compounds. Each day your workspace knows more than the day before. Memory does not reset when you switch tools, switch AI providers, or switch devices. It stays.
Connected Ecosystem
Connect once. Your Spine hydrates. Memory starts flowing. Adding a third tool is an enable toggle, not a project. The platform supports every major connector through MCP-first ingestion with Descope as the canonical authorization authority for outbound connections; Nango remains only as dormant compatibility for providers Descope outbound does not yet support. Your tools talk to each other through the platform — you never become the bridge between them.
Governed Intelligence
Every AI action passes through a governance gate. Confidence-scored proposals. Human-in-the-loop approval for medium-risk actions. Auto-execute for high-confidence actions with full audit trail. Discard for low-confidence noise. The governance layer never opens. Even the platform operator cannot bypass it.
Solutions — what customers actually use
Each solution is a projection of the same underlying Spine. The data does not change; the perspective does.
The Human Worksurface — without context switching
The workbench is not another dashboard. It is the surface where your work actually happens.
View. Obtain. Execute. Not just a list of data. A place where you can see your leads, qualify them, move them through stages, and convert them — with context and knowledge flowing from every connected tool and from the Twin’s reasoning.
No context switching. Your CRM data, your support signals, your communication history, your task status, your AI proposals — all on one surface. You never leave to go find something in another tool. It comes to you.
Your surface, shaped by you. Identity, role, department, industry, connected tools — all shape the projection. The surface adapts to how you work, not the other way around.
Human stops being the API. The old pattern: open Salesforce, copy the context, paste it into Slack, re-explain it to the AI, check the project tracker, update the spreadsheet. The new pattern: everything is already on your surface. The tools talk to each other through the Spine. You do the work, not the integration.
Part V — The Architecture
The final hierarchy
VISION
Operational Continuity
│
▼
PRODUCT
IntegrateWise
│
▼
SOLUTIONS
Sales · CS · Ops · Executive · Knowledge
│
▼
EXPERIENCES
Web · Desktop · Mobile · CLI · Slack · Teams · Partner · Embedded
│
▼
BUSINESS PLATFORMS
Identity · Connectivity · Integration Manager · Continuity · Capability Fabric · Governance
│
▼
EXECUTION PLATFORMS
Intelligence · Runtime · Storage · Search · Messaging · Deployment · Observability
│
▼
DEPLOYMENT PROFILES
Cloudflare Native · Vercel Native · Replit Native · Docker Native · Kubernetes Native · AWS Native · Azure Native
│
▼
TECHNOLOGY
Workers · D1 · Postgres · Redis · S3 · Queues · Vector DBs · etc.
Seven layers. Each independent. Each replaceable below the Business Platforms. The layers above change slowly (vision, product, solutions). The layers below change freely (execution, deployment, technology). The Business Platforms are the stable contract in the middle — versioned, backward-compatible, and never bypassed.
Three kinds of platforms
The architecture recognizes three distinct kinds of platforms. They serve different audiences and change at different speeds.
Business Platforms — your IP
These are what customers buy. They are stable, versioned, and contract-driven. They do not change.
Execution Platforms — replaceable
These are how the system runs. They can change freely without changing the product.
Experience Platforms — unlimited
These are where people work. Any surface that can call Projection APIs over a Gateway JWT is a valid experience.
Each experience consumes only the capabilities it needs. A Slack app needs approvals and signals, not the full workbench. A desktop app needs the complete experience. Both call the same Projection APIs. Both see the same Spine.
Capability Fabric — the center of everything
Everything orbits capabilities.
Experiences
│
▼
Capability Fabric
┌──────────┼──────────┐
▼ ▼ ▼
Continuity Intelligence Governance
│ │ │
└─── Integration Manager ───┘
│
Connectivity
│
Identity
Capabilities are the language of the platform.
Frontends consume capabilities.
AI reasons over capabilities.
Governance protects capabilities.
Continuity stores capability state.
Integration Manager hydrates capabilities.
No surface ever talks to raw tools.
No AI ever holds raw credentials.
No connector ever writes directly to the Spine.
Three capability types
The critical distinction: Provider Capabilities are resolved at activation. Platform Capabilities are resolved at runtime by the Twin during the Orient phase of OODA. Experience Capabilities are resolved by the surface based on device and context. The user never manually selects any of them.
Deployment Profiles
Deployment is not infrastructure. Deployment is a product choice.
Each Deployment Profile implements the same platform contracts:
The profiles
Cloudflare Native — Workers · D1 · KV · R2 · Durable Objects · Queues · Vectorize · Workers AI
Vercel Native — Functions · Edge Functions · Postgres · Blob · KV · AI SDK
Replit Native — Replit Deployments · PostgreSQL · Object Storage · Secrets · Always On
Docker / Kubernetes Native — Containers · PostgreSQL · Redis · MinIO · NATS
AWS Native — Lambda · RDS · S3 · SQS · Bedrock · CloudWatch
Azure Native — Functions · Cosmos DB · Blob · Service Bus · Azure AI
On-Prem Native — Customer Infrastructure · PostgreSQL · Redis · MinIO · NATS
Each is a first-class deployment profile, not a port or secondary target. They all implement the same platform contracts, so the customer chooses the deployment environment without changing the product.
IntegrateWise is not built on Cloudflare, Vercel, or Replit. It runs natively on any of them.
Deployment Profile → Infrastructure Provider → Technology
Deployment Profile Infrastructure Provider Technology
───────────────── ─────────────────────── ──────────
Replit Native Replit Platform Postgres · Object Storage · Secrets
Cloudflare Native Cloudflare Platform Workers · D1 · KV · R2 · DOs · Queues
Vercel Native Vercel Platform Functions · Postgres · Blob · AI SDK
Docker Native Container Runtime PostgreSQL · Redis · MinIO · NATS
Two doors, one Spine
The architecture has exactly two external boundaries, with the Spine between them.
North Plane — The API Gateway. Every consumer enters here. AI assistants over inbound MCP. Experiences over capability calls. External agents over the public API. The Gateway authenticates, resolves the tenant, routes to the right capability, and enforces rate limits.
South Plane — The Integration Router. Every outbound action exits here. The Router picks the right adapter, injects context, manages credentials, and monitors health.
Neither plane talks to the other except through the Spine. That is the invariant that makes everything else work: tenant isolation, governance enforcement, audit completeness, and storage swappability all depend on it.
Part VI — The Three Planes
The principle
IntegrateWise is not one experience. It is three planes that a user moves through at different speeds, with different levels of visibility into the platform’s internals.
EXPERIENCE PLANE CONTINUITY PLANE EXECUTION PLANE
(What users see) (What we build) (How work happens)
Marketplace Capability Discovery Human Worksurface
Discovery Identity Binding Digital Twin
Install Initial Hydration Governance
Connect Once Memory Formation OODA Loop
Human Worksurface Relationship Binding Continuous Learning
Context Assembly
Spine
GTM surface. The moat. Daily work.
Users enter here. Nobody sees this. Users live here.
Experience Plane — what users see
The user is not yet a customer. They are browsing, evaluating, clicking. This is the GTM surface.
The journey:
AI Marketplace (ChatGPT, Claude, Perplexity, Gemini)
↓
Install
↓
Authenticate Workspace
↓
Connect Once
↓
Human Worksurface Opens
The user’s psychology: “What is this? Does it do what I need? Is it worth trying?”
The success metric: Install and authenticate. That is the only conversion that matters at this plane.
What the user sees: One listing. One promise. One click. The listing explains the value in outcomes, not architecture.
What the user does NOT see: Connectors. Capabilities. MCP. Normalization. Spine. Any architectural concept.
Continuity Plane — what IntegrateWise builds
This is the moat. Nobody sees it. But this is what differentiates IntegrateWise from every other product in the market.
The journey — “Continuity Activation”:
Connect Once
↓
Capability Discovery
(What can Salesforce do? What can Slack do?
Not data selection. Capability surfacing.)
↓
Identity Binding
(Who is this user? What tenant? What role?
What department? What industry?)
↓
Bootstrap Hydration
(Latest 30 days. Selected entities.
Enough to prove value. Minutes, not hours.)
↓
Continuity Ready
(Spine has enough context to be useful.
Workbench opens.)
↓
Background Enrichment
(Full historical sync.
Entity resolution across tools.
Memory extraction.
Knowledge graph building.
Relationship mapping.
Signal generation.
Runs quietly while the user works.)
↓
Continuous OODA
(Never stops.
Every observation enriches the Spine.
Every action writes back.
Every cycle makes the next richer.)
The three hydration phases:
Key principle: The workbench opens before everything is synchronized. The user gets value from partial hydration. Background enrichment runs while they work. The user never waits.
The Integration Manager owns activation. Not Connectivity. The Integration Manager handles the full activation flow and then, after activation, becomes mostly invisible — streaming changes forever through the Connectivity Platform.
Execution Plane — how work happens
This is daily work. This is OODA. This is where the user lives 95% of the time.
The user’s daily loop:
Open workbench
↓
See what matters
(Signals, insights, risks, opportunities — surfaced by the Twin)
↓
Review Twin proposals
(On My Desk. Confidence-scored. With evidence.)
↓
Approve or modify
(One click. The governance gate.)
↓
Continue working
(The approved action executes through the Integration Router.)
↓
Context updates
(Writeback to Spine. Next observation is richer.)
↓
Close workbench
(Twin continues working in the background.)
The user’s psychology: “I have work to do. Show me what matters. Let me act on it.”
The success metric: The user completes their core workflow without switching to another tool. Time-to-answer for key questions decreases over time as memory compounds.
What the user does NOT experience: Capability selection. Connector management. MCP protocol. Normalization pipeline. Entity resolution. Memory classification. Any architectural concept.
The user thinks about their work — their customers, their deals, their signals, their decisions. The platform thinks about everything else.
Part VII — The Two Products
Two products, one Continuity Platform
┌─────────────────────────────────────────────────────────┐
│ │
│ ONE CONTINUITY PLATFORM │
│ │
│ Spine · Memory · Entity Resolution · Governance │
│ │
├────────────────────────┬────────────────────────────────┤
│ │ │
│ ACTIVATION PRODUCT │ OPERATIONAL PRODUCT │
│ │ │
│ KPI: │ KPI: │
│ Time-to-first-value │ Daily active value │
│ │ │
│ Marketplace │ Human Worksurface │
│ Discovery │ Digital Twin │
│ Connect Once │ Governance │
│ Capability Disc. │ OODA Loop │
│ Bootstrap Hydration │ Continuous Learning │
│ │ │
│ Minutes │ Forever │
│ Disposable │ Permanent │
│ Fast, simple, clear │ Deep, compounding, growing │
│ │ │
└────────────────────────┴────────────────────────────────┘
The Activation Product is designed to be consumed and discarded. Its job is to get the user from “what is this?” to “my workspace is ready” as fast as possible. Once the Continuity Platform is activated, the Activation Product’s job is done. The user transitions to the Operational Product and never sees the Activation flow again — unless they add a new connector.
The Operational Product is designed to be the permanent surface. Its job is to deliver daily value through the OODA loop while the Continuity Platform compounds in the background. The longer the user works, the richer the platform becomes. It gets better every day, not because the code changes, but because the context deepens.
They share one Continuity Platform. The Spine, Memory, Entity Resolution, and Governance serve both products. The Activation Product writes the first entities into the Spine. The Operational Product reads from and writes back to the same Spine. Context accumulated during activation enriches daily work. Context accumulated during daily work makes future activations faster and richer.
Part VIII — OODA as Architectural Law
The original OODA loop
Colonel John Boyd developed the OODA loop to explain why some pilots consistently won dogfights. It was not about faster aircraft. It was about faster decisions.
OBSERVE → ORIENT → DECIDE → ACT
↑ │
└───────────────────┘
Observe — Gather data from the environment.
Orient — Analyze and synthesize against prior knowledge. Boyd called this the schwerpunkt — the center of gravity of the entire loop. Everything flows through Orientation.
Decide — Select a course of action.
Act — Execute. Then observe the result. The loop tightens.
Boyd’s core thesis: the side that cycles through OODA faster — and orients more accurately — wins. Not the side with more data. Not the side with more firepower. The side that understands faster and acts on that understanding before the opponent can react.
Why Orientation is everything
Boyd placed disproportionate weight on Orientation. Two pilots can observe the same radar blip. One sees a threat. The other sees a decoy. The difference is not in the observation. It is in the orientation — the accumulated context, pattern recognition, and prior experience that shapes interpretation.
The Spine IS the Orientation engine. Without the Spine, every observation is raw data. With the Spine, every observation is understood in context. This is why IntegrateWise exists — the platform does not automate decisions; it makes orientation so fast and so rich that the decision becomes obvious.
IntegrateWise as the extended OODA loop
┌─────────────────────────────────────────────────────────────────┐
│ │
│ INTEGRATEWISE │
│ Extended OODA Loop │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ OBSERVE │───▶│ ORIENT │───▶│ PROPOSE │───▶│ GOVERN │ │
│ │ │ │ │ │ │ │ │ │
│ │Connectors│ │ Spine │ │ Twin │ │ L7 Gate │ │
│ │MCP Inbound│ │Entity360 │ │Confidence│ │ Approval │ │
│ │Webhooks │ │ Memory │ │ Evidence │ │ Token │ │
│ │Signals │ │ Context │ │ Action │ │ Audit │ │
│ └──────────┘ │Assembly │ └──────────┘ └────┬─────┘ │
│ ▲ └──────────┘ │ │
│ │ ▼ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ │ LEARN │◀───│ ORGANIZE │◀───│ EXECUTE │ │
│ │ │ │ │ │ │ │ │
│ │ │ Continuity│ │ Scoping │ │Integration│ │
│ │ │ Engine │ │ Classify │ │ Router │ │
│ │ │ Decay │ │ Relate │ │ Outbound │ │
│ └──────────│ Compound │ └──────────┘ │ Writeback│ │
│ └──────────┘ └──────────┘ │
│ │
│ Orientation is the center. The Spine makes it rich. │
│ Governance is the gate. No action without approval. │
│ Memory compounds. Each cycle makes the next faster. │
│ │
└─────────────────────────────────────────────────────────────────┘
Observe — Connectors and Signals
The Connectivity Platform receives data through the Integration Manager. Every signal is stamped with provenance. The connector does not reason — it only observes.
Orient — The Spine and Context Assembly
The Normalizer transforms raw data into canonical entities. The Spine binds them to stable IDs. Context Assembly builds the full picture. Capabilities are resolved here — the Twin determines which Platform Capabilities are needed based on the oriented context. The user never sees this resolution.
This is the step that matters most. Two platforms can observe the same Salesforce webhook. Only IntegrateWise can orient it against the full context of every prior interaction, every relationship, every learned pattern, every governance rule.
Propose — The Twin
The Twin reads the oriented context — Entity360, timeline, memory, signals — and proposes an action. Not a raw output. A structured proposal with evidence, confidence, and a recommended course.
Govern — The Gate
≥ 0.85 confidence: Auto-approve. Execute. Audit.
0.70–0.85: Surface on My Desk. Human reviews.
< 0.70: Discard. Log for learning.
This is IntegrateWise’s extension to OODA. Boyd assumed the decision-maker was also the actor. IntegrateWise assumes the AI proposes and the human governs. The gate is non-negotiable.
Execute — The Integration Router
An approved action routes through the South Plane to the target tool. Entity360 context is injected before the call. No action touches the outside world without an approval token.
Writeback, Remember, Organize, Learn — The Extensions
These steps do not exist in Boyd’s original OODA. They are IntegrateWise’s critical addition.
Every outcome writes back to the Spine. The Continuity Engine extracts knowledge with confidence scores. Memory is classified into scopes (Personal, Work, Organization, AI). Relationships are updated. The next Orientation is richer. The loop tightens. The platform gets smarter the longer you use it — not because the model changes, but because the orientation improves.
OODA depth over time
ACTIVATION OPERATIONAL
(first session) (every session)
Observe: First connector data Observe: Continuous stream from all connectors
Orient: Bootstrap context Orient: Full Spine + Memory + Relationships
Decide: First Twin insight Decide: Deep proposals with evidence chains
Govern: User reviews first proposal Govern: Confidence-gated approval at scale
Act: First action executes Act: Thousands of actions over time
Learn: First writeback Learn: Memory compounds indefinitely
CONTEXT DEPTH:
█░░░░░░░░░░░░░░░░░░░░ → ████████████████████████
(30 days, one tool) (years, every tool, every user)
Competitive frame through OODA
IntegrateWise is the only platform that runs the complete extended OODA loop across every tool, every AI, and every person in the organization.
Part IX — Go to Market
Distribution — AI-assistant-first
IntegrateWise ships as an MCP app listed in the marketplaces of the AI assistants people already use. ChatGPT’s app store. Claude’s connector directory. Perplexity. Users discover and add it from inside the assistant they already work with.
The primary ingress channel is the primary distribution channel. List once as an MCP app. That listing is both how users find IntegrateWise and how their assistant reaches the Spine.
The user lifecycle
DISCOVER → ACTIVATE → CONTINUE → GROW
Three sales motions
Direct — Individuals and small teams
Land on the native web experience. Establish your workspace. Connect your tools. Start working. The Twin begins reasoning from day one.
Embedded — Enterprise with existing portals
You already have an internal dashboard. IntegrateWise deploys into your environment. Your users authenticate through your existing identity provider. The Business Platforms run invisibly under your brand. Their surface, our brain.
Platform — Channel and white-label
You are a dev platform, an IDE, or a low-code environment. IntegrateWise becomes the intelligence and memory layer inside your product. Your users get governed AI and persistent context without knowing IntegrateWise exists.
Customer Zero — the proof
The first real deployment runs on two connectors: Salesforce + Slack. Read-only. Approval-required. 90-day retention.
One workspace authentication. The CS experience shows cross-system account context in under 60 seconds. The Twin proposes at least one insight per day. The VP of Customer Success answers “what is our risk?” without opening Salesforce or Slack.
Adding a third tool is an enable toggle, not a project.
Part X — What Makes This Defensible
The moat is memory gravity
The defensibility is not in connector breadth. That is commoditized. The defensibility is not in the AI model. That is rented and replaceable. The defensibility is not in the experience layer. That is replaceable by design.
The moat is memory gravity.
The more context you store in the Spine, the more valuable the platform becomes to you, and the higher the cost of leaving. Every entity, every relationship, every timeline entry, every learned pattern — all of it makes every future decision better. That compounds. It does not transfer.
When you connect your first tool, the Spine starts building context. When you connect your fifth tool, the context from the first four makes the fifth more valuable. When the Twin has 90 days of reasoning history, switching to a different system means starting from zero. Not because you are locked in by contract — but because your context lives here.
Truth you own, that compounds in place, that makes every tool and every AI better — that is the moat.
The seven agnostic dimensions
Competitors lock you into their runtime, their model, their experience. IntegrateWise locks you into nothing — except the context you have built. And that context is yours.
What is replaceable and what is not
Everything outside the Business Platforms is replaceable. Everything inside the Business Platforms is versioned and contract-driven.
Part XI — The Positioning
Tagline hierarchy
Competitive frame
They connect apps. IntegrateWise connects context.
Anti-positioning
IntegrateWise is not:
“AI-powered platform” — AI is rented, not the product
“No-code automation” — the platform is capability-driven, not workflow-driven
“Replace your tools” — tools stay; the platform connects them
“Chat with your data” — the Twin proposes and governs; it does not just answer
The correct frame: Human workbench. Assistive AI. Governed context.
Part XII — How the Company Runs
The principle
IntegrateWise preaches no lock-in, swappable implementations, and context that stays with you. The company’s own operational stack follows the same philosophy.
Every tool the company uses is a replaceable implementation behind a stable business function. The company runs on the same principle as the product.
The company stack by function
Product and infrastructure
Build and ship
Understand and learn
Communicate and sell
Company operations
The operational replacement table
Part XIII — The Close
What exists today
The Spine architecture and normalization pipeline
The Twin reasoning engine with confidence-gated governance
The MCP surface for AI-assistant-first ingress
Descope as the canonical authorization authority for outbound connections (Nango retained as dormant compatibility)
The multi-experience architecture (web, embedded, platform)
The identity projection system (12 departments, 6+ industries, 4 role buckets)
The Discovery contract and capability registry
Native deployment on Cloudflare, with Vercel and Replit as first-class deployment profiles
Customer Zero proof framework (Salesforce + Slack, CS experience)
Launch narrative (frozen)
Campaign thesis: Your Last Auth. Total Continuity.
Product mechanism: One Click to Total Ecosystem.
Category: Operational Continuity Infrastructure (not "Operating System for Enterprise Context").
Core enemy: Starting from zero — AUTH AGAIN · CONNECT AGAIN · EXPLAIN AGAIN · SEARCH AGAIN · RECONSTRUCT AGAIN · START AGAIN. Not Salesforce, not Slack, not integrations, not stateless AI.
Core problem: The Empty Context Tax.
Product promise: The next piece of work starts where the last one ended.
AI difference: Your AI starts in context.
Governance law: Twin prepares. Human approves.
Ownership doctrine: Truth you own. AI you rent. Approval in between.
Primary CTA: Connect Your Ecosystem.
IntegrateWise is the continuity layer between your tools, your people, and the AI working with them.
Launch film spine: "The Last Auth" → AUTHORIZE → CONNECT → RETAIN → CONTINUE → ACT → REMEMBER ↺.
What is coming
MCP marketplace listings (ChatGPT, Claude, Perplexity)
Native Deployment Profiles for Vercel and Replit
Schema AI for arbitrary payload mapping
Agent-to-agent orchestration through the Spine
Platform partner SDK for white-label deployment
Additional solution verticals beyond Customer Zero
The one-sentence story
IntegrateWise is the memory and context layer that sits beneath all your tools and all your AI providers — so you brief it once, it remembers everything, and every platform you use gets the same truth without you having to repeat yourself.
The thirty-second pitch
Every knowledge worker spends their day copying context between tools, re-briefing AI assistants, and doing the work that software should be doing for them. IntegrateWise is the Operational Continuity Platform that sits beneath all your tools and all your AI providers, carrying context forward so nothing is forgotten. You own the data. You rent the AI. Every action passes through your approval. One workbench. Full continuity. Zero context loss.
The founder’s conviction
The battle is not Human vs. AI. It is not about which provider wins or which model is best. It is about building the right relationship between humans and AI — one where the human has a surface for their work, the AI has a home where it lives as a governed digital twin, and both share one memory layer controlled by the human.
Everything must be grounded in human behaviour and goals, not pulled to AI’s ways. If there is a battle for Human over AI, that can never be Human alone or AI alone. It must be Human and AI over one shared memory and intelligence layer — where Humans have their own surface for their work and AI has its own home where it lives the life of a digital twin, governed by human.
The ask
IntegrateWise is building the missing layer between tools and AI. The category is operational continuity. The product is real. The architecture is proven. The doctrine is locked.
Everything outside the Business Platforms is replaceable. Everything inside the Business Platforms is versioned and contract-driven.
OODA wins dogfights. IntegrateWise runs OODA for your entire business — with the Spine as orientation, the Twin as proposal, the Gate as governance, and memory that makes every cycle faster than the last.
Truth you own. AI you rent. Approval in between.
Build capabilities once. Experience them anywhere. Deploy them anywhere.
One workbench. Full continuity. Zero context loss.
That is IntegrateWise.
IntegrateWise — The Operational Continuity Platform
Build capabilities once. Experience them anywhere. Deploy them anywhere.
Nothing important is forgotten.
This fills a gap that has been implicit since the first version of the architecture but never given a name. Every platform needs one place where routing, configuration, and provider selection live. Without it, those decisions scatter across services, get hardcoded in environment variables, or live in someone’s head. None of those survive scale.
The Integration Hub
What it is
The Integration Hub is the Business Platform that owns all routing decisions, configuration state, and provider selection across IntegrateWise. It is the single place where the platform’s behaviour is defined — not through code, but through configuration.
Experiences
│
▼
Capability Fabric
┌──────────┼──────────┐
▼ ▼ ▼
Continuity Intelligence Governance
│ │ │
└─── Integration Manager ───┘
│
Connectivity
│
Identity
│
Integration Hub ← THE ROUTING & CONFIG BRAIN
The Integration Hub sits beneath all other Business Platforms. It does not own data (that is the Continuity Platform). It does not own identity (that is the Identity Platform). It does not own capabilities (that is the Capability Fabric). It owns how the platform routes, which providers it uses, and what configuration governs each decision.
Why it is needed
Without the Integration Hub, configuration lives in fragments:
Every one of these decisions should be made once, in one place, and observed by every service that needs them. That place is the Integration Hub.
What it governs
The Integration Hub owns five categories of configuration:
- Provider Routing
Example: A low-cost tenant routes triage through Workers AI (cheap, fast) and proposals through GPT-5-mini via OpenRouter (accurate, moderate cost). A premium tenant routes everything through Claude (highest quality). The Hub defines these rules. The services execute them. - Connector Configuration
- Feature Flags and Tiers
- Credential Vault Interface
- Routing Rules and Policies
Where it sits in the architecture
The Integration Hub is a Business Platform — stable, versioned, contract-driven. It does not change freely. Its routing rules and configuration schemas are part of the platform contract.
But it also touches the Execution Platforms — because it selects which execution platform handles which task. That is its purpose: it is the bridge between the stable business layer and the replaceable execution layer.
BUSINESS PLATFORMS INTEGRATION HUB EXECUTION PLATFORMS
─────────────────── ──────────────── ────────────────────
Identity Routes identity Intelligence (which model?)
Connectivity Routes connectors Runtime (which compute?)
Integration Manager Routes integrations Storage (which store?)
Continuity Routes memory Search (which engine?)
Capability Fabric Routes capabilities Messaging (which queue?)
Governance Routes approvals Deployment (which profile?)
Observability (which tool?)
The Integration Hub is the routing brain that connects the stable business layer to the replaceable execution layer. Every Business Platform reads its routing decisions from the Hub. Every Execution Platform is selected by the Hub.
The Hub as a dashboard
The Integration Hub is also the operator’s configuration surface — the place where platform administrators manage the platform’s behaviour without changing code.
┌─────────────────────────────────────────────────────────────┐
│ │
│ INTEGRATION HUB │
│ Configuration Dashboard │
│ │
├─────────────────────────────────────────────────────────────┤
│ │
│ PROVIDER ROUTING │
│ ├─ AI Models gpt-5-mini (default) · Claude · Grok │
│ ├─ Storage D1 (primary) · Postgres (enterprise) │
│ ├─ Search Vectorize (default) · Pinecone │
│ └─ Queues CF Queues (default) · Redis Streams │
│ │
│ CONNECTOR CONFIGURATION │
│ ├─ Salesforce Active · Full Sync · 30min frequency │
│ ├─ Slack Active · Real-time · Webhook │
│ ├─ HubSpot Inactive · Not connected │
│ └─ GitHub Active · Incremental · 15min │
│ │
│ FEATURE FLAGS │
│ ├─ Schema AI Enabled (beta) │
│ ├─ A2A Orchestration Disabled (Month 6) │
│ ├─ Twin Voice Enabled │
│ └─ Auto-approve ≥ 0.85 confidence │
│ │
│ CREDENTIALS │
│ ├─ Nango Wall 4 active connections │
│ ├─ MCP Keys 2 active keys │
│ └─ API Keys 3 active (1 expiring soon) │
│ │
│ ROUTING RULES │
│ ├─ Fallback chain OpenRouter → Workers AI → local │
│ ├─ Cost limit $50/tenant/month (default) │
│ ├─ Priority Governance > Twin > Triage > Bulk │
│ └─ Surface access Web: Full · Slack: Approve+Notify │
│ │
│ DEPLOYMENT PROFILE │
│ ├─ Current Cloudflare Native │
│ ├─ Available Vercel · Replit · Docker │
│ └─ Override None │
│ │
└─────────────────────────────────────────────────────────────┘
This dashboard is the operator’s view. It is not the user’s view. The user sees the Human Worksurface and the Governance Gate. The operator sees the Integration Hub — the control plane for the platform itself.
How it differs from Integration Manager
This is a naming question that must be answered cleanly, because “Integration Hub” and “Integration Manager” sound similar.
The Integration Manager is the hands — it touches external tools.
The Integration Hub is the brain — it decides how everything routes.
They are complementary. The Integration Manager reads routing decisions from the Integration Hub. The Integration Hub does not touch external tools itself.
Updated Business Platforms table
Seven Business Platforms. The Integration Hub is the seventh. It does not replace any of the other six. It governs how they route to the Execution Platforms beneath them.
The updated hierarchy
VISION
Operational Continuity
│
▼
PRODUCT
IntegrateWise
│
▼
SOLUTIONS
Sales · CS · Ops · Executive · Knowledge
│
▼
EXPERIENCES
Web · Desktop · Mobile · CLI · Slack · Teams · Partner · Embedded
│
▼
BUSINESS PLATFORMS (7)
Identity · Connectivity · Integration Manager · Integration Hub
Continuity · Capability Fabric · Governance
│
▼
EXECUTION PLATFORMS
Intelligence · Runtime · Storage · Search · Messaging · Deployment · Observability
│
▼
DEPLOYMENT PROFILES
Cloudflare Native · Vercel Native · Replit Native · Docker Native
Kubernetes Native · AWS Native · Azure Native
│
▼
TECHNOLOGY
Workers · D1 · Postgres · Redis · S3 · Queues · Vector DBs · etc.
How the Hub enables the agnostic doctrine
The Integration Hub is the mechanism that makes every agnosticism claim real.
Without the Hub, “agnostic” is a philosophy. With the Hub, “agnostic” is a configuration.
One line
The Integration Hub is the platform’s control tower — it routes every decision, configures every provider, manages every credential, and governs every feature flag. Without it, agnosticism is a claim. With it, agnosticism is a setting.
Where this goes in the v2 doctrine
Add the Integration Hub to the Business Platforms list in Part V of the final writeup. Add a new section between the current Deployment Profiles section and the Two Doors, One Spine section: “The Integration Hub — Routing and Configuration Backbone.” Include the Hub dashboard, the five configuration categories, and the table distinguishing it from Integration Manager. Update the hierarchy diagram to show seven Business Platforms instead of six.
This completes the Business Platform layer. Seven platforms, each with a distinct responsibility, none overlapping:
Seven words. Seven platforms. The full Business Platform layer.
The Complete System Definition
The Product in One Line
One click to make tools and AI work for humans.
That is it. Everything behind that click is architecture. The user never sees the architecture. They see a workspace where their tools are connected, their data is unified, and their AI already knows what to do.
The Flow — In Plain Language
STEP 1: CONNECT
→ User gives one Auth
→ Tools connect (API, Connector, MCP, LLM Call)
→ Integration Manager handles everything
STEP 2: HYDRATE
→ Data flows into the Spine
→ Entities resolved
→ SSOT built
→ Workbench ready
STEP 3: WORK
→ User works on unified data
→ One workbench. All tools. One truth.
→ No tab switching. No context loss.
STEP 4: AI BECOMES PROACTIVE
→ Twin watches the same SSOT
→ Knows context always
→ Proposes actions before the user asks
→ Helps with daily tasks
STEP 5: MEMORY
→ Human needs knowledge to work
→ AI needs knowledge to operate
→ Both live on the Spine
→ Memory compounds every day
STEP 6: REPEAT
→ Every day the system is smarter
→ Every day the AI knows more
→ Every day the user works faster
The Spine — What It Actually Contains
The Spine is not just a database. It is the living memory of the organization. It holds three fundamentally different types of data.
THE SPINE
┌─────────────────────────────────────────────────────┐
│ │
│ LAYER 1: SIMPLE DATA (Structured) │
│ ───────────────────────────────── │
│ Fields. Numbers. Dates. Statuses. │
│ │
│ Account name: "Acme Corp" │
│ ARR: $1.2M │
│ Health Score: 62 │
│ Deal Stage: Negotiation │
│ Task Status: In Progress │
│ Contact Email: sarah@acme.com │
│ Sprint Velocity: 23 points │
│ │
│ This is the data that tools already produce. │
│ It flows in through Integration Manager. │
│ It lives in structured schemas. │
│ Postgres. KV. Standard storage. │
│ │
├─────────────────────────────────────────────────────┤
│ │
│ LAYER 2: RICH DATA (Unstructured) │
│ ───────────────────────────────── │
│ Files. Images. Documents. Attachments. │
│ Conversations. Emails. Meeting recordings. │
│ │
│ Contract PDF for Acme Corp │
│ Slack thread with 47 messages │
│ Design file for product launch │
│ Meeting recording from QBR │
│ Email chain with legal team │
│ Invoice document │
│ Screenshot from customer │
│ │
│ This is large. This is unstructured. │
│ It lives in R2 (object storage). │
│ It is indexed for search. │
│ It is referenced by entities. │
│ │
├─────────────────────────────────────────────────────┤
│ │
│ LAYER 3: KNOWLEDGE (Human + AI) │
│ ───────────────────────────────── │
│ This is where it gets critical. │
│ │
│ HUMAN KNOWLEDGE: │
│ → Notes the user writes │
│ → Decisions they document │
│ → Playbooks they follow │
│ → Runbooks for incidents │
│ → Meeting notes │
│ → Strategic documents │
│ → Tribal knowledge ("Acme's CEO hates emails, │
│ always call") │
│ │
│ AI KNOWLEDGE: │
│ → Patterns the AI has learned │
│ → Behavioral models of users │
│ → Organizational patterns │
│ → Predictions and their outcomes │
│ → What worked and what didn't │
│ → Confidence scores for its own models │
│ → "David approves escalations 90% of the time" │
│ │
│ MEMORY TRIAGE: │
│ → Not all knowledge is permanent │
│ → The Spine must decide what lives, what ages, │
│ and what is discarded │
│ │
└─────────────────────────────────────────────────────┘
Memory Triage — The Critical Intelligence
This is the piece that determines organizational continuity. Without triage, the Spine becomes a dump. With triage, it becomes wisdom.
MEMORY TRIAGE
Every piece of knowledge enters the Spine with a LIFECYCLE.
STAGE 1: HOT MEMORY (0-7 days)
→ Recent events, active context
→ Lives in fast storage (Postgres / KV)
→ Available instantly to every workbench and Twin
→ Example: "Sarah reviewed Acme Corp today at 9:14 AM"
→ Example: "Bug #8821 resolved 2 hours ago"
STAGE 2: WARM MEMORY (7-30 days)
→ Still relevant, accessed occasionally
→ Migrated to indexed storage
→ Available on query, not pre-loaded
→ Example: "Acme Corp health has dropped 3 times this month"
→ Example: "David approved 14 of 16 proposals in the last 2 weeks"
STAGE 3: COLD MEMORY (30-90 days)
→ Historical reference
→ Lives in R2 (object storage)
→ Indexed for search and pattern analysis
→ Example: "Q1 churn pattern: accounts with health < 60
at renewal had 73% churn rate"
→ Example: "Sarah's Q1 close rate was 34%"
STAGE 4: PERMANENT MEMORY (90+ days → forever)
→ Crystallized organizational knowledge
→ Patterns that have proven true over time
→ Behavioral models that are stable
→ Decisions that define how the org operates
→ Example: "Enterprise accounts always get auto-escalation"
→ Example: "Customer health correlates with bug resolution time"
→ Example: "Executive QBRs happen quarterly, always with
health and pipeline data"
STAGE 5: DISCARDED
→ Temporary noise
→ One-off events that don't repeat
→ Outdated information superseded by new data
→ Example: "Slack message 'lunch at noon?' — no business value"
→ Example: "Draft email never sent — superseded by final version"
THE TRIAGE RULES:
→ Repeated patterns STRENGTHEN (move toward permanent)
→ One-off events DECAY (move toward discarded)
→ User-confirmed knowledge ELEVATES (instantly becomes trusted)
→ AI-observed patterns must PROVE themselves over time
→ Organizational decisions are PERMANENT by default
→ Personal preferences decay when the person changes roles
THE TRIAGE PIPELINE:
New knowledge enters
│
▼
Is this a user-created decision or document?
│
├── Yes → Permanent Memory (organizational record)
│
▼
Is this an AI-observed pattern?
│
├── Yes → Hot Memory (needs to prove itself)
│ After 7 repetitions → Warm
│ After 30 repetitions → Cold/Indexed
│ After 90 repetitions with accuracy → Permanent
│
▼
Is this a one-off event?
│
├── Yes → Hot Memory (7 days)
│ No repetition → Decay → Discard
│ Repeated → Escalate to Warm
│
▼
Is this external data (from tools)?
│
├── Yes → Follow retention policy
│ 90 days Slack → Archive to R2
│ Indefinite CRM → Keep in Spine
│ Per governance settings
│
▼
Memory Triage Worker runs every night
Decides what stays. What moves. What dies.
The Agnostic Layers
The system must be agnostic at every level. No dependency on any specific tool, model, frontend, or deployment.
AGNOSTIC LAYERS
┌─────────────────────────────────────────────────────┐
│ INTEGRATION AGNOSTIC │
│ ───────────────────── │
│ The system does not care what tools connect. │
│ │
│ Salesforce? → Nango Adapter │
│ HubSpot? → Nango Adapter │
│ Jira? → Native Adapter │
│ Custom API? → MCP Adapter │
│ Database? → Direct Connector │
│ LLM API? → LLM Call Adapter │
│ │
│ The Spine doesn't know the source. │
│ It only knows canonical data. │
│ │
├─────────────────────────────────────────────────────┤
│ AI MODEL AGNOSTIC │
│ ───────────────────── │
│ The system does not care which AI model runs. │
│ │
│ Claude? → Works │
│ GPT? → Works │
│ Gemini? → Works │
│ Kimi? → Works │
│ DeepSeek? → Works │
│ Local model? → Works │
│ Future model? → Works │
│ │
│ Context stays in the Spine. │
│ Model swaps underneath. │
│ The Twin's intelligence is model-independent. │
│ │
├─────────────────────────────────────────────────────┤
│ FRONTEND AGNOSTIC │
│ ───────────────────── │
│ The system does not care what renders it. │
│ │
│ Web browser? → Works │
│ Mobile app? → Works │
│ CLI? → Works │
│ Slack? → Works │
│ Teams? → Works │
│ VS Code? → Works │
│ ChatGPT? → Works │
│ Embedded widget? → Works │
│ Partner portal? → Works │
│ │
│ All are projections of the same Spine. │
│ │
├─────────────────────────────────────────────────────┤
│ DEPLOYMENT AGNOSTIC │
│ ───────────────────── │
│ The system does not care where it runs. │
│ │
│ Vercel? → Works │
│ Cloudflare Workers? → Works │
│ Docker? → Works │
│ Kubernetes? → Works │
│ On-premise? → Works │
│ Replit? → Works │
│ │
│ The application doesn't know where it runs. │
│ The platform doesn't know where it runs. │
│ Only the deployment adapter knows. │
│ │
├─────────────────────────────────────────────────────┤
│ STORAGE AGNOSTIC │
│ ───────────────────── │
│ The system does not depend on one storage type. │
│ │
│ Postgres? → Structured data │
│ KV (Redis/Workers KV)? → Hot cache, sessions │
│ R2? → Files, documents, cold memory │
│ Vector DB? → Semantic search, embeddings │
│ Queues? → Event processing, pipeline stages │
│ Logs? → Audit, observability │
│ │
│ The Spine orchestrates across all of them. │
│ │
└─────────────────────────────────────────────────────┘
Integration Manager — Full Detail
INTEGRATION MANAGER
What it IS:
→ The stateless plumbing between external tools and the Spine
→ It does not store business logic
→ It does not make decisions
→ It connects apps to truth
What it OWNS:
→ Discovery: What tools exist in the marketplace
→ Connection: OAuth, API keys, tokens
→ Consent: What data the user allows access to
→ Capability Discovery: What can this tool do?
→ Provider Registry: What adapters are available?
→ Sync: Pulling and pushing data
→ Webhooks: Real-time event streams
→ MCP: Model Context Protocol for AI-native tools
→ Health: Is the connection alive?
→ Lifecycle: Connect, sync, pause, disconnect
ADAPTER TYPES:
┌─────────────────────────────────────────────┐
│ Nango Adapter │
│ → For tools with OAuth (Salesforce, HubSpot,│
│ Slack, Google, Microsoft) │
│ → Managed OAuth flows │
│ → Token refresh │
│ → Standard API polling │
├─────────────────────────────────────────────┤
│ Native Adapter │
│ → For tools we built custom integrations for│
│ → Jira, GitHub, Linear, Notion │
│ → Deep schema mapping │
│ → Webhook-native │
├─────────────────────────────────────────────┤
│ MCP Adapter │
│ → For AI-native tool connections │
│ → Model Context Protocol │
│ → Tool exposes capabilities to AI directly │
│ → Used when AI needs to call tool functions │
├─────────────────────────────────────────────┤
│ Direct API Connector │
│ → For custom / internal APIs │
│ → User provides endpoint + auth │
│ → Schema mapping configured manually │
├─────────────────────────────────────────────┤
│ LLM Call Adapter │
│ → For AI-to-AI communication │
│ → One AI system calling another │
│ → Example: IntegrateWise Twin calling │
│ a specialized coding agent │
│ → Structured prompt + response pipeline │
└─────────────────────────────────────────────┘
THE CONNECTION FLOW:
User clicks "Connect Salesforce"
│
▼
Integration Manager receives request
│
▼
Selects adapter: Nango Adapter for Salesforce
│
▼
Initiates OAuth flow
│
▼
User authorizes in Salesforce
│
▼
Token received and stored securely
│
▼
Capability Discovery runs:
→ "Salesforce exposes: Accounts, Contacts,
Cases, Opportunities, Tasks, Custom Objects"
→ Schema introspection
→ Field mapping to canonical models
│
▼
Capability Registry updated:
→ "This workspace now has Salesforce capabilities"
→ Available to Spine, Workbench, and Twin
│
▼
Initial sync begins:
→ Bulk pull of historical data
→ Pushed to Spine ingestion queue
│
▼
Webhook subscription:
→ Real-time events now stream
→ Salesforce → Integration Manager → Spine
│
▼
Connection live.
Health monitoring begins.
Capability Fabric
This is the layer that sits between connected tools and the rest of the system. It answers the question: “What can this workspace do right now?”
CAPABILITY FABRIC
The Capability Fabric is a living registry of everything
the workspace can do, based on what tools are connected,
what domain packs are active, and what permissions exist.
┌─────────────────────────────────────────────────────┐
│ CAPABILITY SOURCES │
│ │
│ From Connected Tools: │
│ Salesforce → Account CRUD, Contact CRUD, │
│ Case Management, Pipeline Tracking │
│ Slack → Channel Read, Message Read, Send Message, │
│ Thread Read │
│ Jira → Issue CRUD, Sprint Management, Board View │
│ HubSpot → Deal CRUD, Contact Sync, Workflow Trigger│
│ Calendar → Event Read, Create Event, Attendee Mgmt │
│ │
│ From Domain Packs: │
│ Customer Success → Health Scoring, Renewal Tracking,│
│ Escalation Routing │
│ Sales → Pipeline Management, Forecast, Lead Scoring│
│ Engineering → Sprint Board, PR Tracking, Standup │
│ Finance → Invoice Tracking, Revenue Recognition │
│ Executive → KPI Dashboard, Portfolio View, Risk Map │
│ │
│ From Shared Features: │
│ Timeline, Search, Entity360, Notifications, │
│ Approvals, Knowledge, Activity Feed │
│ │
│ From Platform: │
│ Identity, Governance, Memory, Twin Intelligence │
│ │
└─────────────────────────────────────────────────────┘
HOW IT WORKS:
- Admin connects Salesforce
→ Capability Discovery runs
→ "Salesforce Account CRUD" registered - Admin enables Customer Success domain pack
→ "Health Scoring" capability registered
→ "Renewal Tracking" capability registered - The Fabric now knows:
→ This workspace CAN create/update accounts (from Salesforce)
→ This workspace CAN score account health (from CS pack)
→ This workspace CAN track renewals (from CS pack + Salesforce) - Any workbench or Twin can query the Fabric:
→ "What capabilities do I have for Acme Corp?"
→ Fabric returns: Account CRUD, Health Scoring,
Case Management, Slack Messaging, Calendar Scheduling - The Twin uses the Fabric to know what actions it CAN propose:
→ "I can escalate a case (Jira + Governance)"
→ "I can send a Slack message (Slack adapter)"
→ "I can create a calendar event (Calendar adapter)"
→ "I CANNOT update the billing system (not connected)"
GTM Motion — The Full Journey
THE USER'S GTM JOURNEY
STAGE 1: DISCOVERY
│
│ User finds IntegrateWise through:
│ → Connector Marketplace (searching for a Slack integration)
│ → Google search ("unified workspace for sales teams")
│ → AI Marketplace (browsing AI-powered tools)
│ → Referral from another user
│ → Content / blog / social
│
▼
STAGE 2: SIGNUP
│
│ User signs up:
│ → From Marketplace: "Install" → Redirected to signup
│ → From website: "Start Free" → Email + password
│ → From AI app: "Connect to IntegrateWise" → OAuth
│
│ Identity created.
│ Workspace provisioned.
│
▼
STAGE 3: IDENTITY + AUTH
│
│ Single EcosystemConnection established (L0)
│ One trust boundary for the entire workspace
│
│ Auth methods:
│ → Direct OAuth (user authorizes tools)
│ → API Key (for developer connections)
│ → MCP (for AI-native tool connections)
│ → LLM Call (for AI-to-AI communication)
│ → Direct connector (for custom integrations)
│
▼
STAGE 4: CONNECT
│
│ Connector Marketplace opens
│ User selects tools:
│ → "Connect Salesforce" → OAuth flow → Connected
│ → "Connect Slack" → OAuth flow → Connected
│ → "Connect Jira" → OAuth flow → Connected
│
│ Or via MCP:
│ → "Connect to this AI coding assistant" → MCP handshake
│
│ Or via LLM Call:
│ → "Use GPT-4 for document analysis" → API key → Active
│
▼
STAGE 5: SPINE HYDRATION
│
│ Instant Hydration (60 seconds):
│ → Basic entity count
│ → "847 accounts, 12,000 contacts found"
│ → Enough to show value immediately
│
│ Operational Hydration (5-15 minutes):
│ → Full entity resolution
│ → Relationship mapping
│ → Timeline population
│ → Search indexing
│ → Workbench ready for daily use
│
│ Continuous Hydration (ongoing):
│ → Real-time sync
│ → Memory building
│ → Pattern detection
│ → AI learning begins
│
▼
STAGE 6: TWIN ACTIVATION
│
│ The Twin wakes up for the first time:
│ → Reviews the hydrated Spine
│ → Identifies: "Here are the key items for today"
│ → Surfaces in the workbench:
│
│ "Welcome to your workspace. Here's what I found:
│ → 3 accounts need attention (health declining)
│ → 2 deals at risk (stalled for 20+ days)
│ → 5 tasks overdue across your team
│ → 1 renewal this week
│
│ [View Details] [Configure Notifications]"
│
▼
STAGE 7: DAILY USE
│
│ User works. System works. AI learns.
│ Every day the same lifecycle.
│ Every day the system is smarter.
│
▼
STAGE 8: EXPANSION
│
│ User adds more tools
│ User invites more team members
│ User enables more domain packs
│ User upgrades tier
│ The platform grows with them
OODA for Connected Tools
The AI does not just learn from user behavior and organizational data. It also learns from the tools themselves.
OODA FOR CONNECTED TOOLS
The system doesn't just connect tools and forget.
The AI must understand each tool deeply.
OBSERVE:
→ What tools are connected?
→ What data does each tool produce?
→ What actions does each tool support?
→ How frequently does data change?
→ What is the tool's data quality?
→ What patterns exist in the tool's data?
ORIENT:
→ "Salesforce updates accounts 47 times/day on average"
→ "Slack produces 340 messages/day across 12 channels"
→ "Jira has 23 active issues, 4 blocked"
→ "HubSpot deal stages change every 3.2 days on average"
→ "Calendar has 14 meetings/week for this team"
→ "The tool has a memory: Salesforce knows 3 years
of customer history"
DECIDE:
→ "This tool's data is high-signal for health scoring"
→ "This tool's data is noise for executive reporting"
→ "This tool needs real-time sync (Slack) vs
daily batch (Calendar)"
→ "This tool's historical data should be fully
extracted for memory building"
ACT:
→ Adjust sync frequency per tool
→ Prioritize extraction of high-value data
→ Build tool-specific knowledge models
→ Recommend tool-specific workbench views
LEARN:
→ "Over 30 days, Salesforce data predicts churn
better than HubSpot data for this workspace"
→ "Slack escalation messages have 89% correlation
with health drops"
→ "Jira bug resolution time directly predicts
customer satisfaction"
→ "The memory of each tool is different.
Respect each tool's history."
Continuity Pipelines and Workers
This is the processing engine that runs underneath everything. These are the actual compute units that do the work.
CONTINUITY PIPELINES
A pipeline is a sequence of processing stages.
Each stage does one job.
Data flows from stage to stage.
Workers execute each stage.
THE MAIN PIPELINES:
┌─────────────────────────────────────────────────────┐
│ PIPELINE 1: INGESTION PIPELINE │
│ ────────────────────────────── │
│ │
│ Worker: Ingestion Worker │
│ Trigger: Webhook received / Poll timer fired │
│ │
│ Stage 1: RECEIVE │
│ → Worker receives raw payload from Integration Mgr │
│ → Validates payload format │
│ → Assigns event ID │
│ │
│ Stage 2: QUEUE │
│ → Pushes to processing queue │
│ → Ensures ordering per entity │
│ → Handles backpressure │
│ │
│ Worker runs on Cloudflare Queues or equivalent │
│ Scales automatically based on event volume │
│ │
├─────────────────────────────────────────────────────┤
│ PIPELINE 2: NORMALIZATION PIPELINE │
│ ────────────────────────────────── │
│ │
│ Worker: Normalization Worker │
│ Trigger: Event in processing queue │
│ │
│ Stage 1: PARSE │
│ → Read raw payload │
│ → Identify source system (Salesforce, Slack, etc) │
│ → Map to canonical schema │
│ │
│ Stage 2: TRANSFORM │
│ → Salesforce Account → Canonical Organization │
│ → Slack Message → Canonical Conversation │
│ → Jira Issue → Canonical Task │
│ → Field mapping, type conversion, validation │
│ │
│ Stage 3: VALIDATE │
│ → Schema validation │
│ → Data quality check │
│ → Reject malformed events │
│ │
│ Output: Canonical event ready for resolution │
│ │
├─────────────────────────────────────────────────────┤
│ PIPELINE 3: RESOLUTION PIPELINE │
│ ────────────────────────────── │
│ │
│ Worker: Resolution Worker │
│ Trigger: Canonical event from normalization │
│ │
│ Stage 1: ENTITY RESOLUTION │
│ → "Acme Corp" (Salesforce) = "Acme Corporation" │
│ (HubSpot) = "#acme-cs" (Slack) │
│ → Match, merge, or create entities │
│ → Confidence scoring on matches │
│ │
│ Stage 2: RELATIONSHIP RESOLUTION │
│ → Entity → has → contacts │
│ → Entity → has → deals │
│ → Entity → has → cases │
│ → Entity → related_to → other entities │
│ → Bidirectional relationship graph maintained │
│ │
│ Stage 3: SPINE WRITE │
│ → Write resolved entity to Spine │
│ → Update Entity360 │
│ → Update relationship graph │
│ → Update search index │
│ │
│ Output: Updated Spine with resolved entities │
│ │
├─────────────────────────────────────────────────────┤
│ PIPELINE 4: TIMELINE PIPELINE │
│ ────────────────────────────── │
│ │
│ Worker: Timeline Worker │
│ Trigger: Entity update in Spine │
│ │
│ Stage 1: EVENT RECORD │
│ → Create timeline entry │
│ → Timestamp, entity, action, source │
│ → Link to source event │
│ │
│ Stage 2: SEQUENCE │
│ → Place in chronological order │
│ → Link related events (same entity, same session) │
│ → Detect event clusters │
│ │
│ Stage 3: INDEX │
│ → Add to search index │
│ → Add to entity timeline │
│ → Add to user activity feed │
│ │
│ Output: Searchable, chronological event history │
│ │
├─────────────────────────────────────────────────────┤
│ PIPELINE 5: KNOWLEDGE PIPELINE │
│ ────────────────────────────── │
│ │
│ Worker: Knowledge Worker │
│ Trigger: Unstructured data ingested │
│ │
│ Stage 1: CLASSIFY │
│ → Is this a document? Conversation? Email? │
│ → What entities does it reference? │
│ → What domain does it belong to? │
│ │
│ Stage 2: EXTRACT │
│ → Pull key information │
│ → Named entities, dates, amounts, decisions │
│ → Attachments, links, references │
│ │
│ Stage 3: EMBED │
│ → Generate vector embeddings │
│ → Store in vector DB for semantic search │
│ → Link to source entity │
│ │
│ Stage 4: CLASSIFY FOR TRIAGE │
│ → Hot memory? (recent, frequently accessed) │
│ → Warm memory? (older, occasionally accessed) │
│ → Cold memory? (historical, rarely accessed) │
│ → Permanent? (organizational decision / playbook) │
│ → Discard? (noise, no business value) │
│ │
│ Output: Classified, searchable, triaged knowledge │
│ │
├─────────────────────────────────────────────────────┤
│ PIPELINE 6: R2 TRIAGE PIPELINE │
│ ────────────────────────────── │
│ │
│ Worker: Triage Worker │
│ Trigger: Nightly batch / Memory age threshold │
│ │
│ Stage 1: SCAN │
│ → Review all Hot memory items │
│ → Check age, access frequency, relevance score │
│ │
│ Stage 2: DECIDE │
│ → Age > 7 days, accessed < 3 times → Move to Warm │
│ → Age > 30 days, accessed < 1 time → Move to Cold │
│ → Age > 90 days, no access → Archive or Discard │
│ → User-marked "important" → Permanent │
│ → AI pattern with > 90% accuracy → Permanent │
│ │
│ Stage 3: MOVE │
│ → Hot → Warm: Move from Postgres to indexed KV │
│ → Warm → Cold: Move from KV to R2 object storage │
│ → Cold → Archive: Compress and store in R2 │
│ → Discard: Remove from active storage │
│ → Permanent: Copy to permanent memory store │
│ │
│ Stage 4: UPDATE INDEX │
│ → Search index updated │
│ → Entity references updated │
│ → Memory graph updated │
│ │
│ Output: Optimized storage with clear memory tiers │
│ │
├─────────────────────────────────────────────────────┤
│ PIPELINE 7: PROJECTION PIPELINE │
│ ────────────────────────────── │
│ │
│ Worker: Projection Worker │
│ Trigger: User opens workbench / Spine update │
│ │
│ Stage 1: IDENTIFY │
│ → Who is the user? │
│ → What workbench are they opening? │
│ → What projection rules apply? │
│ │
│ Stage 2: QUERY │
│ → Pull relevant entities from Spine │
│ → Pull relevant timeline events │
│ → Pull relevant knowledge │
│ → Apply access control (Governance) │
│ │
│ Stage 3: ASSEMBLE │
│ → Apply projection rules │
│ → Arrange data into workbench format │
│ → Include shared features │
│ → Include domain-specific features │
│ → Include private features │
│ │
│ Stage 4: DELIVER │
│ → Send to frontend │
│ → Cache for performance │
│ → Subscribe for real-time updates │
│ │
│ Output: Ready-to-render workbench │
│ │
├─────────────────────────────────────────────────────┤
│ PIPELINE 8: CONTINUITY PIPELINE │
│ ────────────────────────────── │
│ │
│ Worker: Continuity Worker │
│ Trigger: Always running (streaming) │
│ │
│ This is the master orchestrator. │
│ It does not process data itself. │
│ It ensures all other pipelines are connected. │
│ │
│ Stage 1: MONITOR │
│ → Is Ingestion healthy? │
│ → Is Normalization keeping up? │
│ → Is Resolution running? │
│ → Is Timeline current? │
│ → Is Knowledge indexed? │
│ → Is Triage scheduled? │
│ → Is Projection responsive? │
│ │
│ Stage 2: ORCHESTRATE │
│ → Route events to the right pipeline │
│ → Handle pipeline failures │
│ → Retry on errors │
│ → Scale workers based on load │
│ │
│ Stage 3: GUARANTEE │
│ → No event is lost │
│ → No entity is unresolved │
│ → No timeline gap exists │
│ → Continuity is maintained │
│ │
│ Output: All pipelines running. Continuity intact. │
│ │
└─────────────────────────────────────────────────────┘
How Workers Carry User Work Every Day
Workers are not abstract. They are the daily labor force of the system. Every piece of work the user sees completed was done by a worker.
WHAT WORKERS DO EVERY DAY
MORNING (Before user arrives):
Sync Worker
→ Pulled 12,000 events overnight from all tools
→ Normalization Worker processed all 12,000
→ Resolution Worker resolved 847 entity updates
→ Timeline Worker recorded 4,200 timeline events
→ Knowledge Worker indexed 340 new documents/threads
→ Triage Worker archived 1,200 old memory items
→ Projection Worker pre-loaded all workbench contexts
DURING WORK (While user works):
Real-time Sync Worker
→ Processing 47 webhooks per minute
→ Every Slack message → Spine within 2 seconds
→ Every Salesforce update → Spine within 5 seconds
→ Every Jira transition → Spine within 3 seconds
Projection Worker
→ User clicks on "Acme Corp"
→ Worker queries Spine, assembles Entity360
→ Returns unified view in < 200ms
→ Subscribes user to real-time updates for Acme
Notification Worker
→ "Acme health dropped below 65" → notification fired
→ "Meeting in 15 minutes" → notification fired
→ "PR #431 approved" → notification fired
→ All deterministic. All pipeline-driven.
Search Worker
→ Every new event indexed immediately
→ User searches "Acme escalation" → instant results
→ Semantic search powered by vector embeddings
EVENING (After user leaves):
Consolidation Worker
→ Compressed today's 847 events into memory
→ Updated organizational knowledge base
→ Refreshed prediction models
Triage Worker
→ Aged out 340 hot memory items to warm
→ Archived 89 warm items to cold storage
→ Discarded 23 items with no business value
→ Elevated 3 AI patterns to permanent status
Preparation Worker
→ Pre-loaded tomorrow's workbench contexts
→ Queued tomorrow's notifications
→ Pre-generated standup summaries
→ Drafted tomorrow's Twin proposals
WORKERS ARE THE SYSTEM'S DAILY WORKFORCE.
They do the labor. The user sees the results.
Twin Capabilities — How It Connects, Acts, and Communicates
How the Twin Connects to Tools
TWIN → TOOL CONNECTION
The Twin NEVER connects to tools directly.
Never.
The Twin reads from the Spine.
The Twin writes proposals to the Spine.
The Integration Manager handles all tool communication.
FLOW:
Twin needs to know Acme's Salesforce data
→ Twin reads Entity360 from Spine
→ Spine already has the data (via Integration Manager)
→ Twin never touches Salesforce
Twin wants to send a Slack message
→ Twin writes proposal to Spine: "Send message to #acme-cs"
→ Governance checks the proposal
→ If approved: Spine → Integration Manager → Slack
→ Twin never touches Slack
Twin wants to create a Jira ticket
→ Twin writes proposal to Spine: "Create P1 for Dataway"
→ Governance checks the proposal
→ If approved: Spine → Integration Manager → Jira
→ Twin never touches Jira
THE RULE:
→ Twin reads truth from Spine
→ Twin proposes actions to Spine
→ Integration Manager executes approved actions
→ Spine records everything
How the Twin Gets Work Done via Agents
TWIN → AGENT COMMUNICATION
Sometimes the Twin needs specialized help.
It calls other agents.
AGENT-TO-AGENT COMMUNICATION (via Capability Fabric):
Twin needs to analyze a contract PDF
→ Twin calls: Document Analysis Agent (LLM Call)
→ Agent reads the PDF from R2
→ Agent returns structured analysis
→ Twin incorporates into its reasoning
Twin needs to draft a customer email
→ Twin calls: Writing Agent (LLM Call)
→ Agent receives context from Spine
→ Agent drafts email
→ Twin reviews and proposes to user
Twin needs to analyze code for a bug
→ Twin calls: Code Analysis Agent (MCP)
→ Agent reads the codebase
→ Agent returns findings
→ Twin proposes fix to engineer
Twin needs to generate a forecast
→ Twin calls: Forecasting Agent (LLM Call)
→ Agent receives pipeline data from Spine
→ Agent generates forecast
→ Twin presents in Executive workbench
CAPABILITY FABRIC DECIDES:
→ What agents are available?
→ What tools can be called?
→ What permissions exist?
→ What governance applies?
The Twin doesn't hardcode agent connections.
It queries the Capability Fabric:
"What can I do with the data I have?"
The Fabric returns available capabilities.
The Twin selects the best one.
How Updates Are Posted to the User
TWIN → USER COMMUNICATION
The Twin communicates through FIVE channels:
-
PROPOSALS (In Approvals Workbench)
─────────────────────────────────────
The Twin's primary communication method."Acme Corp health dropped to 62.
Recovery plan drafted.
[Approve] [Modify] [Dismiss]"Context: Full Entity360 available on expand
Confidence: Shown as percentage
Priority: Ordered by impact and urgency -
NOTIFICATIONS (Push to User)
─────────────────────────────────────
Real-time alerts when something needs attention."Acme Corp health alert: dropped below 65"
"Deal velocity warning: Meridian stalled 22 days"
"Meeting prep ready: Northwind renewal at 2 PM"Delivered via:
→ Workbench notification badge
→ Email (if configured)
→ Slack (if connected)
→ Mobile push (if installed)
→ Browser notification (if permitted) -
MORNING BRIEFING (Daily Summary)
─────────────────────────────────────
The Twin's daily briefing to each user."Good morning, Sarah. Here's your day:
→ 3 meetings today
→ 2 deals need attention (Acme, Meridian)
→ 1 proposal pending your review
→ Northwind renewal is Thursday
→ Top priority: Acme health recovery" -
WORKBENCH ENRICHMENT (Inline Intelligence)
─────────────────────────────────────
The Twin enriches workbench views with insights.User opens Acme Corp Entity360.
At the top, a Twin insight bar:"Acme's health trajectory suggests risk.
Correlated with unresolved bug #8821.
Similar pattern seen in Q1 for Northwind.
[View Pattern] [Take Action]"The user didn't ask for this.
The Twin saw the pattern and surfaced it. -
DIRECT MESSAGING (When Enabled)
─────────────────────────────────────
The Twin can message the user directly
through connected channels.Via Slack DM:
"Hi Sarah, I noticed Acme Corp's health dropped
to 62. I've drafted a recovery plan.
Review it here: [link]"Via Email:
Subject: "Action needed: Acme Corp health alert"
Body: Brief summary + link to workbenchVia In-App Chat:
Conversational interface
User can ask: "What's going on with Acme?"
Twin responds with context from Spine
MESSAGING BETWEEN TWIN AND USER:
Twin → User:
Proposals. Notifications. Briefings. Insights. Direct messages.
User → Twin:
Approve / Modify / Dismiss proposals
Ask questions: "Why did Acme health drop?"
Give commands: "Schedule a meeting with Acme VP"
Provide feedback: "Don't propose emails for Acme.
They prefer calls."
The Twin LEARNS from every user response.
Essential User Work in the Workbench
The workbench is not just a display. The user does real work here. This is L1 — the core product.
WHAT THE USER DOES IN THE WORKBENCH
This is NOT agentic. This is NOT AI.
This is the user doing their job. On the platform.
SALES REP:
→ Reviews pipeline
→ Updates deal stages
→ Logs call notes
→ Sends emails
→ Creates tasks
→ Schedules meetings
→ Views customer history
→ Prepares for meetings
→ Updates forecasts
All of this writes to the Spine.
All of this syncs back to connected tools.
All of this is deterministic. Pipeline-driven.
CS MANAGER:
→ Reviews health dashboard
→ Checks open cases
→ Responds to escalations
→ Prepares renewal presentations
→ Logs customer interactions
→ Updates account notes
→ Creates QBR documents
ENGINEER:
→ Reviews sprint board
→ Updates issue status
→ Submits PRs
→ Writes code review comments
→ Updates blockers
→ Logs time
→ Documents decisions
EXECUTIVE:
→ Reviews KPIs
→ Approves budgets
→ Reviews portfolio
→ Checks forecasts
→ Reads risk reports
ALL OF THIS IS USER WORK.
ALL OF THIS IS L1.
ALL OF THIS WRITES TO THE SPINE.
NONE OF THIS REQUIRES AI.
The Twin watches this work.
The Twin learns from this work.
The Twin proposes improvements to this work.
But the Twin does NOT do this work.
The user does the work.
The AI helps the user do it better.
Data Access Levels — Spine via LLM
What can the LLM see? This is a critical boundary.
SPINE → LLM DATA ACCESS
The LLM (Twin's reasoning engine) accesses the Spine
through a structured ACCESS CONTRACT.
LEVEL 1: ENTITY SUMMARY
→ The LLM receives a structured summary of an entity
→ Not raw data. Not full database records.
→ A canonical, pre-processed summary.
Example: Entity360 for Acme Corp
{
"entity": "acme-corp",
"type": "customer",
"arr": 1200000,
"health_score": 62,
"health_trend": "declining",
"open_cases": 3,
"active_deals": 2,
"last_touchpoint": "2026-07-02",
"renewal_date": "2026-08-15",
"risk_level": "moderate",
"champion": "John Smith",
"recent_events_count": 12
}
LEVEL 2: CONTEXT WINDOW
→ The LLM receives relevant timeline events
→ Limited to a configurable window (last 30 days default)
→ Filtered by relevance score
→ Summarized if too long
Example: Last 30 days for Acme Corp
[
{ "date": "2026-07-02", "event": "Health dropped to 62", "source": "Spine" },
{ "date": "2026-07-01", "event": "Slack escalation in #acme-cs", "source": "Slack" },
{ "date": "2026-06-28", "event": "Bug #8821 reported", "source": "Jira" },
...
]
LEVEL 3: KNOWLEDGE CONTEXT
→ The LLM receives relevant knowledge items
→ Organizational patterns
→ Historical decisions
→ User preferences
Example:
[
{ "knowledge": "Acme prefers phone calls over email", "confidence": 0.95, "source": "user_input" },
{ "knowledge": "Health drops for Acme correlate with bugs", "confidence": 0.89, "source": "ai_pattern" },
...
]
LEVEL 4: CAPABILITY CONTEXT
→ The LLM receives available capabilities
→ What actions it CAN propose
Example:
[
{ "capability": "create_jira_issue", "source": "Jira" },
{ "capability": "send_slack_message", "source": "Slack" },
{ "capability": "schedule_meeting", "source": "Calendar" },
{ "capability": "draft_email", "source": "Email" },
]
WHAT THE LLM CANNOT ACCESS:
❌ Raw database queries
❌ Other users' private data (without governance approval)
❌ Unredacted PII (governed by policy)
❌ System credentials or tokens
❌ Data from entities outside its access scope
❌ Full historical dumps (limited to context window)
❌ Direct write access to any system
THE LLM RECEIVES CONTEXT.
THE LLM DOES NOT RECEIVE RAW DATA.
THE SPINE GOVERNS WHAT THE LLM CAN SEE.
Agentic Work vs Just Prompts
This is the critical classification.
CLASSIFYING AGENTIC WORK VS PROMPTS
PROMPT (Not Agentic):
→ User asks a question
→ LLM answers
→ No action taken
→ No tool called
→ No write to Spine
→ No governance needed
→ No approval needed
Examples:
"What is Acme Corp's health score?"
→ LLM reads Spine context, returns answer
"Summarize last week's Slack activity"
→ LLM reads timeline, returns summary
"What are my tasks for today?"
→ LLM reads Spine, returns task list
This is a PROMPT. Not an agent.
The LLM is a reader. Not a doer.
No side effects. No writes. No governance.
AGENTIC WORK (Truly Agentic):
→ The LLM takes an ACTION
→ A tool is called
→ A write occurs
→ Data changes
→ Governance applies
→ Approval may be required
Examples:
"Escalate Acme's bug to P1"
→ LLM proposes → Governance checks →
User approves → Jira updated via Integration Manager
"Draft and send a recovery email to Acme"
→ LLM drafts → Governance checks →
User approves → Email sent via Integration Manager
"Schedule a QBR with Acme's VP for next Tuesday"
→ LLM creates event → Governance checks →
User approves → Calendar updated via Integration Manager
"Create a new task for the engineering team"
→ LLM proposes → Governance checks →
User approves → Jira issue created via Integration Manager
This is AGENTIC. The LLM is an actor. Not just a reader.
Side effects exist. Writes occur. Governance applies.
THE CLASSIFICATION:
┌─────────────────────────────────────────────────┐
│ │
│ PROMPT AGENTIC │
│ ───── ─────── │
│ Reads from Spine Writes to Spine │
│ No tool calls Tool calls required │
│ No side effects Side effects exist │
│ No governance Governance applies │
│ No approval Approval may be needed│
│ No agent-to-agent Agent calls agent │
│ User gets an answer User gets a proposal │
│ LLM is a READER LLM is an ACTOR │
│ │
│ Example: Example: │
│ "What's Acme's health?" "Escalate Acme's bug" │
│ │
└─────────────────────────────────────────────────┘
THE GRAY AREA — ENRICHMENT:
→ LLM reads Spine + external source → Enriches Spine
→ Example: LLM reads a contract PDF → Extracts key dates
→ Writes structured data to Spine
→ This is agentic (write occurs) but low-risk
→ Governance: auto-approved (enrichment, not action)
→ Still classified as agentic because Spine changes
THE ARCHITECTURE RULE:
→ If the LLM only READS → It is a prompt
→ If the LLM WRITES or CALLS → It is agentic
→ All agentic work passes through Governance
→ All agentic work is recorded in the Spine
→ The user always knows what the AI did
The Complete System — Final Definition
THE INTEGRATEWISE SYSTEM
PRODUCT (L1 — Pipeline)
→ One click to connect tools
→ Integration Manager handles all tool communication
→ Spine is the Single Source of Truth
→ User works on unified data in their workbench
→ Workers process data continuously
→ Pipelines flow: Ingest → Normalize → Resolve →
Timeline → Knowledge → Triage → Projection → Experience
→ Everything deterministic. Everything reliable.
AI (L2 — OODA)
→ Watches the product (L1 events)
→ Lives in its Home (user models, org memory, predictions)
→ Reasons only when action is needed
→ Proposes actions through Governance
→ Learns from every outcome
→ Gets smarter every day
→ Communicates via proposals, notifications,
briefings, insights, and direct messages
CAPABILITY FABRIC
→ Registry of everything the workspace can do
→ Sources: Connected tools, domain packs,
shared features, platform services
→ Queried by Workbench and Twin alike
AGNOSTIC LAYERS
→ Integration agnostic (Nango, Native, MCP, LLM Call, Direct)
→ AI model agnostic (Claude, GPT, Gemini, Local, Future)
→ Frontend agnostic (Web, Mobile, CLI, Slack, Embedded)
→ Deployment agnostic (Vercel, Cloudflare, Docker, On-prem)
→ Storage agnostic (Postgres, KV, R2, Vector, Queues)
MEMORY
→ Simple data (structured fields)
→ Rich data (files, images, documents)
→ Knowledge (human + AI)
→ Memory triage: Hot → Warm → Cold → Permanent → Discard
→ Organizational continuity preserved
THE ONE-LINE DEFINITION:
The system connects tools with one auth, unifies data into a
single source of truth, lets users work on that truth in their
own workbench, and gives the AI a home where it watches, learns,
reasons, proposes, and grows — every day, forever.