mahavishnu

Mahavishnu Orchestrate

Etymology: From Sanskrit maha (great) + Vishnu (the preserver in Hindu trinity)

Part of the Bodai Ecosystem - The Orchestrator component

Mahavishnu is the internal control plane for the Bodai ecosystem: a multi-repo, multi-engine, async-first orchestration system for coordinating work across our own repositories, MCP services, and AI-capable backends. It enables workflow routing, cross-repository coordination, operational tooling, and headless worker orchestration.

Mahavishnu is maintained first as ecosystem infrastructure for Bodai-owned repos. Some parts are reusable and may have future commercial value, but the current product posture is internal orchestration rather than a polished general-purpose external platform.

Quality & CI

Crackerjack is the standard quality-control and CI/CD gate across Mahavishnu and the broader Bodai ecosystem. Prefer Crackerjack-aligned local validation before relying on narrower repo-only checks.

Ecosystem Components

Component	Role	Port	Description
Mahavishnu	Orchestrator	8680	Multi-engine workflow orchestration
Akosha	Seer	8682	Cross-system intelligence & embeddings
Dhara	Curator	8683	Persistent object storage with ACID
Session-Buddy	Builder	8678	Session lifecycle & knowledge graphs
Crackerjack	Inspector	8676	Quality gates & CI/CD validation
Oneiric	Foundation	N/A	Component resolution, lifecycle management, adapter system, action kits, domain bridges, runtime orchestration, remote delivery

Positioning

Mahavishnu is best understood as an ecosystem control plane, not as a general-purpose coding agent. Its current sweet spot is coordinating repo-centric workflows, tools, and services across the Bodai stack.

Commercially, the most plausible future niche is a narrow B2B control plane for AI-native engineering teams managing many repos, tools, and agent workflows. That is a possible direction, not the current primary product shape.

Capabilities

Implemented and actively used

• Multi-repo orchestration - Coordinate workflows across Bodai-owned repositories and services
• MCP server surface - FastMCP-based server exposing orchestration, coordination, and operational tools
• Cross-repository coordination - Track issues, todos, dependencies, and status across the ecosystem
• Repository messaging - Async message passing between repositories for event-driven coordination
• Headless worker orchestration - Execute tasks in parallel using terminal-based and adapter-backed workers
• Goal-driven teams - Create multi-agent teams from natural-language goals
• OpenTelemetry ingestion and search - Ingest traces and search them semantically
• Role-based organization and routing - Classify repos and route work by role and task type

Implemented but uneven in maturity

• Multi-pool execution - Local and delegated pools are real; some cloud-oriented paths are less mature than the core local control plane
• Multiple orchestration adapters - Prefect, Agno, and LlamaIndex integrations exist, but operator maturity varies by workflow and deployment context
• Observability and monitoring - Present across metrics, health, and WebSocket surfaces, but some surrounding docs and dashboards are still catching up
• Durable operational state - Dhara owns restart/recovery checkpoints for workflows, pools, routing decisions, and approvals; Session-Buddy remains the session-local context store

Experimental or planned edges

• Broader cloud pool execution - Treat specialized cloud/GPU paths as experimental unless validated for the target workflow
• Autonomous skill synthesis / self-improvement loops - Supporting pieces exist, but fully autonomous self-modification is not the current operating model

Orchestrator Landscape

This is the short version of where each system fits. It is not a scorecard.

Legend: