Bring Your Own Agent

Klaas van Schelven
Klaas van Schelven; September 18 - 2 min read | tags: philosophy
A developer bringing their own agent to the tools they use

Twenty years after getting rid of Clippy, we appear to have decided that we need 100 clippies rather than one.

Every product is getting a little intelligence-shaped thing in the sidebar that wants to summarize, suggest, explain and occasionally do something on your behalf. Jira has Rovo. Sentry has Seer. Salesforce had Einstein (but I guess that name was a bit too much – it’s gone now).

I get it: nobody wants to become the next Kodak. CEOs love telling investors they’re still relevant. And there might even be an occasional user actually aksing for this stuff.

But personally, I would rather have one agent that can use all my tools than a separate one living in each.

Just Give me the Data

So if yet another agent isn’t the solution, what is? I’d say: just give me my data! Make sure you have a great API, or maybe even slap an MCP on top of it.

This way, the agent that I was using anyway can just reach inside and do its thing. No need to have 5 imaginary friends passing notes to each other if I can bring my tool of choice.

Error Tracking

You’re reading this post on the blog of Bugsink: a tool to keep Track of Errors in your (production) applications. I happen to believe that Error Tracking is actually a pretty sweet fit for the “agentic age”: Error Trackers are built to collect meaningful context, and Agents are built to consume it.

That doesn’t mean I’m about to force my own particular agent on you though: first, it’s simply not what I’m about (see the above) and second, I don’t believe competing directly with the billions of the big AI labs is such a good game to be in in the first place.

When the AI belongs inside

Putting the AI in the product may still have its uses, of course: when a company can do analysis across millions of its customers’ data sets, it may learn things that each individual customer (or their agent) wouldn’t be able to figure out.

The obvious problem with that setup is that it requires each of those customers to give up their data. That’s problematic to begin with, but if the data contains the customers’ customers’ data (as it often does in the case of Error Trackers) the problems become even more serious.

Let tools be tools

I suspect we’ll look back at this phase as we now do on the time everybody and their dog wanted to tack their own social media platform onto their website (remember, kids?)

For now, I think the best thing we can do is to make sure our tools are actually useful to the agents our users choose to use.