Is It Really Multi-Agent?

I've been calling this a "multi-agent system." Time to be honest: it's not. Not really.

Yes, I'm using LangGraph. Yes, there are multiple specialized components — format classifiers, parsers for PDF and Excel and email, a 4-step extraction pipeline, validation nodes. It looks like a multi-agent architecture diagram if you squint hard enough.

But here's what's actually happening: a single orchestrator pushes documents through a sequential pipeline. Each "agent" is really just a function that reads shared state, does its job, and writes results back. There's no agent-to-agent communication. No competing perspectives. No negotiation or consensus-building. Just one path through the graph per document.

Document → Classify → Parse → Map → Generate → Validate → Done

A true multi-agent system might have an X12 Expert Agent debating a Payer Context Agent about whether "CLIA number" maps to REF*X4 or REF*1J. A Critic Agent could evaluate multiple DSL proposals and pick the best one. Agents could disagree, escalate ambiguity, ask clarifying questions.

Mine just... processes documents. Sequentially. One step after another. And I'm starting to think that's fine.

Document parsing is inherently sequential. You can't map to X12 segments until you've classified what type of validation you're dealing with. You can't generate DSL until you know which segments and elements are involved. You can't write rejection messages until you know the rule structure. The dependencies are real.

Could I add competing agents that propose different interpretations of ambiguous edits? Sure. Would it improve accuracy enough to justify 3-4x the LLM calls and significantly more complex orchestration logic? I genuinely don't know.

What I do know: the current approach is working. The 4-step sequential pipeline catches errors earlier. The format-specific parsers handle the variety of payer documentation. Rules are getting generated, validated, and stored. When something fails, I can pinpoint exactly which step broke and why.

I spent a week sketching out what "real" multi-agent would look like for this problem. Multiple extraction agents proposing different X12 mappings. A voting mechanism to select the best interpretation. Arbitration for edge cases. It was architecturally elegant on the whiteboard.

Then I ran another batch of payer edits through the existing pipeline. The rules came out clean.

Maybe the lesson is that "multi-agent" is a tool, not a goal. The sequential pipeline emerged because it solved real problems — observability, debuggability, independent retry logic. If I hit a wall where competing perspectives would genuinely improve quality, I'll add them. Until then, I'm not going to architect for a problem I don't have yet.

The system works. It's just not as fancy as the conference talks make it sound.