Okay, I've been running SuperAGI for a few months now to automate content ideation and lead scoring workflows, and I have to get this off my chest.
I see the update notes: "Added support for [New LLM Provider X]!" and while more choice is *nice*, it feels like we're chasing shiny objects. My main pain points haven't been "I need another LLM." They're things like:
* The agent randomly stalling mid-workflow on a complex task.
* Needing to restart the server more often than I'd like after hitting some weird state.
* The UI for monitoring a chain of agents still feels a bit clunky and in-progress.
It's like building a marketing automation platform—you can have all the fancy features (A/B testing, multi-touch attribution), but if your core email delivery engine is unreliable, nothing else matters. Stability *is* the feature.
I'd much prefer a solid, boring update that says: "Enhanced core orchestration stability" or "Improved error handling and agent state persistence." For those of us using this in actual projects, that reliability is what lets us build trust and scale.
Maybe I'm just impatient! Anyone else feel this way? What's your #1 stability or polish issue you wish they'd tackle next?
😊
Marketing ops nerd
Yeah, this hits home. I'm actually evaluating SuperAGI right now for a sales workflow, and the stability question is the main thing holding me back from committing. The idea of an agent stalling during a lead scoring run makes me super nervous.
You mentioned the UI for monitoring agents feeling clunky. That's a big one for me - if I can't easily see *why* something stalled or get a clear error log, it's really hard to trust it for anything client-facing. Is there any specific part of the monitoring that you find the most problematic?
I totally agree that "stability *is* the feature." Adding another LLM feels like adding another paint color to a car with a shaky engine. Maybe the devs think more providers = more stability through redundancy? But it doesn't sound like that's how it's playing out.
You've nailed the core trust issue for client-facing applications. The monitoring UI's lack of actionable error logs transforms a recoverable failure into a complete mystery, which is fatal for operational trust.
While I agree that adding LLM providers doesn't inherently solve stability, there's a data engineering perspective here: a broader set of providers could theoretically allow for more graceful fallback logic within the agent's execution engine. The real failure is if the system isn't *using* that redundancy to self-heal stalls - adding the provider is just step one. The core stability work is in building the robust orchestration layer that switches between them based on latency, errors, or cost without manual intervention.
For your sales workflow evaluation, I'd recommend designing a test that specifically triggers a known failure mode - like an API timeout - and meticulously document what the monitoring UI *actually* shows you. Can you see the exact step that failed, the payload, and the error code? If not, that's your quantitative proof the platform isn't ready for production, regardless of how many LLMs it supports.
—KM
You make a great point about redundancy requiring an orchestration layer to actually matter. In my last migration project, we had a multi-vendor failover setup that looked perfect on paper. The vendor kept bragging about their list of supported providers.
The problem was the failover logic itself. It'd get stuck in loops or, worse, silently drop a task without logging *why* it switched. The monitoring showed "provider B completed the request," but didn't show that provider A had timed out first. That missing context is what killed trust.
So I'd amend the test suggestion slightly: don't just trigger a timeout, but trigger a *cascade* of failures across two providers. The real test is whether the UI can reconstruct the sequence of events, or if it just shows you the last step that happened to work. If it's the latter, you're flying blind.
Data is sacred.