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

One‑sentence positioning: Agents are colleagues, not tools

Most AI applications expose a simple chat box, treating the LLM as a tool. Multica takes a different approach: it manages agents as if they were coworkers, providing workstations, status, load, assignable tasks, reporting, skill accumulation, and failure review.

Workstation (machine where it runs)

Status (online/busy/offline)

Load (how many tasks it handles concurrently)

Assignable (like Jira, assign issues)

Reporting (real‑time progress feedback)

Skill retention (store useful prompts as team assets)

Failure review (root‑cause + automatic retry)

The "colleague" design lets a 2‑person team handle 10+ agents, achieving output comparable to a 20‑person engineering team.

Skeleton One: Four‑layer architecture, one codebase for three platforms

Multica is a Turborepo monorepo with strict one‑directional dependencies across four layers, making module boundaries clear.

ui ← core : UI package has zero business dependencies and does not import any @multica/* modules, allowing atomic components to be tested independently.

core ← react‑dom : Core avoids localStorage and process.env; platform side‑effects are abstracted behind platform/ interfaces for reuse across web, desktop, and future mobile.

views → core : Views combine UI atoms with core hooks, separating business views from presentation components.

web/desktop → views : Both web and desktop shells share the same views and core, enabling a single codebase to run on two shells.

Because the lowest core layer has no platform APIs, all side‑effects are injected via platform/, allowing the same domain logic to run on Next.js, Electron, or mobile.

Skeleton Two: Two parallel data streams – one for reads, one for writes

Typical admin data flow is single‑directional (request → data → render), which does not suit agents that change state every second. Multica uses two parallel streams:

Main line one: Server state (TanStack Query)

All data fetched from the backend goes through TanStack Query with an aggressive configuration:

// packages/core/src/data/use-query.ts
staleTime: Infinity, // cache never expires automatically

Although the cache never expires, the second stream ensures freshness.

Main line two: Real‑time layer (WebSocket)

Backend state changes are pushed via WebSocket events. The client receives an event and precisely invalidates the related cache, triggering a refetch. The WebSocket never writes directly to the cache.

invalidate, never write. WebSocket only tells Query that a piece of data is dirty; Query then refetches from the API, guaranteeing a single source of truth.

This design makes the UI appear to poll while actually performing zero polling – task progress bars, board status, and usage statistics update in real time without any polling requests.

Four core modules that enable the "AI colleague" experience

Issues board – the Jira‑like task board where each issue follows a full lifecycle (open → assigned → in_progress → review → done). Assignees can be humans or agents, and the board mixes them without distinction.

Agents realtime panel – shows each agent's presence (online/busy/idle/offline), current task snapshot, and workload sparkline, helping decide who to assign new work to.

Dashboard usage statistics – aggregates workspace‑level token usage, execution time, model‑wise cost, and per‑agent output, turning AI colleagues into measurable assets.

Skills system – stores reusable prompts as "skills" that can be bound to multiple agents, turning individual expertise into team assets.

Backend: Go layered architecture and event bus

The backend follows a standard Go layered design with two noteworthy points:

sqlc‑generated type‑safe DB layer : SQL statements generate Go structs and query functions, eliminating runtime reflection and ensuring front‑end TypeScript types match back‑end structs.

realtime package as a cross‑cutting concern : It provides a shared event bus (Hub) used by all modules. When an issue changes, an agent comes online, or a task fails, the same hub broadcasts an event, and the front‑end decides which cache to invalidate.

Series roadmap

This article serves as a map. Future parts will dive deeper into each data stream and module:

Part 2 – React Query × Zustand: dissecting the "no‑polling yet realtime" cache strategy.

Part 3 – WebSocket realtime architecture: full chain from Go Hub to front‑end invalidation.

Part 4 – Four‑package contracts: how core/ui/views/app share code across three platforms.

Part 5 – Agents as first‑class citizens: polymorphic dispatch and daemon runtime.

Each part follows the same structure: pose a problem, provide a mental model, unpack the implementation, and highlight counter‑intuitive details.