Unclassified

SpineWorkspace — AI Workbench Information Architecture

<!-- DOCUMENT CLASS: PUBLIC | SOURCE: 07_SPINEWORKSPACE_AGENTIC_WORKBENCH_IA.md --> <!-- STATUS: Aligned with Founder Canon (31 August 2026) --> <!-- RENAMED: "Agentic Workbench" → "AI Workbench" per Founder Canon -->

SpineWorkspace — AI Workbench Information Architecture

Status: CANONICAL TARGET
Product: SpineWorkspace
Surface: AI Workbench (Twin and Spine Agents)
Foundation: Business Context Spine (THE semantic foundation) + AI Continuity Memory

1. Purpose

The AI Workbench is the machine-side operating environment in which Twin and Spine Agents perform business work over the shared Business Context Spine.

It exists to reason over and act on Business Context. Without Business Context, the AI Workbench has nothing to work with. With it, the AI Workbench already knows the business objective, the current state, the evidence, the authority, and what needs to happen next.

It is not a generic AI playground.

It is where Twin and Spine Agents:

  • understand Business Context and Work;
  • assemble context from the Spine;
  • reason over business objectives and KPIs;
  • plan and allocate work;
  • delegate to agents;
  • communicate with humans;
  • invoke governed capabilities;
  • monitor execution;
  • verify results against Business Context;
  • report to the user.

The Tier-0 Principle

Business Context is the semantic foundation of SpineWorkspace. The AI Workbench operates on Business Context, not raw data. Without Business Context, the AI Workbench has nothing to work with.

2. IA model

AI WORKBENCH
│
├── CURRENT WORK (grounded in Business Context)
│   ├── Active Work
│   ├── Assigned Work
│   ├── Waiting Work
│   └── Escalations
│
├── BUSINESS CONTEXT (from the Spine)
│   ├── Active Context
│   ├── Related Entities
│   ├── Relevant Memory
│   ├── Communications
│   ├── Decisions
│   ├── Policies
│   ├── KPIs and Objectives
│   └── Evidence
│
├── AI CONTINUITY MEMORY (working state that serves BC)
│   ├── Prior Assignment State
│   ├── Working Summaries
│   ├── Unresolved Questions
│   ├── Current Plans
│   ├── Active Hypotheses
│   └── Interaction Preferences
│
├── REASONING
│   ├── OODA (embedded, not buttons)
│   ├── Intent
│   ├── Orientation
│   ├── Plan
│   ├── Alternatives
│   └── Recommendation
│
├── WORK ALLOCATION
│   ├── Human
│   ├── Twin
│   ├── Domain Agent
│   ├── Specialist Agent
│   ├── Workflow
│   └── System
│
├── AGENT WORK
│   ├── Delegated
│   ├── In Progress
│   ├── Blocked
│   ├── Completed
│   └── Failed
│
├── CAPABILITY EXECUTION
│   ├── Capability
│   ├── Tool Binding
│   ├── MCP
│   ├── API
│   ├── Workflow
│   └── ADK
│
├── COMMUNICATION
│   ├── User Chat
│   ├── Slack
│   ├── Email
│   ├── Approval Request
│   └── Agent Communication
│
├── EVIDENCE / RESULTS
│   ├── Evidence
│   ├── Receipts
│   ├── Results
│   ├── Errors
│   └── Reconciliation
│
└── EXCEPTIONS
    ├── Missing Context
    ├── Ambiguous Outcome
    ├── Policy Block
    ├── Approval Required
    └── Escalation

3. Twin lifecycle

UNDERSTAND (Business Context)
 ↓
CONTEXTUALIZE (from the Spine)
 ↓
ALLOCATE (work grounded in BC)
 ↓
PLAN / PROPOSE
 ↓
DELEGATE
 ↓
EXECUTE THROUGH GOVERNED CAPABILITIES
 ↓
VERIFY (against Business Context)
 ↓
REPORT
 ↓
ADAPT (update AI Continuity Memory)

OODA operates internally, embedded in every interaction:

OBSERVE → ORIENT → DECIDE → ACT

4. Context boundary

The Twin receives:

Business Context Spine
 ↓
Context Assembly
 ↓
Permission · Purpose · Freshness · Relevance
 ↓
AI Workbench Context
 ↓
Twin

The Twin never directly queries canonical Business Context Spine.

5. Agent hierarchy

USER
 ↓
TWIN
 ├── Domain Agents
 ├── Specialist Agents
 ├── Research Agents
 ├── Workflow Agents
 └── External Agents

The Twin remains the orchestration boundary.

6. Agent handoff

Twin
 ↓
Work Handoff (with Business Context)
 ↓
Agent
 ↓
Scoped Context (grounded in BC)
 ↓
Result + Evidence (verified against BC)
 ↓
Twin

Agent handoff does not create authority.

7. Work assignment contract

Every agent assignment should identify:

  • Work ID;
  • objective (tied to Business Context);
  • assignee;
  • capability;
  • authority envelope;
  • context reference (from the Spine);
  • constraints;
  • dependencies;
  • expected outcome (business outcome);
  • evidence requirement;
  • escalation condition.

8. Completion contract

An agent result must contain:

  • status;
  • result;
  • evidence;
  • actions taken;
  • errors;
  • confidence;
  • attribution;
  • timestamp;
  • recommended next step.

The Twin validates it against Work and Business Context before reporting completion.

9. Human intervention

The Twin stops and asks the human when:

  • authority is insufficient;
  • policy requires approval;
  • context is materially ambiguous;
  • risk exceeds allowed threshold;
  • external outcome is ambiguous;
  • reconciliation fails;
  • a consequential judgment remains human-owned.

10. AI Workbench is not autonomous truth

The AI Workbench may contain:

  • working memory (AI Continuity Memory);
  • agent plans;
  • drafts;
  • temporary context;
  • tool results;
  • workflow state.

None of these become Business Context automatically. They are working states that serve Business Context.

11. Acceptance criteria

  1. Twin is user-scoped.
  2. Twin operates only on bounded Business Context projections.
  3. Twin is the primary AI orchestrator.
  4. Agents are bounded workers operating on Business Context.
  5. Agent handoff is communication, not authority.
  6. Capabilities are separate from tool implementations.
  7. Consequential execution traverses governance.
  8. Completion requires verification/reconciliation against Business Context.
  9. Results return to the Twin.
  10. Business Context promotion remains outside the Twin.
  11. AI Continuity Memory serves Business Context; it does not replace it.