← Back to cases
Published: Compiled by YuanASIoffline operationprivate deploymentlocal quantized modelsmulti-node orchestrationcontext compactionopen-multi-agent

A fully offline multi-node agent stack

Open-source production adoption · third-party project

This offline agent stack is a third-party open-source project, built and maintained by Mark Galyan (GitHub: apollo-mg) on open-multi-agent. The whole system runs disconnected, inference stays on local quantized models, and OMA is the orchestration core.

Scenario

The open-multi-agent README lists Mark Galyan as a contributor since the framework's first month. His public repository, Project Apollo, calls itself an air-gapped, local-first multi-node swarm architecture.

Per its README and runbook the system has two layers: a coordinator plans and decomposes work, workers claim and execute it. Between them is a SQLite message bus in WAL mode: workers claim tasks atomically with exclusive transactions, tasks carry hardware constraints (minimum context, precision bits), and routing follows each node's reported VRAM and status. The current stable setup is dual-node: a 16GB-VRAM workstation coordinating, a 32GB-VRAM dual-card headless server executing.

The pain points are in his own public issue and PRs: VRAM is a hard boundary and unattended long loops blow through the context window; heavily quantized models emit malformed JSON in multi-turn tool calls and loop.

How it works

RolesTask DAGToolsModelDeployment
Coordinator node (Architect)Goal → decomposition and dependency scheduling; context compaction keeps history within budget across turnsOMA's coordinator and context compaction; delegated tasks go out over the message bus and wait on an SSE callback with a 30-minute safety timeoutLocal quantized model behind an OpenAI-compatible endpointStarted on the workstation from the vendored open-multi-agent engine directory in the repo (npx tsx examples/apollo_cli.ts or apollo_server.ts)
Worker daemonClaims tasks from the SQLite queue and executes locally; anything stuck in progress past 15 minutes is swept back to pendingLocal shell and OS management exposed over MCP behind a tiered permission gateSmaller local models per node (his README puts logging and extraction work at the 8B–14B range)deploy/Dockerfile.worker copies engines/open-multi-agent-upstream/package*.json, runs npm ci, then installs the Python daemon
Resident background loops (his "Daydream Daemon" and codebase investigator)Unattended long multi-turn loops reviewing logs and the codebaseContext compaction is what keeps these loops aliveLocal quantized modelsResident locally, the full stack runs offline

OMA's place is visible in the repository layout: engines/ holds two open-multi-agent engine directories recorded as commit pointers — one is OMA's first release commit from 2026-04-01; deploy/Dockerfile.worker installs that directory's Node dependencies for the worker image; the bootstrap script and runbook start the orchestration layer there.

His three merged PRs to open-multi-agent all came from running offline.

#161 (merged 2026-04-23): the context strategy was only evaluated after the first turn, and compacted history never came back to the caller, so callers kept the uncompacted array. The fix touches src/agent/agent.ts, src/agent/runner.ts and the context-strategy tests: the first-turn gate is gone and every turn is preserved. It follows his issue #152.

#163 (merged 2026-04-25): exposes topP, topK, minP, frequencyPenalty, presencePenalty and extraBody through AgentConfig and RunTeamOptions, wired into the OpenAI and Anthropic adapters. His reason: cloud defaults suffice, but heavily quantized MoE models on consumer hardware fall into repetitive loops in multi-turn tool calls without them.

#269 (merged 2026-06-02): quantized models sometimes emit Python triple quotes or unescaped quotes in tool arguments; JSON.parse then failed and returned an empty object, leaving the model spinning. The PR adds a regex fallback in OpenAI completion parsing, reworked after review to drop the hardcoded tool names, with its own tests.

Result

What he and the public record state:

The open-multi-agent README lists Mark Galyan under "Built with OMA": he "runs OMA fully offline on local quantized models", using the coordinator and context compaction to keep autonomous loops alive under tight VRAM limits, a contributor since the framework's first month.

Three PRs (#161, #163, #269) are merged upstream, across the agent runner, LLM adapters and tests. Two further PRs he closed himself; on one he explained the cause was his own local inference server.

On public issue #152 he states the use: open-multi-agent as the core orchestrator of a local-first system, reproducing a Coordinator → Worker pattern locally.

His repository's acknowledgements credit open-multi-agent (MIT) for the core TypeScript DAG orchestration and baseline agent loops; the engine directories, worker Dockerfile and bootstrap script line up.

Verifiable

SourceLinkVerified on
open-multi-agent README, "Built with OMA" entryhttps://github.com/open-multi-agent/open-multi-agent#built-with-oma
PR #161: context compaction persistence and dropped turnshttps://github.com/open-multi-agent/open-multi-agent/pull/161
PR #163: sampling parameters on AgentConfig / RunTeamOptionshttps://github.com/open-multi-agent/open-multi-agent/pull/163
PR #269: regex fallback for malformed tool-argument JSONhttps://github.com/open-multi-agent/open-multi-agent/pull/269
Issue #152: his bug report and follow-up description of usehttps://github.com/open-multi-agent/open-multi-agent/issues/152
Project Apollo repository and README (architecture, nodes, models)https://github.com/apollo-mg/Project-Apollo
OPERATIONS.md: boot sequence, orchestration layer started from the vendored OMA directoryhttps://github.com/apollo-mg/Project-Apollo/blob/778a7e8/OPERATIONS.md
deploy/Dockerfile.worker: worker image installs OMA dependencieshttps://github.com/apollo-mg/Project-Apollo/blob/778a7e8/deploy/Dockerfile.worker
scripts/bootstrap_swarm.sh: orchestration layer launched from the OMA engine directoryhttps://github.com/apollo-mg/Project-Apollo/blob/778a7e8/scripts/bootstrap_swarm.sh
engines/: two open-multi-agent engine pointershttps://github.com/apollo-mg/Project-Apollo/tree/778a7e8/engines

How this relates to YuanASI

Everything on this page comes from a third-party open-source project's public repository, PRs and issues. YuanASI authors open-multi-agent, and his fixes reached it through public PRs.

If your constraints are the same — data stays on your network, models run on your own GPUs, several agents divide the work — YuanASI covers private deployment and on-premises models under Multi-Agent System Integration

Last updated

Want to know how a workflow like this would land on your side?