AGNOHive

A generic, model-agnostic agentic swarm built on Agno. Runs on a dedicated ZGX workstation, connects to any project via MCP, and coordinates a full engineering team of local Ollama-backed agents — no cloud API calls.

How It Works

Client machine                           ZGX (AGNOHive)
──────────────                           ──────────────────────────────────────
hive-mcp  ◄─────────────────────────────  ContextRouter
  apply_diff                              Researcher
  write_file                              Planner
  run_shell                               Coder          ──► Qdrant (vectors)
  run_docker                              Executor       ──► PostgreSQL/AGE (graph)
  git_*                                   Reviewer       ──► SigNoz (OTel)
  index_project
  scan_project_context → hive.md
  web_search / web_fetch                ──────────────────────────────────────
                                           Coordinator (qwen3-coder:30b)
project MCP  ◄───────────────────────────  orchestrates all agents
  get_file_content
  find_files
  search_files
  memory_search
  (app-specific tools)

Two MCP connections per run (dual-MCP):

• hive-mcp (primary) — all file reads + writes + shell + Docker + git + ripgrep + web. Used for everything by default.
• Project MCP (supplementary) — project-specific tools not in hive-mcp: memory_search, get_context_section, app workflows. Optional — hive works without it.

Graceful fallback: if hive-mcp is unreachable, agents automatically fall back to project MCP for reads. If both are down, the run fails with a clear error. If only one MCP is provided, it handles everything.

1. Coordinator's first action is get_file_content('hive.md') — grounded project context loaded on demand, not pre-injected (prevents models from answering without tool calls)
2. Failure context from past runs is injected into the coordinator's instructions
3. The coordinator routes operations to the right MCP — member agents see only their scoped tool subset
4. After each run, successes go to LightRAG (vector memory) and failures go to PostgreSQL (failure log)
5. OTel traces flow to SigNoz

---

Prerequisites

ZGX Workstation

• Ubuntu / Linux with Python 3.12+
• Miniforge or standard venv
• Ollama running natively (for GPU access)
• Docker + Docker Compose (for Qdrant and PostgreSQL/AGE)
• Tailscale

Ollama Models (pull before first run)

ollama pull qwen3-coder:30b        # engineering Coordinator — non-thinking A3B MoE
ollama pull qwen2.5-coder:32b      # Researcher + Planner + Coder + Reviewer
ollama pull qwen2.5-coder:7b       # planning/parallel-review coordinator + LightRAG extraction
ollama pull llama3.1:8b            # ContextRouter + Executor + session compaction
ollama pull qwen3-embedding:0.6b   # LightRAG embeddings (1024-dim)

All agents run local Ollama models. Set any model via env var (e.g. CODER_MODEL=qwen2.5-coder:32b) or in teams/*.yaml.

Active roster (2026-06-12): 5 models, ~47 GB resident. ibm/granite4.1:30b and qwen3:30b-a3b were deleted (35 GB freed) — re-pull granite only if a coordinator rollback is needed.

ARM64 GB10 model compatibility:

• qwen3-coder:30b — ✅ Current engineering coordinator. Non-thinking A3B MoE. Same-task A/B (full pipeline): 84s grounded (read every service) vs granite4.1:30b 217s (hallucinated purposes from dir names) vs qwen3:30b-a3b thinking 318s. ~2.6× faster than granite with better grounding.
• qwen2.5-coder:32b — ✅ Researcher/Planner/Coder/Reviewer. Reliable tool use. (Was unusable as coordinator on Ollama 0.24 — CUDA crash after ~14 min — but that was the old build; untested as coordinator since 0.30.6.)
• qwen2.5-coder:7b — ✅ planning + parallel-review coordinator, and LightRAG extraction (better code entities than llama3.1:8b; ~30% slower but worth it).
• llama3.1:8b — ✅ ContextRouter + Executor + session compactio