DEV Community

Cover image for Building an AI Agent Orchestrator: How 6 Specialized Agents Coordinate Through GitHub
Aleksandr Primak
Aleksandr Primak

Posted on

Building an AI Agent Orchestrator: How 6 Specialized Agents Coordinate Through GitHub

#ai #github #devnexus #agents

A technical deep-dive into multi-agent coordination patterns

The Problem: Solo Founders Wear Too Many Hats

If you have ever built software alone, you know the struggle. One minute you are deep in code, the next you are triaging issues, then writing docs, then responding to support requests, then trying to remember what you were coding.

Context switching is the productivity killer nobody talks about enough.

I started building Operum after a particularly brutal week where I shipped zero features despite working 60+ hours. All my time went to coordination overhead - the glue work that keeps projects moving but does not directly produce value.

The idea was simple: what if AI agents could handle the coordination, and I could focus on the creative work?

(I am writing this from DevNexus in Atlanta, where conversations about AI-assisted development are everywhere. If you are here too, I would love to connect.)

Why 6 Specialized Agents Instead of One General Agent

The first version of Operum used a single agent that tried to do everything. It was... not great.

Here is what I learned: specialized agents with focused context significantly outperform generalist agents.

Think about it like a real team:

  • A PM who understands the full project context and can coordinate
  • An architect who knows the codebase patterns and can guide decisions
  • An engineer who can write clean, consistent code
  • A QA engineer who knows what to test and how
  • A marketer who understands your audience
  • A community manager who knows your users

Each role requires different knowledge, different prompts, and different tools. Cramming all of that into one agent creates conflicts and confusion.

The Six Agents

Agent Role Primary Responsibility
PM Orchestrator Triages issues, coordinates workflow, manages pipeline
Architect Technical Advisor Reviews feasibility, provides architectural guidance
Engineer Builder Writes code, creates pull requests
Tester Validator Tests changes, catches bugs, approves for review
Marketing Growth Content creation, SEO, launch strategy
Community Support Discord/Twitter monitoring, user assistance

The Coordination Challenge

Multi-agent systems have a fundamental problem: how do agents hand off work without stepping on each other?

I tried several approaches:

Attempt 1: Direct Agent-to-Agent Communication

Agents talked to each other directly. Chaos ensued. Agent A would ask Agent B something while Agent B was asking Agent A something else. Deadlocks everywhere.

Attempt 2: Shared Memory

All agents read/wrote to a shared context. Better, but still problematic. Race conditions. Conflicting writes. Agents overwriting each other's work.

Attempt 3: Pipeline with Clear Handoffs (Winner)

The solution that worked: a linear pipeline where each agent has clear ownership of a stage.

backlog --> needs-architecture --> ready-for-dev --> in-progress --> needs-testing --> needs-review --> done
Enter fullscreen mode Exit fullscreen mode

Each stage is a GitHub label. Only one agent owns each stage. When an agent finishes, they update the label, which signals the next agent.

No direct communication needed. GitHub is the source of truth.

GitHub as the Coordination Layer

Using GitHub for coordination was not the original plan - it emerged from necessity.

Initially, I built a custom coordination layer. It worked, but users could not see what was happening. Trust requires transparency.

GitHub solved multiple problems at once:

  1. Visibility - Every agent action shows up as a comment or commit
  2. Auditability - Full history of who did what and when
  3. Familiarity - Users already know how to read issues and PRs
  4. Integration - Works with existing workflows and tools

How It Works in Practice

  1. You create a GitHub issue describing what you want
  2. PM agent sees the new issue, triages it, adds the needs-architecture label
  3. Architect agent picks up issues with that label, adds technical guidance as a comment, changes label to ready-for-dev
  4. Engineer agent picks up, creates a branch, writes code, opens a PR, changes label to needs-testing
  5. Tester agent checks out the PR, runs tests, adds results as a comment, changes label to needs-review
  6. You review the PR and merge

Every step is visible. Every decision is documented.

Technical Implementation

Desktop Architecture (Tauri)

I chose Tauri over Electron for several reasons:

  • Rust backend - Performance and memory safety
  • Smaller bundle size - ~10MB vs ~150MB for Electron
  • Native webview - Uses system webview instead of bundling Chromium
  • Security - Rust's memory safety guarantees 
Operum Desktop App
|
|-- Rust Backend
|   |-- Agent Process Manager (spawns/monitors agent processes)
|   |-- State Store (SQLite with WAL mode)
|   |-- IPC Handler (file-based triggers)
|   +-- GitHub Client (REST API integration)
|
+-- SvelteKit Frontend
    |-- Dashboard (real-time agent status)
    |-- Issue Pipeline View
    +-- Settings/Configuration
Enter fullscreen mode Exit fullscreen mode

Inter-Process Communication

Agents run as separate processes. They communicate through file-based IPC:

Trigger files: triggers/{agent}.trigger - Contains task assignments

Response files: responses/{agent}.response - Contains task results

Why files instead of sockets or message queues?

  1. Debuggability - You can cat a file to see what is happening
  2. Simplicity - No connection management, no serialization libraries
  3. Crash recovery - Files survive process crashes
  4. Atomicity - File writes are atomic on most systems

State Management

SQLite with WAL (Write-Ahead Logging) mode provides:

  • Concurrent reads - Multiple agents can read simultaneously
  • Crash recovery - WAL survives unexpected shutdowns
  • Single file - Easy backup and restore
  • Fast writes - WAL batches writes efficiently

Agent Response Protocol

Agents report results using a structured format:

DONE: Implemented user authentication feature
ISSUE: #142
LABEL-UPDATED: in-progress --> needs-testing
PR: #143
Enter fullscreen mode Exit fullscreen mode

Prefixes make parsing easy:

  • DONE: - Task completed successfully
  • REQUEST: - Needs human input or decision
  • ERROR: - Something went wrong

Lessons Learned

1. Agents Need Guardrails

Unconstrained agents do unpredictable things. Every agent needs:

  • A clear scope (what they can and cannot do)
  • Defined outputs (what format to respond in)
  • Explicit limitations (what to escalate vs handle)

2. Transparency Builds Trust

When users cannot see what agents are doing, they do not trust the output. Every action should be logged somewhere visible.

3. Human-in-the-Loop is Non-Negotiable

Agents propose. Humans approve. The final merge button stays with the human. This is not just about trust - it is about accountability.

4. Specialization Beats Generalization

Six focused agents outperform one general agent. Narrower context windows lead to more consistent behavior.

5. Local-First Simplifies Everything

Running locally means:

  • No security debates about where code goes
  • No latency from network round-trips
  • No usage-based pricing anxiety
  • Full user control

What's Next

Operum is currently in public beta. The core orchestration works, but there is more to build:

  • Multi-provider support - Currently Claude-powered, adding support for more LLM providers
  • More agent types - Security review agents, analytics agents, etc.
  • Custom agent creation - Let users define their own agent roles and workflows
  • Better state visualization - Richer pipeline UI with real-time updates
  • Team templates - Pre-configured agent teams for common project types

Try Operum

Operum is free during public beta. If you are a solo founder or small team drowning in coordination overhead, give it a try:

Download the desktop app, connect your GitHub repo, and let six AI agents handle the coordination work while you focus on building.

I would love to hear what you think — drop by the Discord or open an issue on GitHub.

Built by a solo founder who got tired of context switching and decided to automate it away.

Top comments (0)