The Agent Harness Reality Check: What I Found Building One After Everyone Said Orchestration is Dead

I kept hearing that agent orchestration was dead. "So two-years ago," as Signal #147 put it. The consensus seemed clear: individual agents talking directly to users was the future, and anyone still building coordination layers was stuck in the past. But I spent three weeks building my own agent harness anyway, starting with Claude's SDK as the foundation. What I discovered building it myself completely contradicted what everyone was saying online.

Why I Built When Everyone Said Don't

I had a specific use case that existing platforms couldn't handle cleanly. I needed agents that could coordinate on long-running research tasks, where one agent might hand off partial work to another based on what it discovered, then get results back hours later. The workflow wasn't linear enough for simple chaining, but it wasn't complex enough to justify a full orchestration platform.

Claude's SDK gave me solid building blocks for individual agent interactions, but the coordination between agents was still my problem to solve. That's when I realized something the hot takes missed: orchestration isn't dead—it just moved. Someone has to coordinate these agents, and the question isn't whether coordination happens, but who controls it.

What Building Taught Me About Control

The first surprise was how much coordination logic I actually needed. Even basic multi-agent workflows require decisions about timing, error handling, state management, and resource allocation. When Agent A fails halfway through a task, do you retry, route to Agent B, or fail the whole workflow? When two agents need the same expensive resource, who decides priority?

I thought I was orchestrating agents, but I quickly realized I was orchestrating API calls with some conversational intelligence attached. The complexity wasn't in making agents talk to each other—it was in managing the state and dependencies between their operations. Debugging distributed agent behavior when you own every piece taught me things that using a platform never could.

The Vendor Lock-in Nobody Talks About

Using existing orchestration platforms feels easier initially because they handle all this coordination logic for you. But after building my own, I could see the hidden costs more clearly. When you rent orchestration, you're not just paying for convenience—you're accepting that someone else gets to change the rules of how your agents coordinate.

I watched a friend's agent workflow break when their platform updated its routing algorithm. Nothing in his code changed, but suddenly his agents were making different handoff decisions. The platform's update was probably an improvement overall, but it broke his specific use case. He had to refactor around their new coordination rules instead of fixing his own.

The architectural decisions become permanent once you're locked in. The platform's abstractions shape how you think about agent interactions, and eventually your entire system assumes their coordination model. Switching becomes rebuilding from scratch.

The Real Question Isn't Whether, It's Who

Orchestration is happening whether you see it or not. When you use agent platforms, they just hide the coordination behind APIs and abstractions. "Orchestration is dead" really means "orchestration is commoditized"—it's become table stakes that platforms provide, not something you build yourself.

But commoditization doesn't eliminate the layer—it just moves control of that layer to the platform vendors. When I built my harness, I gained something more valuable than just coordination logic: I gained the ability to change how coordination works when my needs evolve.

What My Harness Actually Does

My coordination layer handles three main patterns: sequential handoffs where Agent A's output becomes Agent B's input, parallel delegation where one agent farms out subtasks to specialists, and collaborative convergence where multiple agents contribute to a shared workspace until they reach consensus.

Claude's SDK made the individual agent interactions straightforward, but I was on my own for everything else: managing the message queues between agents, handling partial failures, deciding when to timeout waiting for responses, and maintaining the shared context that agents needed to coordinate effectively.

The edge cases broke my assumptions about coordination constantly. What happens when an agent produces output that's valid for its individual task but breaks the assumptions of the next agent in the chain? How do you handle agents that work at different speeds without creating bottlenecks? I couldn't predict the performance characteristics without building and testing under real workloads.

The Ownership Tax

Rolling your own orchestration has real maintenance overhead. I spend time on infrastructure that I could be spending on agent capabilities. When vendor solutions work for your use case, they're often the right choice. The platforms have solved problems I haven't even encountered yet.

But there are specific scenarios where control beats convenience. When your competitive advantage depends on how your agents coordinate, not just what they individually accomplish. When you need coordination patterns that don't fit platform abstractions. When you're building something new enough that existing orchestration models constrain your thinking.

I'm keeping my harness despite the extra work because it lets me experiment with coordination patterns that would be impossible on existing platforms. The "orchestration is dead" narrative might be less about technical architecture and more about who gets to control the valuable coordination layer in the AI stack. The platforms want that control because coordination is where vendor lock-in happens. I'm still wondering whether the convenience of renting coordination is worth giving up the ability to change the rules when I need to innovate beyond what existing platforms support.