SpineWorkspace — Communications Over the Bridge
SpineWorkspace — Communications Over the Bridge
Status: CANONICAL TARGET
Product: SpineWorkspace
Platform: IntegrateWise
Primary purpose: Governed communication and contextual work continuity across humans, Twin, agents and external systems
Foundation: Business Context Spine (THE semantic foundation)
1. Definition
The Bridge is the governed communication substrate through which work-related messages, context references, decisions, approvals, requests, agent handoffs and execution signals move between the human Workbench, Twin, agents and connected systems while retaining identity, Work, provenance and authority context.
The Bridge is not:
- a fourth memory store;
- a canonical database;
- a replacement for Slack/email/Teams;
- an authority bypass;
- an unrestricted agent bus.
The Tier-0 Principle
Business Context is the semantic foundation of SpineWorkspace. The Bridge communicates Business Context. Without Business Context, the Bridge has nothing to communicate.
2. Bridge topology
BUSINESS CONTEXT SPINE
(THE Semantic Foundation)
│
BUSINESS CONTEXT
│
┌─────────┴─────────┐
│ │
HUMAN WORKBENCH AI WORKBENCH
│ │
└─────────┬─────────┘
│
COMMUNICATION BRIDGE
│
┌───────────────────┼───────────────────┐
│ │ │
HUMAN AGENTS SYSTEMS
│ │ │
Slack / Email ACP / Agent APIs / Webhooks
Chat / Meetings Handoffs Workflows / MCP
│ │ │
└───────────────────┼───────────────────┘
│
Work / Context
│
▼
BUSINESS CONTEXT SPINE
3. Bridge message envelope
Every governed Bridge message should carry or resolve to:
Tenant
Principal
Sender
Recipient
Work ID
Task ID where applicable
Communication Type
Purpose
Context Reference
Capability Reference where applicable
Authority Context
Source Channel
Correlation ID
Causation ID
Timestamp
Provenance
Sensitivity
Status
4. Channel taxonomy
Human Channels
├── Workbench Chat
├── Slack
├── Email
├── Teams
├── Meetings
└── Calls
Agent Channels
├── ACP
├── Work Handoff
├── Context Reference
├── Agent Result
└── Escalation
System Channels
├── API
├── Webhook
├── Event Bus
├── Workflow Event
├── MCP
└── Connector Event
The Bridge standardizes the semantic work context without replacing the underlying transport.
5. Communication is attached to Work
A message is not isolated from business context.
Communication
↓
Work
↓
Entity / Customer / Account / Project
↓
Context
↓
Decision / Assignment / Outcome
Example:
Slack
↓
Manager approves discount
↓
Communication Event
↓
Work ID
↓
Approval Event
↓
Governance
↓
Capability Execution
6. Human-to-Twin communication
Human
↓
Workbench / Chat
↓
Bridge
↓
Twin
↓
Context Assembly
↓
Response / Proposal / Action
The Twin receives user intent plus the relevant Work/Context reference.
7. Twin-to-agent communication
Twin
↓
Work Allocation
↓
ACP
↓
Domain Agent
↓
Scoped Context
↓
Agent Work
↓
Result + Evidence
↓
ACP
↓
Twin
The agent does not become the owner of the Work.
8. Human-to-human communication
The user may consult a manager or teammate through Slack, email, chat or meetings.
User
↓
Bridge
↓
External Communication Channel
↓
Response
↓
Bridge
↓
Work / Decision / Evidence
↓
Twin
The Work remains continuous even when the human leaves SpineWorkspace to communicate in another channel.
9. Context sharing
The Bridge carries a reference to governed context, not arbitrary raw organizational memory.
Context Reference
├── Work
├── Purpose
├── Relevant Entities
├── Current State
├── Allowed Evidence
├── Authority Scope
├── Freshness
└── Expiry
Context is assembled from Spine and filtered before being handed to an external participant.
10. ACP vs MCP
MCP
AI ↔ Tool / Resource / Capability
ACP
Agent ↔ Agent / Agent ↔ Twin
through Work and Context handoff
MCP does not establish organizational authority.
ACP does not establish organizational authority.
Governance establishes whether consequential actions are permitted.
11. Communication-derived evidence
Communication may become:
Message
↓
Evidence
↓
Context
↓
Decision / Interpretation
↓
Triage
↓
Candidate
↓
Governed Promotion
↓
Organizational Memory
Raw messages are not automatically Organizational Memory.
12. Approval through the Bridge
An approval received through Slack or another connected channel must be converted to a verified approval event:
Channel Response
↓
Authenticated Principal
↓
Tenant Check
↓
Work ID
↓
Candidate / Action Version
↓
Policy Check
↓
Immutable Approval Event
↓
Governed Execution / Promotion
A Slack reaction alone is never a canonical authority bypass.
13. Execution through the Bridge
Human / Twin Intent
↓
Bridge / Work Context
↓
Capability
↓
Governance
↓
Execution Fabric
↓
API / MCP / Workflow / Tool
↓
Source System
14. Return path
Source System
↓
Webhook / Event / Polling / API
↓
Connector
↓
Loader
↓
Normalizer
↓
Business Context
↓
Reconciliation
↓
Spine
This guarantees that outbound execution and inbound state remain part of one continuity thread.
15. Knowledge evolution through the Bridge
Communication
+
Execution Outcome
↓
Evidence
↓
Context
↓
Interpretation
↓
Triage
↓
Governance
↓
Organizational Memory
↓
Future Context
This is how communications and executed work can enrich organizational knowledge without allowing raw communications or agent output to become truth automatically.
16. Bridge reliability
Required properties:
- authenticated delivery;
- tenant isolation;
- correlation;
- causation;
- idempotency;
- deduplication;
- replay control;
- provenance;
- delivery status;
- audit;
- expiry where applicable;
- ambiguity handling;
- reconciliation for consequential effects.
An ambiguous outbound result must be reconciled before retrying.
17. Bridge laws
- Bridge communication is not canonical truth.
- Bridge context is scoped to Work and purpose.
- Bridge messages retain source provenance.
- External channels cannot bypass governance.
- Agent communication does not grant authority.
- Approved consequential actions traverse Execution Fabric.
- Source-system results re-enter through ingestion and reconciliation.
- Communication-derived knowledge enters Organizational Memory only through governed promotion.
- The Bridge preserves Work continuity across applications and agents.