The most common reply to our outreach is four words: "we're building this in-house."
In March, I wrote a post explaining when that's a trap. Much of it still holds. A lot has changed.
If you're an engineer with Claude Code and a noisy pager, you're going to build something. And you should. This post is about where that something stops, and what we'll give you to find out.
What you're probably building
Almost every internal build we see follows the same shape. An alert fires. Someone invokes an agent, or the agent responds on its own. It pulls logs and recent deployments, then suggests a root cause.
Under the hood it's an agent plus a set of static skills you wrote yourself plus a set of off-the-shelf MCP servers, and they're good, because you're the expert on your own system. The result is an investigation assistant: a Claude Code for production, sitting in Slack.
It works. It makes investigations faster. It takes a good engineer about a week to get a promising version running. Build it; the agent layer and the Slack wiring are cheap, and they keep getting cheaper.
Where your tool beats ours
On the failure patterns you already know today, your internal tool should do exceptionally well.
We’re probably calling many of the same foundational models.
You know exactly how your infrastructure works, and you can hard-code exact instructions for your expected failures. From that perspective, you're operating at an advantage.
This is why none of our arguments are about today's accuracy. They're about tomorrow.
Whether the tool survives your company evolving, whether it's safe to touch production, and the bill, which is the part nobody itemizes.
We hit all three building Bacca.
1. The future can't be hardcoded, and one team's bot doesn't scale
Your hardcoded skills are perfect for last night's failures. Then the system changes underneath. AI is writing more of your code, services multiply, the engineer who tuned the prompts changes teams.
Who updates the skills then?
Maybe this reminds you of sitting in a postmortem while your manager reminds everyone, again, to update the runbooks. A static skill is a runbook a machine reads instead of a human. Every team has outdated runbooks: written after an incident, useful for a few months, and inaccurate within a year.
Nobody likes maintaining runbooks, and nobody will like maintaining skills, because they're the same document with better formatting. Each patch is trivial. The pile of patches is a second system that nobody owns, and it decays quietly, because a triage tool that's slowly going stale doesn't page anyone about itself.
You need an agent that’s able to learn your environment, instead of memorizing it, also lifts a ceiling you've stopped noticing.
Then the same problem arrives at company scale. A large organization isn't one team. Different teams, sometimes whole sub-businesses, need their own knowledge and their own instructions: in practice, a different agent per team under one roof, because two teams will call different things by the same name, and accuracy depends on the agent knowing whose world it's standing in.
The alternative is what we already see inside engineering orgs: five teams with five bespoke bots, none of them sharing anything they've learned.
2. A read-only agent can be bold. An agent with production access can't
Most internal builds already run with more than read-only access. Run the agent from an engineer's own environment, which is how nearly everyone runs it, and it inherits that engineer's permissions. The framework underneath will happily use every one of them. On a laptop that's convenient. Pointed at production, an incorrect action can cause an incident.
And you will want it pointed at production, because every team that builds an investigation assistant asks the same next question: whether it can just fix the thing that broke.
You need approval gates with ACL controls, so remediation happens with a human in the loop instead of an agent with production credentials and an open prompt.
You need deterministic actions, so that when a metric crosses a threshold the response is code that always does the same thing, not a model that probably will.
And you need an audit trail of every query it ran and every action it took, because the first serious review after an incident will ask for one, and "we're not sure what the agent did" is not an answer anyone survives twice.
Candidly, these parts took us longer to build than the agent itself.
They're workflows, designed from day one, and they're what keeps the agent transparent enough to trust: you can always see what it did and what it's allowed to do next.
And of course, you can build the features into your own tool. The question, however, is did you factor all of this into your build vs buy decision?
3. Then comes the bill
I’m sure you’ve heard the vendor cost pitch for twenty years: engineering time is expensive, so buy <insert tech solution> instead of building.
But things have changed. A bit. Building the agent layer is cheap now.
The real cost is in running the thing, and in keeping it useful.
Engineering leaders are already staring at AI spend that grew much faster than the ROI they get.
So here's a quick test: ask what one investigation costs in your internal tool. We ask every team that's built one. Nobody has known yet, because LLM spend sits in one company-wide bucket that nobody attributes.
We know our number and we continue to optimize it.
Forget dollars for a minute; count tokens.
Same alert, your build and Bacca side by side, both configured to use the same model. Three optimizations decide the gap.
Compression before the model. If you build it, your agent most likely reaches logs through a MCP integration to where your logs live, reads them, and hands them to the model.
That describes nearly every build we've seen.
Logs from one incident can be large, and most of them are the same few lines repeating with different timestamps. Piped in raw, that's hundreds of thousands of input tokens that mostly say nothing, and because the content changes every time, they're uncacheable, the most expensive kind you can buy.
We aggregate and compress logs and metrics ahead of time into the representation a model reads best, and send only that.
Discover once, reuse everywhere. Left alone, an agent rediscovers your system during every incident: which service logs where, what query reads that component's saturation, at full token price, at 3am. We run that discovery offline, on a schedule, validate it, and every investigation that follows reuses it for close to nothing, while an agent without it is still rediscovering the basics at full price.
Deduplication before investigation. Most alerts are the same problem arriving again. Investigate each one and you pay full price for the same answer many times. Bacca decides an alert is a repeat before spending tokens on it.
4. Keep up with new model releases
Every few weeks a new foundational model ships, and every provider says theirs is now the best.
Some of them are right. Nobody can tell you which one is right for your incidents. The only real answer is your own benchmark: historical incidents with confirmed root causes, replayed against every new model and every prompt change.
We spent more time building the feedback and evaluation pipeline than we spent building the agent itself (nobody plans that; it just happens). Most teams that set out to build an AI SRE discover they've signed up to build an ML evaluation pipeline with an AI SRE attached. The work recurs, too. Models you depend on get deprecated. Models you'd benefit from keep shipping. The evaluating never stops, and it lands on your best engineers, indefinitely.
Add it up and the comparison we want you to make is simple: with Bacca there's no build to fund, the run cost is lower because of the optimizations above, and the maintenance burden, the eval treadmill and the skill rot, are ours instead of yours.
So don't take our word for it
The old version of this post ended by inviting you to exchange notes. This one ends with three more things we think could help you.
Our test set. An anonymized benchmark of real production failures, drawn from the incidents we work on. Run your agent against the same cases we run ours against, and see where you stand before your next real outage grades you.
Replay. Bacca can replay your own historical incidents against your own bot. Building in-house, you can only test forward, waiting for the next fire. Point it at last Friday's outage and watch what your tool would have done.
A head-to-head. When your next incident hits, throw it at both. Count the tokens and keep whichever wins. If yours wins, you've lost nothing and gained a benchmark. If ours does, you found out in one incident instead of six months.
We already work with teams who started exactly where you are: mid-build and are wondering what tomorrow looks like.
If that's you, I'd like to see what you've built.
Eric Lu
Founder & CEO
we will contact you soon