The inevitability of company-specific agents

There’s an incident in #alerts: one of our Redis queues has an unusually high error rate. I @mention [Insert Slack Based Agent Here] and ask it to investigate.

Sixteen minutes later, the agent responds with eleven paragraphs of jargon about “cascading backpressure inversion” and “heuristic jitter collapse.” It’s in English, sure, but I genuinely have no idea what it’s saying. I can't see which model it used, can't inspect the prompt, and can't change the harness. So now I have two problems: production is on fire, and the agent that's supposed to help isn't helping.

# alerts

!

MonitorsAPP2:14 PM

Redis queue error rate elevated

ingest-events · .2% error rate (threshold .1%)

Ryan D'Onofrio2:15 PM

@Agent investigate

A

AgentAPP2:31 PM

Root cause appears to be a cascading backpressure inversion in the ingest fan-out tier, where the queue lease reconciler races the shard rebalancer during partial-partition drift.

This manifests as a semi-durable retry storm across the ephemeral consumer mesh, amplified by heuristic jitter collapse in the dequeue coordinator and a latent fencing-token skew between epochs.

Recommended remediation: introduce an adaptive lease quorum with bounded staleness, align the reconciler's monotonic watermark to the rebalancer's causal frontier, and re-baseline the saturation envelope.

Show more (11 more paragraphs)

Companies will want to own their agents

I think a lot of companies have made a Faustian bargain handing their agents to vendors and will soon want them back.

As agents take on more responsibility, companies will want more control over how they operate: which tools they can access, whose credentials they use, which models they run, and how their behavior can be changed.

I'm happy to keep paying for tokens, just as I pay for Lambda executions. But I don't want to outsource the harness that determines what my agent can do.

Not every company will make that tradeoff. But I think more engineering teams will choose to own their agents.

Meet Sprinkle

Sprinkle is Raindrop's internal agent, built on Sentry's open-source agent, Junior (thanks @zeeg). It helps teams investigate issues and take action across their tools through Slack. Sprinkle lives on a Mac mini on my desk, and our team can work with him through Slack, web chat, or MCP.

Honestly, Sprinkle started as kind of a joke. My wife named it, and I thought it’d be like an office pet. I just wanted to see how hard it would be to build our own agent.

But internal agents become useful fast. Once Sprinkle had access to our repositories, logs, and internal tools, the question around the office shifted from "Can Sprinkle do this?" to "Why can't Sprinkle do this?"

That's the advantage of a company-specific agent. A general-purpose agent has to work for every company. Sprinkle only has to work for ours.

Under the hood, Sprinkle has two components: a lightweight router on Vercel that handles authentication and forwards requests, and a worker on the Mac mini where the agent runs. Each task gets a persistent folder with its own checkout and databases, rather than a new VM. Its instructions, skills, and permissions live in Git, so changing its behavior is a pull request.

Every improvement compounds

Every "why can't Sprinkle do this?" becomes a PR. And the requests keep growing.

Some things we’ve built:

• RBAC for tools. Our founder Alexis wanted to use Ashby MCP through Slack, but I didn't want everyone at Raindrop asking how so-and-so did in their interview. So Ashby is scoped by user and channel: it only appears for the right people in the right place.
• Other agents can give it work. Sprinkle has its own MCP server. From Claude Code, Codex, or any local agent, I can hand it a half-finished task and walk away. It picks it up on the Mac and reports back in Slack.
• It reviews itself. Every day, a scheduled run reads Sprinkle's traces in Raindrop and its logs, finds where it was slow or wrong, and opens PRs to improve its own instructions.

Since October began, Sprinkle has merged 104 PRs across our repos, about 6% of everything Raindrop merged (and closer to 10% in the last week of October). I expect that share to keep growing.

Nobody is coming to save you

There are a few unfortunate drawbacks to self-hosting your agent (ask the hyperscalers!). A recent power outage took Sprinkle offline. The Mac mini is a single machine, after all. When it's slow, wrong, or stuck, that's my bug.

We've also rebuilt parts of Sprinkle more than once. The first version gave each conversation its own virtual machine. That was too heavy. Now each request gets a folder on the Mac, and the databases run in one shared VM. (If there is interest I will write another article in more detail on its architecture as I think it’s unique and a better way to do dev work!)

Slack is where the work is

Building your team's agent is addictive. I can get more done in Slack than ever before. It's observable, collaborative, and async.

Using the Raindrop MCP, Sprinkle runs its own self-healing loops and reports back with self-diagnostics when something breaks (which it will).

If Sprinkle hands me something I can't read, I can open the prompt and ship a PR before the incident is over.

I think every company will end up with an agent like this, one that knows its people, its tools, and its weird corners. Might as well own yours.