I built a 7-agent WhatsApp ops system (Mojo). Here's the architecture, what broke, and what I'd do differently.

Mojo is a seven-agent AI system that turns one WhatsApp message into a finished marketing campaign. Research, strategy, scripts, localization, and production briefs. Delivered to Google Drive in under 45 minutes, for under a dollar a run. I built it solo. Here is the architecture, the bugs that nearly killed it, and what I would change.

The architecture

Mojo runs on the OpenClaw runtime with a custom TypeScript plugin I wrote called KonvertClaw. Seven agents, each owning one discipline:

• Ops — the front door. Reads the WhatsApp brief, routes the run, and drafts the client email in Gmail at the end.
• Scout — research. Pulls the market, the competitors, the cultural context.
• Strategist — turns research into a campaign angle and a messaging spine.
• Writer — scripts and copy against the strategy.
• Babel — localization. Adapts the work for each target market and language.
• Producer — production briefs: shot lists, asset specs, the handoff a creative team can actually execute.
• Mojo — the conductor that holds the whole sequence together.

The agents run in a fixed sequence with three approval gates. The whole thing is controlled from WhatsApp — you send a brief, you approve at the gates, you get a finished package in Drive. Ops drafts the client-facing email so the human just reviews and sends.

Why this stands out from a regular multi-agent setup

The first version let an LLM decide which agent ran next. It failed 50–70% of the time. The model would skip a step, loop, or hand off to the wrong agent depending on the phrasing of a brief.

So I ripped out the LLM router and replaced it with a deterministic TypeScript state machine. The sequence is code. The judgment inside each step is the model.

LLMs are for judgment. Code is for everything that has to be reliable. That split is the whole trick.

That one decision is what moved Mojo from a clever demo to something I'd let touch a paying client's work.

What broke

Every serious bug became a spec for the next guardrail.

• Hallucinated tools. Agents invented tools that didn't exist and called them confidently. Fix: tool-awareness injection — each agent is told, explicitly and at runtime, exactly which tools it has.
• Double-dispatch. A race condition fired the same step twice and produced duplicate work. Fix: an in-memory lock around dispatch.
• Self-approval. An agent approved its own output and walked straight through a gate. Fix: a three-layer guard so the thing being checked can never be the thing doing the checking.

Each bug quietly became a spec.

What I'd do differently

• Guardrails first. I built the happy path and bolted safety on after. Next time the locks, the gates, and the tool boundaries come before the first real run.
• Observability on day one. I was debugging blind for too long. Tracing every dispatch and decision from the start would have saved days.
• Treat the LLM as the smallest part. The model is maybe 10% of the system. The other 90% is plumbing — state, locks, retries, gates, logging. Build the plumbing like that's the product, because it is.

Mojo works now. More than 20 clean end-to-end runs so far. A working agent system is mostly good plumbing with a model bolted on top. Get the plumbing right, and the magic takes care of itself.

---

Manish Dwivedi builds AI agents, automation systems, and SaaS products at Minimanishtic Labs. Mojo and KonvertClaw are part of the Konvert Media stack.