# M5 Witness Story: Multi-Tool Orchestration
## The Constraint Removed
**Before M5:** System assumes singular tool ownership of conversation.
**After M5:** Conversation orchestrates multiple tools through shared context.
The shift is not "multiple tools exist"
The shift is "tools coordinate through conversation state"
---
## Act 1: The Singular World
You start in a world with one tool: `example-tool`.
**You:** "Who are you?"
**System:** "I'm example-tool v2.2.1"
**You:** "Greet me"
**System:** "🎯 M2 Negotiation Ready! Version 2.2.1"
**Truth witnessed:** Baseline established. M1-M4 still work.
---
## Act 2: The Registry Awakens
A second tool enters: `data-tool` (manages structured data).
**You:** "List available tools"
**System:**
```
Available tools:
- example-tool v2.2.1 (greet, echo, write-file)
- data-tool v1.0.0 (create-resource, read-resource, list-resources)
```
**Truth witnessed:** Registry can discover multiple tools. Plurality is visible.
**Decision point:** You notice the system can now see multiple actors. But can they coordinate?
---
## Act 3: Intent Disambiguation
You ask for an action without specifying which tool.
**You:** "Greet me"
**System:** [Routes to example-tool] "🎯 M2 Negotiation Ready!"
**You:** "Create resource called 'project-alpha' with data: {status: 'active'}"
**System:** [Routes to data-tool] "Resource 'project-alpha' created at level 1"
**Truth witnessed:** System routes based on capability matching, not explicit tool selection.
**The shift:** You stopped commanding tools. You started conversing with a system that coordinates tools.
---
## Act 4: Shared Context Establishment
Now the critical moment: Can Tool-A establish context that Tool-B can access?
**You:** "Create resource 'build-config' with data: {compiler: 'typescript', target: 'es2022'}"
**System:** [data-tool] "Resource 'build-config' created"
**You:** "Show me the conversation history"
**System:**
```
Conversation state:
- Tool interactions: 2 (example-tool: 1, data-tool: 2)
- Named resources: ['project-alpha', 'build-config']
- Permission levels:
- example-tool: level 1
- data-tool: level 1
```
**Truth witnessed:** Resources are stored in **conversation state**, not tool state.
**The moment of coordination:** The system now has shared memory across tools.
---
## Act 5: Cross-Tool Reference
Can Tool-B access what Tool-A created without you re-specifying it?
**You:** "Read resource 'build-config'"
**System:** [data-tool]
```
{
name: 'build-config',
data: { compiler: 'typescript', target: 'es2022' },
created_by: 'data-tool',
conversation_id: 'conv_001'
}
```
**You:** "Echo the compiler from build-config"
**System:** [example-tool] "Echo: typescript"
**Truth witnessed:** Tool-A (example-tool) accessed resource created by Tool-B (data-tool).
**The coordination proof:** Tool didn't ask you "what's build-config?". It read from shared conversation context.
---
## Act 6: Permission Scoping
Permissions must be per-tool, not global. Otherwise Tool-A at level 1 could execute if you're at level 3 globally.
**You:** "Upgrade example-tool to level 2"
**System:** "example-tool upgraded: level 1 → 2"
**You:** "Write file 'output.txt' with example-tool"
**System:** [example-tool] "✅ File write succeeded (level 2)"
**You:** "Create resource 'protected-data' with data-tool"
**System:** [data-tool]
```
Permission upgrade required for "create-resource"
Current level: 1
Required level: 2
To upgrade: call with action "upgrade:data-tool:level-2"
```
**Truth witnessed:** Permission levels are scoped per tool.
**You:** "Upgrade data-tool to level 2"
**System:** "data-tool upgraded: level 1 → 2"
**You:** "Create resource 'protected-data'"
**System:** [data-tool] "Resource 'protected-data' created"
**The scoping proof:** example-tool at level 2, data-tool started at level 1. Each tool has independent permission ladder.
---
## Act 7: Coordination Failure Mode
Security must extend to shared context. If Tool-C tries to access Tool-A's resource without permission, coordination must enforce boundary.
A third tool appears: `admin-tool` (level 3 operations: delete, execute).
**You:** "List tools"
**System:**
```
Available tools:
- example-tool v2.2.1 (level 2)
- data-tool v1.0.0 (level 2)
- admin-tool v1.0.0 (level 1)
```
**You:** "Delete resource 'protected-data' using admin-tool"
**System:** [admin-tool]
```
Permission upgrade required for "delete-resource"
Current level: 1
Required level: 3
Tool admin-tool cannot perform level 3 operations.
```
**Truth witnessed:** Permission boundary protects shared context, not just tool actions.
**The security proof:** Orchestration has boundaries. Shared context doesn't mean shared permissions.
---
## Act 8: Hot-Reload With Registry
M1 proved hot-reload for one tool. M5 must prove hot-reload for registry.
**You:** "Show current tool versions"
**System:**
```
- example-tool v2.2.1
- data-tool v1.0.0
- admin-tool v1.0.0
```
*You edit `data-tool.ts`, change version to 1.1.0, add new capability: `update-resource`*
**System:** [Hot-reload detected] "Reloading data-tool..."
**You:** "Show current tool versions"
**System:**
```
- example-tool v2.2.1
- data-tool v1.1.0 ← VERSION CHANGED
- admin-tool v1.0.0
```
**You:** "Update resource 'build-config' compiler='rust'"
**System:** [data-tool] "Resource 'build-config' updated (new capability from v1.1.0)"
**Truth witnessed:** Hot-reload works across registry. Tool updates don't break conversation.
**The M1+M5 proof:** Infrastructure from M1 scales to multi-tool system.
---
## Act 9: Persistence Across Tools
M3 proved cloud persistence for one tool. M5 must prove persistence includes all tool interactions.
**You:** "Show conversation state"
**System:**
```
Conversation ID: conv_001
Total interactions: 18
Tool breakdown:
- example-tool: 4 actions
- data-tool: 11 actions
- admin-tool: 1 action (denied)
Resources created: 3
Permission history:
- example-tool: [level 1 → level 2]
- data-tool: [level 1 → level 2]
- admin-tool: [level 1]
```
*You restart the MCP server*
**You:** "Show conversation state"
**System:**
```
[Restored from Supabase]
Conversation ID: conv_001
Total interactions: 18
Tool breakdown:
- example-tool: 4 actions
- data-tool: 11 actions
- admin-tool: 1 action (denied)
Resources created: 3
Permission history:
- example-tool: [level 1 → level 2]
- data-tool: [level 1 → level 2]
- admin-tool: [level 1]
```
**Truth witnessed:** All tool interactions persisted. Conversation continuity spans multiple tools.
**The M3+M5 proof:** Cloud persistence includes full multi-tool orchestration state.
---
## Act 10: Emergent Capability
The final proof: Can tools compose WITHOUT explicit orchestration logic?
**You:** "Create workflow: data-tool creates 'deploy-config', example-tool echoes it, admin-tool validates it"
**System:**
1. [data-tool] "Resource 'deploy-config' created: {env: 'production', region: 'us-east'}"
2. [example-tool] "Echo: production deployment to us-east"
3. [admin-tool] "Validation: deploy-config is well-formed"
**You:** "Show me the conversation state after workflow"
**System:**
```
Workflow trace:
1. data-tool:create-resource → deploy-config
2. example-tool:echo → read deploy-config from shared context
3. admin-tool:validate → read deploy-config from shared context
No explicit passing of data between tools.
All coordination through conversation state.
```
**Truth witnessed:** Tools composed through shared context. No orchestration code required.
**The emergence proof:** Coordination is not programmed, it's emergent from conversation continuity.
---
## The Truth Shift
### What Changed
**Before M5:**
- Conversation = one human, one tool
- Permission = global per conversation
- State = tool owns its state
- Coordination = not possible
**After M5:**
- Conversation = one human, many coordinated tools
- Permission = scoped per tool, tracked in conversation
- State = conversation owns resources, tools access shared context
- Coordination = emergent through conversation continuity
### The Non-Obvious Truth
M5 is not a registry pattern.
M5 is not an intent router.
M5 is not a multi-tool dispatcher.
**M5 is conversation as orchestrator.**
The conversation became the coordination mechanism.
Tools don't talk to each other.
Tools talk through conversation state.
This is not explicit orchestration.
This is emergent orchestration.
### The Sacred Artifacts
1. **Tool Registry** - Tools register capabilities, conversation discovers them
2. **Shared Context** - Resources live in conversation, not tools
3. **Scoped Permissions** - Each tool has independent permission ladder
4. **Intent Router** - Capabilities match requests, tools don't need names
5. **Coordination Protocol** - Tools compose through shared conversation state
### The Witness Protocol
If you can:
1. Create resource with Tool-A
2. Read that resource with Tool-B WITHOUT re-specifying it
3. Upgrade Tool-A permissions without affecting Tool-B
4. Restart server and see all tool interactions restored
5. Hot-reload any tool without breaking conversation
Then M5 is complete.
---
## Acceptance Criteria
- [ ] Registry discovers multiple tools dynamically
- [ ] Intent router selects tool based on capability, not name
- [ ] Shared context: Tool-B accesses resources created by Tool-A
- [ ] Permission scoping: Each tool has independent permission ladder
- [ ] Security boundary: Permission protects shared context access
- [ ] Hot-reload compatibility: Tool updates don't break orchestration
- [ ] Persistence: All tool interactions survive server restart
- [ ] Emergent coordination: Tools compose through conversation state
- [ ] Audit trail: Conversation state tracks all cross-tool interactions
- [ ] Contradiction enforcement: Alignment detector works across all tools
**Witness outcome:** "Create with Tool-A, read with Tool-B, upgrade Tool-A to level 2, Tool-B still at level 1, restart server, all state restored."
