MUSAWIR RAJI

Design. Engineer. Ship.

Forged by Raji
Back to Blog
4 min read

I Built a Multi-Agent AI System With Claude. Here's What Nobody Tells You.

Everyone talks about how AI makes you faster. Nobody talks about what it actually looks like when you sit down and use it on a real build. Here's my honest take from building a five-workflow multi-agent system with Claude at the center.

MR

Musawir Raji

Frontend Engineer & Designer

I Built a Multi-Agent AI System With Claude. Here's What Nobody Tells You.

There's a version of this post where I talk about how AI changed my life and I now ship 10x faster and you should too. This isn't that post.

What I want to talk about is what it actually looks like when you sit down and use Claude as a working developer — not the demo, not the tweet, the real thing. Because I've been doing it long enough now that I have opinions, and some of them will probably annoy you.

The Build

A few months ago I built what I started calling the AI Command Center. Five n8n workflows wired together: an orchestrator (WF-ORCH), a research agent (WF-AMAZON), a knowledge base agent (WF-KNOWLEDGE), a KB ingestion pipeline (WF-KB), and a human approval loop via Slack (WF-APPROVAL). Claude sat at the center as the orchestrator brain. Gemini handled the embeddings. Supabase with pgvector stored the knowledge. The whole thing was a speculative portfolio piece — I built it to show what's possible, not because a client asked for it.

I used Claude to help design the agent communication patterns, reason through the tool-calling architecture, debug webhook payloads that were returning empty, and write the logic that decided when to escalate to human review versus when to let the agent proceed autonomously.

It shipped. It works. And here's what I actually learned.

Claude Is Not Your Senior Dev

The biggest mistake I see people make with AI-assisted development — and I made it too, early on — is treating the model like a senior engineer who will save you from your own confusion.

It won't.

When I was designing the orchestrator routing logic, I asked Claude to help me think through how WF-ORCH should decide which sub-agent to call based on the incoming request type. Claude gave me a clean, well-reasoned answer. It looked right. I implemented it.

Two days later I realized the routing was wrong for a specific edge case I hadn't thought to mention in my prompt. Claude didn't catch it because I didn't surface it. The model can only reason about what you give it. If your mental model of the system is incomplete, the output will be incomplete in exactly the same places.

This is the thing people skip when they talk about AI-assisted dev: the thinking is still yours. The model accelerates execution. It does not replace understanding.

Where It Actually Helps

Debugging. When a Supabase pgvector query was returning zero results and I couldn't figure out why, I pasted the schema, the query, and the embedding payload into Claude and got a diagnosis in about ninety seconds. The issue was a dimension mismatch between how Gemini was generating embeddings and how I'd set up the vector column. I probably would have found that eventually. Claude found it immediately.

Architecture conversations. Sometimes I don't need code. I need to think out loud with something that can push back. Claude is genuinely good at this — explaining tradeoffs, pointing out failure modes, suggesting a simpler pattern when I'm overengineering. The key word there is push back. If you treat it like a yes-machine, it becomes one. Ask it to poke holes in your approach. Ask it what could go wrong. The quality of what you get scales directly with the quality of what you ask.

Boilerplate. The n8n HTTP request nodes, the Supabase insert logic, the Slack webhook payload formatting — none of that needed my full attention. I offloaded it. That's not laziness. That's knowing where your actual judgment is needed and protecting that time.

The Honest Limits

Claude hallucinates. Not often, but enough that you can't run code it writes without reading it. I've had it generate function calls for n8n that looked correct, referenced real node types, and were subtly wrong in ways that only surfaced at runtime. You still have to know your stack.

It also has no memory between sessions unless you build it in. Every conversation starts from zero. When I was deep in the Command Center build, I was re-pasting architecture context at the start of almost every session to get useful output. That friction is real and it adds up.

And there are problems it just can't solve — not because it isn't capable, but because the problem requires context it doesn't have access to. Understanding why a specific client's Xano endpoint is behaving differently in production versus staging, for example. That requires you. Always will.

What I Actually Think

AI-assisted development is real and it's here and if you're not using it you are slower than you need to be. That's just true.

But the developers who are going to do the most with it are the ones who stay curious about the fundamentals. The ones who understand what's happening underneath well enough to know when the model is wrong. The ones who can write a clear, specific prompt because they have a clear, specific understanding of the problem.

Claude isn't replacing developers. It's raising the floor for everyone and making the ceiling higher for the people who actually know what they're doing.

That's not a bad deal. You just have to hold up your end of it.

All Posts

If this resonated, share it with someone who'd appreciate it.

Let's Work Together

Get In Touch