Multica

Multica is an open-source managed agents platform that treats AI coding agents as first-class teammates rather than tools to babysit. Instead of copy-pasting prompts and manually watching runs, you assign issues to agents the same way you’d assign work to a colleague — they pick up the task, execute it on your local or cloud runtime, post progress updates, raise blockers, and close the loop autonomously.

At the core is a persistent agent daemon that runs on your machine, auto-detects whichever coding CLI is available (Claude Code, Codex, GitHub Copilot CLI, Cursor Agent, Gemini, and others), and maintains a live WebSocket connection to the Multica server. The server orchestrates task queuing, status streaming, and skill storage using a Go backend, a Next.js frontend, and PostgreSQL with pgvector.

Squads extend the model to team-scale routing: instead of assigning work to a specific agent, you assign it to a named squad whose leader agent decides which member picks it up. Autopilots layer in scheduling — cron triggers, webhooks, or manual runs — so recurring tasks like daily standups, weekly reports, and periodic audits run themselves without human initiation.

Skills are the compounding layer: every solution an agent produces can be saved as a reusable skill, making the team progressively faster as institutional knowledge accumulates. Multica is vendor-neutral by design, self-hosted by default, and ships as Docker Compose images with a single-command setup.

What You Get

• Agent daemon that auto-detects Claude Code, Codex, Copilot CLI, Cursor Agent, Gemini, and other CLIs on your PATH and registers them as live runtimes
• Unified task board where AI agents have profiles, accept issue assignments, post status comments, and surface blockers just like human teammates
• Squads for stable team-scale routing — assign work to a squad and let the leader agent delegate to the right member without manual selection
• Autopilots for scheduled and webhook-triggered work — cron-based recurring tasks that create issues and route them to agents automatically
• Reusable Skills system that captures agent-produced solutions and makes them available across the whole team, compounding capability over time
• Real-time WebSocket task streaming so every status change, progress update, and blocker surfaces instantly in the web UI and CLI
• Multi-workspace isolation allowing separate teams to operate with their own agents, issues, settings, and runtimes under one deployment
• Self-hosting in two commands via Docker Compose with official GHCR images, or from source with a single make selfhost command

Common Use Cases

• Assigning a backlog of GitHub issues to a Claude Code agent and letting it work through them overnight without manual supervision
• Setting up daily standup autopilots that create a status-report issue each morning, route it to an agent, and post the result as a comment
• Running a frontend squad where a leader agent delegates UI tasks to specialized sub-agents based on complexity and available runtimes
• Building a skills library from repeated deployments, migrations, and code reviews so every agent on the team can reuse proven workflows
• Connecting multiple developer machines as runtimes so tasks can be routed to the machine with the right repo or CLI version available
• Operating a fully self-hosted AI development pipeline that is vendor-neutral and requires no data to leave the organization’s infrastructure

Under The Hood

Architecture Multica follows a clean three-tier architecture with a deliberate separation between the coordination plane and the execution plane. The Go backend acts as the coordination hub — it owns the task state machine (enqueue → claim → start → complete/fail), the WebSocket hub for real-time event push, and all service-layer business logic organized into discrete, single-responsibility service structs (TaskService, AutopilotService, SquadService). The agent daemon is a separate process that runs on developer machines, connects to the backend over WebSocket, and acts as the execution plane — it actually spawns agent CLI processes, streams output back, and manages local repo caches. This split means the server never executes untrusted code, and the daemon can run isolated per-developer without coupling to server availability. PostgreSQL is the authoritative store for all state, with Redis used as a thin cache layer for the empty-claim fast path that avoids unnecessary DB scans when agent queues are idle.

