Deep Dive: How Multica, an Open-Source Managed Agents Platform, Turns AI Agents into Real Teammates

Multica — The Open-Source Managed Agents Platform

• Repository: github.com/multica-ai/multica
• Author: Forrest Chang (Jiayuan Zhang)
• License: Apache 2.0
• Positioning: Task management like Linear, but agents are first-class citizens

The project's README opens with a bold declaration: "Your next 10 hires won't be human." Multica's core idea is to turn coding agents—Claude Code, Codex, OpenClaw, Cursor Agent—into real teammates that can take tasks, write code, open PRs, comment, and update status. The author read through the core codebase (a Go backend of roughly 30,000+ lines plus a frontend monorepo) and breaks down its architecture below.

Key points

Architecture: four separated layers

• Frontend: Next.js (App Router) + pnpm monorepo for the task board, agent management, and real-time status
• Backend: Go (Chi router, sqlc, gorilla/websocket) handling API, permissions, event bus, and task scheduling
• Database: PostgreSQL with pgvector for persistence and multi-tenant isolation
• Daemon: a local process that executes agent CLIs on the user's machine

The key decision is "agents run locally, management lives in the cloud." This yields two benefits: (1) security—code and API keys never pass through Multica's servers; (2) flexibility—any agent CLI is supported, with no vendor lock-in.

Backend design

• One interface, ten implementations: server/pkg/agent/ defines a unified execution interface (Backend.Execute), implemented for Claude Code, OpenAI Codex, Cursor Agent, OpenClaw, OpenCode, Gemini CLI, Hermes, Kimi, Pi, and GitHub Copilot. Each agent's quirks are encapsulated in its own Backend; Multica itself is only a dispatcher—like a taxi dispatch center that doesn't drive but assigns and tracks rides.
• Daemon as a sandbox: The daemon receives task:dispatch events over WebSocket, creates an isolated execution environment per task (execenv with workdir, output, and logs directories), runs the agent CLI, and streams output back. Design principle: isolation over shared state—each task starts clean, avoiding ghost bugs from leftover state.
• Synchronous event bus: An in-process pub/sub (events.Bus) covers the full lifecycle: issue:*, task:dispatch/progress/completed/failed, agent:*, autopilot:*, and chat:*. Handlers publish events rather than calling services directly, keeping the system loosely coupled.
• Autopilot: A declarative automation engine supporting cron-style schedules and triggers, in two modes: create_issue (dispatch an agent to resolve it) or direct_task. Autopilot-created issues follow the same lifecycle as manual ones.
• Skill system: Cloud skills (managed via API, importable from ClawHub and skills.sh) plus local skill discovery (e.g., ~/.claude/skills/). The daemon injects skill files into each task's environment, using provider-specific paths—skills act as reusable, standardized "experience" for agents.

Frontend design

• Strict package boundaries in the monorepo: core/ (business logic, platform-agnostic—no react-dom, localStorage, or process.env), ui/ (atomic components, zero business logic), views/ (no next/* or react-router-dom; routing goes through a NavigationAdapter). Shared packages export raw .ts/.tsx for zero-config HMR.
• Dual-track state: React Query owns all server state; Zustand owns client state (workspace selection, filters, modals). WebSocket events only invalidate React Query caches—they never write to Zustand directly. On reconnect, all caches are fully invalidated to recover from missed events.

The cleverest decisions

• Polymorphic assignees: Issues are assigned via assignee_type + assignee_id, so humans and agents are fully equal in the task system—either (or both) can own an issue, and agent-created issues use the same state machine. Agents get their own avatars, concurrency limits, and skill configs.
• Preventing agent-to-agent loops: When a task was triggered by another agent, the prompt explicitly instructs the agent to stay silent if the other comment was just an acknowledgment, and never to @mention the other agent as a sign-off—preventing infinite reply loops at the prompt layer rather than with brittle reply-count limits.
• Session resume: If a long-running task fails mid-way, the daemon retries with ResumeSessionID to continue from the last checkpoint, falling back to a fresh session if resume fails.
• Multi-tenancy as an architectural constraint: Every query filters by workspace_id, routed via an X-Workspace-ID header; WebSocket connections are workspace-scoped.

Technology choices

Go over Node/Python (high-performance WebSocket and process management), sqlc over ORMs (type-safe SQL, zero runtime overhead), Chi over Gin/Echo (lightweight, stdlib-compatible), React Query + Zustand over Redux, pnpm + Turborepo over Nx/Lerna. No microservices, no GraphQL, no gRPC—a deliberately "just enough" stack.

Comparison with similar projects

| Dimension | Multica | Paperclip | Vibe Kanban | Claude Code Dispatch | |---|---|---|---|---| | Open source | ✅ Apache 2.0 | ❌ | ❌ | ❌ (Anthropic) | | Agent variety | 10+ | Limited | Claude only | Claude only | | Local execution | ✅ Daemon | ❌ Cloud | ❌ Cloud | ❌ Cloud | | Skill system | ✅ Cloud + local | ❌ | ❌ | ❌ | | Autopilot | ✅ Scheduled + triggered | Partial | ❌ | ❌ | | Human–agent parity | ✅ First-class | Partial | ❌ | ❌ |

Multica is reportedly the only project combining open source, multi-agent support, local execution, and a Skill system.

Bottom line

Multica is not building an "AI tool" but an "AI employee management system": the Backend interface lets any CLI agent plug in, the Daemon keeps code on the user's machine, the event bus keeps the system decoupled, Skills make agent knowledge reusable, and polymorphic assignment makes humans and agents truly equal. It is deliberate infrastructure for AI-native teams.

📎 GitHub: multica-ai/multica 📎 Website: multica.ai 📎 Author: forrestchang