How Multica Turns 2 People and 10 Agents into the Output of a 20‑Person Team

This article is the first in the Multica dissection series. The author examined the entire codebase—Go backend, Next.js frontend, and 13 AI‑coding‑tool adapters—drawn a diagram and provided commentary.

Agents as colleagues, not tools

Unlike typical AI applications that expose a single chat box, Multica treats each Agent as a coworker. A colleague has a workstation (machine location), status (online/busy/offline), and load (concurrent tasks). Agents can be assigned work like Jira issues, report progress in real time, and accumulate reusable prompts as team assets. When failures occur they can be post‑mortem analysed and automatically retried.

This "colleague" design lets a 2‑person squad manage 10+ agents, achieving output comparable to a 20‑person engineering team. The name Multica combines “Multiplexed Information and Computing Agent” and pays homage to the 1960s Multics operating system.

Core design choice: agents run on the user’s machine

The Multica server (written in Go) only stores workspaces, issues, and task queues; it never executes any Agent task. A daemon process runs on each user’s machine, polls the server every 3 seconds, sends a heartbeat every 15 seconds, and invokes the local AI tool to perform the work.

Counter‑intuitive: clicking “Assign to Claude Code” in the web UI actually runs the code on your own MacBook, not in the cloud.

Because the execution environment stays local, API keys, code directories, and authorized tools never leave the user’s machine, unlike typical SaaS AI services.

Frontend: four‑layer monorepo shared by web and desktop

The frontend lives in a Turborepo monorepo with strict one‑way dependencies across four layers. Web (Next.js) and desktop (Electron) share the same business logic.

ui ← core : UI packages have no @multica/* dependencies, allowing atomic component testing.

core ← react‑dom : Core avoids localStorage and process.env, abstracting platform side‑effects via a platform/ interface.

views → core : Views compose UI atoms and import core hooks, keeping presentation separate from business logic.

web/desktop → views : Both shells reuse the same views and core, enabling one codebase for two platforms.

Note: the mobile (Expo) version is a separate React build that only shares core types and pure functions, not UI or state.

Two parallel data streams: read vs. write

Standard admin panels use a single request‑response flow, but Agent‑driven workflows need real‑time updates. Multica implements:

Read stream – TanStack Query

// packages/core query client
staleTime: Infinity, // cache never expires automatically

Setting Infinity prevents automatic cache eviction; freshness is controlled by the write stream.

Write stream – WebSocket

The server pushes events (e.g., task:queued, task:dispatch, task:running, task:completed) defined in server/pkg/protocol/events.go. The client receives an event, invalidates the related cache, and triggers a refetch.

invalidate, never write。 WebSocket never mutates cached data directly; it only marks it dirty so the query layer reloads it from the API, avoiding cache conflicts.

This makes the UI appear to poll while actually performing zero polling – progress bars, board status, and usage numbers update instantly without any polling requests.

Four core modules that deliver the "AI colleague" experience

Issues board – an agent‑aware Jira where assignee can be a person or an Agent; supports board, list, Gantt, and swimlane views.

Agents panel – shows each Agent’s presence (online/busy/idle/offline), current task snapshot, and workload sparkline.

Dashboard – aggregates token usage, execution time, model‑wise cost, and per‑Agent output, enabling quantitative ROI decisions.

Skills system – stores reusable prompts (e.g., "run tests before refactoring React components") as team‑wide assets linked to multiple Agents.

Backend: Go layering and event bus

The backend follows a conventional Go layered architecture. Two noteworthy aspects:

sqlc‑generated type‑safe DB layer : SQL files generate Go structs and query functions, eliminating runtime reflection and keeping TypeScript types in sync with Go structs.

Realtime package as a cross‑cutting concern : Provides a unified event bus used by all modules. Events flow through server/internal/realtime/ and are sharded via Redis relays ( redis_relay.go and sharded_stream_relay.go) for horizontal scalability.

The next article will explore how the daemon discovers the user’s machine, handles offline Agents, and manages task failures.

Core module quick reference

★ Issues board : Agent task assignment and lifecycle.

★ Agents panel : Online status + workload.

★ Dashboard : Token/cost/time aggregation.

★ Skills : Reusable prompt assets.

Runtimes: daemon × tool combo.

Realtime: event bus + Redis sharding.

Autopilot: cron/webhook time‑driven triggers.

TaskFailure: failure attribution + auto‑retry.