Runtime and MCP Architecture
MindMux separates model execution from project knowledge through a runtime layer and an MCP tool layer.
Runtime abstraction
The runtime abstraction allows different execution backends to power the same product surface. Chat sessions and tasks both rely on this layer.
The main goals are:
- runtime portability
- shared product behavior across backends
- clearer boundaries between product logic and vendor-specific execution
Currently Supported Runtimes
The product direction is to let multiple runtimes operate against one knowledge model. The currently documented available runtimes are:
- Claude Code
- Codex
The important architectural point is not the brand list itself. It is that the brain does not belong to any one of them.
MCP as the knowledge boundary
MindMux exposes structured project capabilities through MCP tools rather than relying only on raw prompt context.
Important tool families include:
- brain read and write tools
- root doc tools
- skill tools
- task tools
- configuration tools
Typical request path
Chat scope vs task scope
The tool surface is intentionally scoped. Some tools are available to the main chat agent but not to delegated task execution, especially where path resolution, orchestration authority, or project-wide writes need tighter control.
Examples of chat-only behavior include:
- project-wide orchestration
- user-interaction cards
- broad knowledge writes
Examples of task-scope behavior include:
- focused read access
- constrained review or execution flows
Independent MCP server process
The codebase uses an MCP server boundary as a separate process rather than folding everything into one monolithic runtime loop. This supports stronger control over tool exposure and keeps the knowledge interface explicit.
External connectors and bridging
MindMux is also an MCP client. That means the product can both:
- expose its own capabilities to runtimes
- consume external MCP servers as connectors
Where a runtime cannot directly consume a given transport shape, the architecture includes a bridge layer that normalizes the connector into a usable form.
Why this matters
This architecture gives MindMux a stable knowledge contract. Runtimes can vary, but the project brain and its operations remain legible and structured.