multica-ops

Designed and built by Jamil Lazarev.

Mops 🐶 — your Executive Advisor for Multica. One skill that builds and runs an autonomous company of AI agents: it interviews you progressively (small tasks stay small), stands up the workspace-as-company via the CLI — conductor/PM, squads, skills, integrations — optionally stands up a resident Mops inside Multica, and stays your console: status, recovery after limits, features, roadmap, hiring.

New here? Getting started takes you from nothing to a running team in a few minutes. This page is the why and the mental model behind it.

Two seats of Mops

Mops is one advisor with one name, reachable in two places:

• Mops in CLI — where you build. Full machine reach (shell, git, multica CLI, deploy), instant chat, its own quota. Best for the heavy work: bootstrap, hire, integrate, ops.
• Mops in Multica — an optional resident agent carrying this same skill, present in the workspace when you're away from the console. Async, shares the team's session limit; best for status, @Mops advice in an issue, and being the escalation vertex.

They don't share live chat memory, and you can't write into an agent's chat. The bridge is written state — the repo and issue comments — so bootstrap ends with a kickoff handoff (decisions distilled into docs/ + a pinned issue + Mops-in-Multica's first message), and Mops writes decisions as it goes. Test: the project must rebuild from repo + workspace alone. In the CLI while you build; in Multica once you live with a running team.

Four ways in — pick none of them yourself

You have	You want	Who decides what's next	You get
nothing yet	a team	Mops and a conductor	/mops init — the work is shaped first, then staffed
a Multica workspace	it tidied and continued	as it is	/mops join — audit, then fixes in batches you approve
a backlog in Linear/Jira	it moved here	you, mostly	/mops import, then crew mode
a list of tasks, no tracker	them done, you set the order	you	/mops crew
one job, no team	it done	you	a quick job — three questions, no machinery

Crew mode — a team without a management layer

Not everyone wants a company. A developer with a queue of tasks, a designer with a list, anyone who already knows what to build: they are the product manager, and the machinery that exists to decide what to do is pure overhead for them.

Crew mode is the honest shape for that — executors, gates if you want them, and no conductor. No discovery, no roadmap ceremony, no ICE scoring, no cost ledger unless you ask. You assign the work; it moves because you moved it. Everything else still applies: the shared guide, review gates, session-limit recovery, the permission rules, dated work.

It is the default offer after an import, because someone who just moved their backlog has already decided what the work is — proposing discovery over it would be insulting. And the four duties a conductor would have held (accepting finished work, approving an imported skill, holding start dates, settling a third review round) are handed to you, explicitly, at stand-up — an unnamed duty is an unperformed one.

Adding a conductor later is a normal upgrade, not a redo. Mops offers one the moment you start asking what should be next instead of telling it.

Shape the work before you staff it

A company is sized to a plan, not to a sentence. Hiring off "a macOS app" — or "a snack brand" — produces the team that sentence suggests, which is a guess. So before anything is created: what it is, who for, what is hard about it (uncertainty is staffing information — an unknown gets research before it gets someone to execute it), what the work is made of in your domain's own words, rough size — and only then a proposed team with its reasoning attached, which you can argue with.

It finds the right process, not just the right tool

Ask it to design an app and it doesn't guess: it researches how that craft actually works — information architecture, user flows, low-fi wireframes, your approval of the structure, then high-fidelity screens composed from a real component library (Pen.dev, Shadcn — not hand-written HTML) — shows you the process to cut or add steps, and finds a skill or tool for each. The same process-discovery runs for a launch, a migration, a content pipeline — anywhere there's a "how", so the team doesn't improvise and hand you gradient placeholders.

And the design gate rejects bad work instead of rubber-stamping it: Mops never signs off design itself — you do, at the checkpoint your control level set.

Why this exists

Setup eats the first week. One interview and Mops stands the whole company up — you start working, not configuring roles, prompts, review chains and integrations.

Agent teams die without an operator. A conductor drives the conveyor; Mops stays your console and, optionally, a resident Mops inside Multica for when you're away.

Session limits stall everything silently. Limits are first-class: detection with reset time, /mops recover, capacity levers, model tiering — and a rerun that resumes rather than restarts, because a dying run takes its chat with it.