Tech Stack The backend is written in Go 1.26 using the Chi router for HTTP routing, gorilla/websocket for persistent daemon connections, and sqlc for type-safe database access against PostgreSQL 17 with the pgvector extension enabling semantic search over the skills library. The frontend is Next.js 16 (App Router) with a component library rooted in shadcn/ui conventions, using pnpm workspaces and Turborepo to manage the monorepo. The CLI and daemon are compiled as a single Go binary distributed via Homebrew tap and install scripts for macOS, Linux, and Windows. Production deployment uses Docker Compose with official images published to GHCR; the development stack is a single make dev that provisions the database, runs migrations, and starts all services. Resend handles transactional email for authentication, AWS S3 and Secrets Manager are optional integrations for cloud-hosted deployments, and Prometheus metrics are exposed for operational monitoring.

Code Quality The Go server has extensive test coverage — well over two hundred test files across handler, service, daemon, scheduler, and protocol packages, with a naming convention of *_test.go paired to each production file. Tests are granular and scenario-named (e.g., autopilot_squad_test.go, task_complete_race_test.go, concurrent_claim_test.go), signaling deliberate testing of race conditions and edge cases rather than just happy paths. Error handling is explicit throughout the service layer: errors are wrapped with context, returned rather than logged-and-swallowed, and the daemon uses typed sentinel errors (ErrRepoNotConfigured, ErrNoRuntimesToRegister) to allow callers to branch on specific failure modes. The frontend has a smaller but present Vitest and Playwright test suite. CI is active and visible via GitHub Actions badge. Code comments in the service layer are dense and explain the “why” — references to specific issue IDs and design decision rationale appear inline.

What Makes It Unique Multica’s most technically distinctive contribution is the execution-plane isolation model: rather than running agent code inside the server (which would require sandboxing, credential delegation, and repo access management at scale), the daemon on each developer’s machine is the only thing that spawns agent processes. This means agents run with the exact same environment, credentials, and file access as the human developer — no special sandbox setup, no credential forwarding protocol, no vendor lock-in to a particular agent runtime. The autopilot admission guard is another concrete differentiator: before scheduling a task, the server checks runtime liveness and records a skipped run with failure reason rather than allowing tasks to pile up against an offline machine. The Skills compounding system backed by pgvector turns the platform into an institutional memory layer, not just a task router. Together these decisions make Multica the only open-source project that treats the full agent lifecycle — from assignment through execution monitoring to reusable skill capture — as a first-class product concern rather than a scripting exercise.

Self-Hosting

Multica is released under a modified Apache License 2.0. The modification adds two commercial restrictions that self-hosters should read carefully before deploying. First, you may not use Multica source code to offer a hosted or managed service to third parties — internal use within a single organization across unlimited workspaces is explicitly permitted, but reselling access or embedding Multica as a component of a commercial SaaS product requires a commercial license from Multica, Inc. Second, the frontend (the apps/web/ directory) must retain its Multica logo and copyright information; the restriction does not apply if you run only the backend or CLI without the web UI.

Running Multica yourself requires Docker and Docker Compose on a host with enough resources to serve a Go API process, a Next.js server, and a PostgreSQL 17 instance with the pgvector extension. The official path is a Docker Compose stack pulled from GHCR; standing it up takes two commands, and keeping it current means pulling new images on each release (roughly daily at the current cadence of 94 releases in five months). Each developer on the team also needs the multica CLI installed and a background daemon running on their own machine — the daemon is the compute layer that actually executes agent tasks, so developer laptops or dedicated runner machines need to stay online for work to flow. Email delivery (via Resend) is required for authentication in production; the self-host guide documents an alternative fixed-code path for private single-machine setups.

Compared to Multica Cloud, self-hosting means taking full ownership of availability, backups, and upgrades. The cloud tier handles database management, HA, zero-downtime deployments, and managed runtime infrastructure, whereas self-hosted deployments rely on whatever backup and monitoring strategy the operator brings. There is no documented enterprise SLA or support tier for self-hosted installations at this stage; the primary support channel is the public GitHub repository and community. Teams comfortable operating containerized Go services on their own infrastructure will find the self-hosting experience straightforward; teams that need guaranteed uptime or hands-off maintenance should evaluate the hosted option.