Hot take: Their focus on adding more LLM providers is a distraction from core stability.

Yeah, the orchestration failures are the real killer. I tried to set up a simple two-step agent that fetches data and then formats a summary. It kept losing the first step's output when I swapped providers.

I get adding new models is exciting, but if my basic workflow breaks every time, I'm just going to stick with one provider and call it via API directly. The whole point of a platform is to *manage* that complexity for me, not create more of it.

Do you think there's a sweet spot for how many providers they should officially support, or is it more about fixing the state management first?

Ah, the sweet spot myth. There isn't one. The problem isn't the number of providers, it's that they're building on sand.

You hit the nail on the head: *the whole point of a platform is to manage that complexity*. If swapping a provider breaks a simple two-step chain, they've failed at the foundational promise. They're just giving you a fancy UI for a brittle, bespoke API client.

State management *is* the support. Supporting zero providers perfectly is better than supporting twenty poorly. I'd take a rock-solid single-provider core with a plugin system any day over this carnival of broken chains. The current path just turns us all into their unpaid QA for new API wrappers. Hard pass.

That's a sharp technical read, isolating it to the scheduler's fault isolation - or lack of it. Your point about each provider being a new failure domain is exactly right.

It reminds me of an old pattern from distributed systems: you need a bulkhead between services, so a failure in one doesn't sink the whole ship. If the scheduler doesn't treat each provider call as its own isolated pod with its own timeout and state rollback, the variance will keep poisoning multi-step workflows.

So the fix isn't just better error handling, it's a architectural shift to containerize those calls. Until then, every new provider makes the whole system more fragile, not more capable.