Is SuperAGI worth the setup hassle for a mid-market company?

Yep, the shallow tool integration is the real gut punch. You get excited by the count, but then you're just writing connectors in their framework. At that point, you're building your own platform on their unstable scaffolding.

The Jira example is spot on. We hit the same wall with ServiceNow. The "tool" was basically just an HTTP client with zero logic for CMDB relationships or approval workflows. Had to write the whole state machine ourselves.

The security policy issue was both. The agents sometimes tried weird egress, but the core setup also demanded it for inter-component chat. We locked it down to specific service DNS names after the fact.

On the cost loop, yeah, we saw it. A data validation agent kept re-fetching the same dataset. We only caught it because our FinOps dashboard flagged an anomaly in the Azure OpenAI spend, not from any platform alert. By then, it was too late.

Does anyone know if the newer commercial versions actually have session-level budget enforcement now, or is it still that useless monthly alert?

Your network policy example highlights the baseline infrastructure debt. We had to apply similar corrections, but the critical fix was adjusting the default QoS class. The manifests don't set `priorityClassName`, so in a cluster with priority preemption, our core pods kept getting evicted by batch jobs. That's a basic production readiness oversight.

On the cost spiral, you cut off at budgeting. Their control is just a throttle, not a hard cap. We verified this by letting an agent hit its configured limit; it merely paused for a few minutes before resuming. You need external enforcement, which circles back to your point about needing dedicated ops bandwidth to build the safety shell they omitted.

That "glue code" point is the real kicker, isn't it? You start with a list of 200 tools and think you're getting a head start, but you quickly realize you're paying for a fancy UI wrapped around a generic HTTP client. The promised productivity boost evaporates the moment your team has to write and maintain the actual business logic adapters for any real internal system.

And yeah, the cost spiral is the silent ROI killer they never mention in the sales deck. "Primitive" is generous. It's a throttle, not a budget. Without that dedicated ops layer you mentioned building your own kill-switches and predictive caps, you're just signing up for a monthly surprise invoice. Hard to justify when you're already burning cycles on their unfinished platform.

You're spot on about the tool integration. That shallow layer is what makes the transition from demo to production so painful. We found the same thing with their Slack integration, it could post to a channel but couldn't parse a thread or handle a basic approval workflow without us writing the entire state machine.

The cost control piece you mentioned, it's even worse than primitive. Their budgeting is per-agent, not per-session or per-task. So a single misconfigured agent on a loop can blow through an entire monthly budget in an hour, and you only get an alert after it's already happened. You absolutely need that dedicated ops layer just to build the circuit breakers they forgot.

That Kubernetes manifest snippet is a perfect example of the foundational work you're signing up for. It's not just about adding a network policy, it's about realizing the platform's defaults assume a permissive, toy environment rather than a real mid-market production cluster.

You're also right about the tipping point for ops bandwidth. The "200+ tools" claim is enticing, but if your team of 5 is already spending its time writing glue code and hardening manifests, you're not automating security reports. You've become a platform engineering team for SuperAGI itself, which completely flips the ROI.

We saw a similar cost spiral in our pilot. The budgeting was almost decorative. A single agent with a logic error could burn through its monthly allowance in one long weekend, and the alert would arrive Monday morning with the invoice. It forced us to build external monitoring anyway, which again, was more ops work.

That's exactly the kind of overhead I'm worried about. Our accounting team was looking at it for expense report automation.

So if writing custom tools for internal systems is needed anyway, wouldn't we be better off just using the OpenAI API directly with a simple script? It seems like you're paying for complexity without getting the real integration.

The hybrid capex/opex shift is the killer for approval. Finance teams can handle predictable SaaS, but "we need a senior engineer-month plus unpredictable API burn" breaks their models.

We saw the same with database tuning. Their default connection pool was set for demo-scale concurrency. It fell over under our normal load, which we only found during load testing - another week of platform work before we even got to our use case.

Oof, that pod churn from bad readiness probes hits home. We had the exact same issue on AKS, but ours was worse because their liveness probe was too aggressive and kept restarting healthy pods under moderate load. Had to fork the chart just to fix timeouts.

Your point about the $150k/year tax is the real math everyone needs to see. It's not just salary, it's the opportunity cost. That senior engineer could be building actual business logic instead of babysitting a brittle platform.

Have you looked at the newer commercial tiers? I'm wondering if their "Enterprise" offering actually fixes the probe configs or if it's just the same manifests with a support SLA slapped on.

Yeah, that's a brutal point about the cost spiral being baked into the design. If the budgeting can't see the validation loops, it's just monitoring the symptom, not the disease.

We saw something similar with their email parsing tool, where a malformed header would trigger a dozen retries before failing. Makes you wonder if it's a side effect of how they abstract the tools.

Has anyone tried instrumenting those retry loops directly to cut them off faster, or is the layer too opaque?

Instrumenting the retry loops? You'd need to decompile their SDK. The abstraction is the point, they hide the mess.

>a dozen retries before failing

That's because the "tool" is just a wrapper. The error handling is generic, so it treats a malformed header the same as a network blip. It's retrying a guaranteed failure.

You're not cutting off a loop, you're trying to patch a design flaw with monitoring.

Exactly. The generic wrapper pattern is what kills you. It's not just about retries, it's about observability. You can't attach a debugger to a black box, and you can't add a circuit breaker to a function you didn't write.

We ran into this with their Salesforce "tool". A malformed SOQL query would spin for minutes because the error response from the API wasn't in the wrapper's expected success/error schema. It logged a generic "tool execution in progress" the whole time. You're not monitoring an application, you're monitoring a facade.

That Salesforce example is a perfect case study of the problem. It's not just a logging issue, it's a diagnostic dead end. You're stuck watching a spinner while the actual error, which the underlying API returned immediately, is trapped inside a layer you can't see.

This is where the "200+ tools" claim starts to crumble. A tool you can't debug or instrument isn't a tool for a production team, it's a liability. You end up having to build a parallel monitoring system just to infer what the black box is doing, which defeats the whole purpose of using a platform.

I'm curious, did your team find a workaround for the Salesforce connector, or did you have to abandon it and write your own from scratch?

You've nailed the core problem with their value prop. That Jira example is spot on - we hit the same wall with their ServiceNow "tool." It could only fetch basic ticket info, none of the CMDB relationships our workflows needed.

Your point on observability is the real kicker. We tried to wire in OpenTelemetry tracing, but the agent runtime just doesn't expose the granular spans. You get a start and end event for the whole "tool use," but no visibility into the validation or retry logic inside. It's like trying to tune a car engine while only being able to measure the total fuel used for a trip.

So yeah, the cost control isn't a feature you can add. It's a missing architectural pillar.

Yeah, the orchestrator setup is a real canary in the coal mine. If their own manifests are that unstable, it tells you a lot about the testing rigor for the actual agent logic. I've seen similar fragility in their Helm chart's handling of secret mounts - they assumed a flat structure that broke on our vault setup immediately.

You mentioned writing custom tools defeated the purpose, but I think the deeper issue is the SDK itself. We tried to build a custom connector and the development loop was painfully slow because the local testing story for tools is so weak. You're essentially debugging in production, which circles back to that missing observability pillar everyone's talking about.