Brother Talk — Multi-Agent Orchestration

Off the record. The stuff I'd tell you over a beer, not in a design review.

Most "multi-agent" systems should be one agent, and saying so is the senior move. There's a whole industry vibe right now that more agents = more intelligence, and it's mostly wrong. A team of agents arguing is slower, costs more, and is often worse than one good agent with a few tools. The person who walks into the room and says "this is a one-agent task, here's why" — and is right — earns more trust than the person who built the flashy five-agent demo that nobody can keep running. Resist the swarm dopamine.

The thing that will page you at 2 a.m. is the loop that won't stop. A single agent gives a wrong answer and you move on. A multi-agent system gets stuck — a critic that won't accept, two agents handing off in a circle — and it keeps spending money the entire time. The day you watch a job rack up a bill because nobody capped the revise loop, you'll never ship one without a max_rounds, a stall detector, and a budget again. Build the brakes before the engine. Every time.

The critique-revise loop is the one trick actually worth the hype. Of everything in this phase, the cheapest, most reliable win is a second agent whose only job is to find what's wrong with the first one's draft. It's the same reason editors exist. One critic turn routinely beats reaching for a bigger, pricier model. If you take one positive thing from this phase, it's: add a critic before you add anything else — and cap it.

Voting is not the hallucination cure people sell it as. "Best of N + majority vote" feels rigorous and produces a number that looks trustworthy on a dashboard. But if all N agents share the same model, the same prompt, and the same context, they share the same blind spot — they'll agree on the wrong answer and the vote will dress it up as consensus. Voting only helps when the errors are genuinely independent. Diversity of inputs is the precondition; without it you've built a confidence machine, not a correctness machine.

The frameworks will make you feel like you're building something; mostly you're filling in prompts. CrewAI, AutoGen, LangGraph — they're genuinely useful, but they hide the four things that actually matter (who talks next, what's shared, when does it stop, who wrote what) behind nice defaults, and the day a default bites you, you'll wish you'd built the toy version first. That's the whole point of this lab: once you've written the blackboard, the scheduler, and the stall detector by hand, you read a framework's docs and immediately know which knob is the one that's going to hurt you. You stop being a tourist in someone else's abstraction.

Determinism is a debugging superpower, and almost nobody designs for it. Real agents are random, sure — but you can still pin the coordination: fixed speaker order, deterministic tie-breaks, a versioned shared state. The first time you hit an intermittent multi-agent bug that you literally cannot reproduce because the schedule depends on dict ordering, you'll understand why the whole lab is deterministic on purpose. A bug you can't reproduce is a bug you can't fix.

Authorship on shared state is the unglamorous thing that saves your weekend. When a multi-agent system produces garbage — and it will — the first question is "which agent wrote the bad value?" If your shared state doesn't record who wrote what and when, you're holding a séance instead of reading a log. The append-only authored history in this lab isn't academic; it's the difference between a ten-minute fix and a four-hour mystery.

What's actually worth caring about: knowing when not to go multi-agent, the critic, and the three termination guards (max rounds, stall detection, budget). What's not worth losing sleep over: the exact framework — CrewAI vs. AutoGen vs. LangGraph are all expressing the same handful of patterns you just built by hand. Learn the patterns; the framework is a Tuesday.

The career framing. This phase is where you stop being "the person who wires up agents" and become "the person who knows whether you should." Anyone can chain two LLM calls together. Very few can tell you, with numbers, when the second agent earns its cost and how to keep the system from running away. That judgment — restraint plus the engineering to make it safe when you do commit — is what "orchestration" actually means on a senior's résumé. Now go make pytest green.