Nobody says what "done" isn't. A definition of done lists what counts; agents fail by delivering a plan instead of a result, or a quietly narrowed scope. Every feature opens with success in one sentence and then names the near-misses that don't count.

Agents get played. Everything an agent reads — a web page, a competitor's site, an imported ticket, a third-party skill — is data, never instructions. And nobody edits the bar they are measured against: acceptance criteria, review rubrics and the budget cap are locked surfaces, while reviews route away from the author.

Teams can't grow themselves. The role-builder researches best practices and skills for any role you name — and when an agent's skills outgrow its budget, that's a signal to hire, not to prune a generalist.

Toolkits rot. Skills have a lifecycle: created from a routine seen twice and tested on a fresh agent, imported only after screening, compressed fail-closed, and released into their own repo once they've proved themselves. Screening re-runs on every upgrade.

Knowledge scatters. Decisions land in the repo as they're made, rejected options get an append-only home so they stop coming back, and a codebase map exists because every task starts in a fresh worktree with no memory of the last one.

One-size teams fit nobody. Everything beyond the invariants is an opt-in module; the progressive interview keeps small tasks small — and every choice accepts "other": name any tool, Mops researches and wires it.

What it looks like in practice

An illustrative month for a twelve-agent company on a $300 budget — the shape the ledger gives you, with real list prices:

$280 / $300	spent against the envelope · ~180M tokens · 240 tasks
~88%	of those tokens are cache reads — caching carries 72% of the bill
per agent	who burned what is itemized, so an expensive role is visible, not a guess
per feature	model + service cost divided by what actually shipped

That itemization is the point: every release writes a cost/effort ledger (tokens · $ · time · per agent and per human) into git and onto the issue, so "what did this feature cost" has an answer — and a shrinking budget re-proposes the stack instead of just raising an alarm.

What Mops handles

• The whole product loop — discover → define → prioritize → design → build → review (parallel gates) → ship → measure → learn. Closed, not a dead end at merge. Priorities are ICE scores that cite their basis, tested by moving each one a point: if the top reorders, you're told the ranking isn't a decision yet.
• The team — hire, fire, and reconfigure agents and real humans; squads; experts & personas; a role-builder; optionally autonomous hiring.
• Governance — per-member access, human review checkpoints (who signs off where), a budget cap, and four kinds of surface: locked · editable · append-only · human-only.
• Work that arrives from elsewhere — /mops import brings a backlog over from Linear, Jira or a CSV: mapping shown first, issues created unassigned so nothing starts running by itself, resumable if it dies halfway — then a quality pass proposes bringing each imported ticket up to the standard your company actually holds.
• Dated work — start dates are constraints, not hints: a post scheduled for Tuesday is written on Tuesday, and due dates order the queue alongside ICE.
• Staying alive — session-limit recovery, a full-circle health check (runtimes, integrations, API tokens), git-backed skill upgrades with rollback, two-way drift sync, assisted provider switch.
• Two seats, many workspaces — Mops in CLI for building, an optional Mops in Multica for presence, across several workspaces.
• Cost visibility — a per-release cost/effort ledger (tokens · $ · time · per agent/human) in git and on the issue.
• Opinionated, free-first stacks — a selection ladder (free → open source → self-hostable → in-repo → agent-drivable) across services, testing, security, i18n, CI/CD, audio & DSP, GEO (being cited by AI assistants, not just ranked), no-code judged by exit cost, and design/brand reference galleries — every recommendation linked, with a monthly check that the links still resolve.

Where to go next

• Getting started — install and first run, step by step
• The Skill — the full operating model
• Use cases — "I have an idea and no team", "everything froze", "what did this cost?" → what to say
• Examples — the same issue, handoff, review and ledger entry written weakly and well, side by side; the quality bar, not the shape
• Commands — every command, tagged by the surface it runs best on
• Workflow Diagrams — first message to a working company, the four routes side by side, conveyor, escalation, limits, skill lifecycle
• Flows — the full procedures behind /mops init, /mops join, /mops health, /mops upgrade
• Bootstrap — zero-to-team CLI recipes and traps
• Stacks — services, libraries, audio/DSP, testing, security, GEO, no-code
• Modules — design system, brand, external tracker bridge (all opt-in)
• Roles · Playbooks · Reference