DEV Community: Fahim

Multiharness: Orchestrating Autonomous Multi-Agent Workflows Across Open-Source Coding Harnesses

Fahim — Tue, 13 Oct 2026 08:34:01 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Most developer setups force engineers to choose a single coding assistant harness or manually copy-paste context between different agentic environments.

Multiharness solves this fragmentation. It is an open-source multi-agent orchestration framework written in Go designed to delegate tasks, manage iterative review loops, and coordinate coding sessions seamlessly across environments like Codex, OpenCode, and local LLM backends.

The Problem: Single-agent harnesses often get stuck in local optima, struggle with verification loops without consuming massive context windows, and create lock-in around closed ecosystems.
Who It’s For & Why They'd Pay: Engineering teams, technical founders, and freelance developers looking to automate complex refactoring, test-generation pipelines, and cross-model code review loops without being tied to a single proprietary vendor or incurring massive API markups.

Demo

Documentation & Overview: multiharness.mdfahimhossen.space
CLI in Action: Run delegator and reviewer agents side-by-side with automatic state syncing across sessions.

Code

Multiharness is fully open-source. Explore the architecture, inspect agent harnesses, or contribute:

ErOr-0 / Multiharness-Core

Multiharness-Core is a central orchestration framework driven by an agentic workflow.Codex acts as the lead Planner to design architecture and delegate tasks, while Opencode serves as the Executor to implement the codebase according to Codex's blueprints.

Multiharness Core

magent coordinates coding tasks across Codex, Claude Code and Muse Code. Choose a folder and one agent. In direct mode (the default), Multiharness passes your task to that CLI, lets it handle planning/editing/testing, and shows its final response. Follow-ups reuse the same agent session; /new starts fresh.

Use /set mode team (or --mode team) when you want separate planning implementation, deterministic validation, review and bounded repair. The team workflow also owns folder snapshots and independent change evidence.

Both modes support folders without Git.

Muse Code (Meta subscription)

Select muse independently for planner, implementer or reviewer in /config. Each role has its own model and reasoning setting. For an all-Muse team:

/set mode team
/set planner-harness muse
/set planner-reasoning low
/set implementer-harness muse
/set implementer-reasoning medium
/set reviewer-harness muse
/set reviewer-reasoning high
/login muse

The default model is muse-spark-1.3. Use each role's *-model setting to…

View on GitHub

How I Built It

Multiharness is built with performance and composability at its core:

Engineered in Go: Selected for low-latency concurrency, deterministic process management, and native cross-platform binaries with zero external runtime dependencies.
Open-Source AI & Local Inference: Multiharness supports self-hosted open-weight models (via vLLM and Ollama) alongside open harnesses like OpenCode. It routes architecture, implementation, and test-review roles across specialized models depending on context window and reasoning requirements.
Delegation & Review Loops: Uses structured task state machines where lead agents break down feature requests into atomic diffs, dispatch them to worker agents, and trigger automatic linting and test validation stages before merge proposals.

Why Does Open Innovation Matter?

Open innovation is critical when building developer tooling:

Avoiding Vendor Lock-In: Developers should not be trapped within a single closed harness API that changes pricing, rate limits, or deprecates models overnight.
Context Privacy & Local Execution: Engineering teams often handle sensitive codebases that cannot leave internal infrastructure. Open-weight models and open agent harnesses allow Multiharness to execute entirely on-prem or on developer workstations.
True Modularity: Open architectures let developers plug in customized prompt templates, custom evaluation harnesses, and distinct model weights tailored for specific languages and domain logic.

Prize Categories

Hacktoberfest Open-Source AI Challenge: Week 2 Side Hustle

Closiq Discord Agent: An AI Customer Support Monolith 🚀

Fahim — Thu, 28 May 2026 01:08:53 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I built the Closiq Discord Agent, a full-stack modular monolith engineered to transform a Discord channel into an automated, AI-driven customer support inbox and lead management system.

When a customer messages your Discord support channel, the backend captures the conversation, handles data persistence, and fetches highly relevant context from a self-hosted Qdrant vector database (which indexes knowledge base documents stored in MinIO). It then leverages OpenRouter or OpenAI-compatible models to dynamically draft and deliver accurate, context-aware responses right back to the customer via a Discord bot.

Demo

GitHub Repository: ErOr-0/closiq-discord-bot
Local Web Dashboard: http://localhost:5173

(Tip: Insert a GIF or a couple of screenshots here showing off your React dashboard interface, your MongoDB message log view, or the Discord bot replying live in a channel!)

Tech Stack At A Glance

Frontend: React + Vite

Backend: Node.js + Express + TypeScript

Databases & Storage: MongoDB (Metadata), Qdrant (Vector Embeddings), and MinIO (Object Storage)

Integrations: discord.js & OpenRouter / OpenAI SDK

The Comeback Story

This project started as an ambitious idea but quickly stalled out. Before dusting it off for this challenge, it was just a loose collection of database models, basic tools, and a primitive, unoptimized LangChain loop sitting in a graveyard of unfinished local folders. It completely lacked a front-end management layer, and the architecture was fragile.

To bring this project to life and cross the finish line, I focused heavily on stability, user experience, and structural boundaries:

Modular Monolith Refactoring: Reorganized the entire Express backend into strict, clean module boundaries (messages, knowledgebase, agent, infrastructure) to make the codebase highly maintainable.
Built the Web Dashboard: Created a comprehensive React interface from scratch so users can visually monitor incoming customer messages and manage knowledge base files without touching terminal commands.
Fixed Edge Cases & UI: Fixed broken message handling logic loops in the AI generation workflow and completely updated the Channel Message UI components for smoother interactions.
Cascading Deletion Sync: Implemented robust file lifecycle management. Now, deleting a knowledge document triggers a clean, sequential purge across the entire stack: removing the object from MinIO, unindexing the vector from Qdrant, and dropping the metadata from MongoDB.

My Experience with GitHub Copilot

GitHub Copilot acted as an invaluable pair-programmer during this sprint, especially when it came to tying multiple disjointed storage microservices together.

Docker Scaffold Speed: Copilot instantly generated the local environment infrastructure configurations inside the docker-compose.yml, getting MongoDB, Qdrant, and MinIO talking to each other effortlessly.
Handling Streams and Upload Boilerplate: Writing multipart file upload endpoints that simultaneously stream files to MinIO and pass text data to vector embeddings involves writing a lot of repetitive error-handling code. Copilot predicted the stream-piping logic accurately, saving me hours of debugging.
Maintaining Architecture Boundaries: Because Copilot quickly grasped the modular monolith layout, it suggested accurate imports across different domain workspaces (like pulling from shared/errors or config/logging) without muddying up the structural boundaries I put in place.