I use a few different agents depending on the job — Codex for most of my day-to-day work, OpenCode when I want to try something new.
Recently I wanted to test Grok’s new model in OpenCode, and reuse a Skill I’d already written in Codex for one of my research tasks. It didn’t carry over. The Skill, and the tool connections behind it, were tied to the agent I’d built them in. I ended up rebuilding the setup from scratch just to run the same task somewhere else.
That’s the part that gets old. Every time I switch agents, I have to configure the setup again. Every new API means another registration, another balance to top up, and another set of docs to read.
I use Firecrawl through MCP to collect information from websites, and model APIs for generation and experiments with models like DeepSeek. Skills tie those tools together into processes the agent can repeat.
Each integration makes sense on its own. Together, they become another thing to look after alongside the projects I actually want to finish.
Moving beyond separate integrations
That’s where BeatAPI started, out of the same problem we run into in our own work.
The idea is close to what OpenRouter does for models, extended to what an agent needs more broadly. Keep using the agent you already work with, connect once, and reach the models, data, and tools you need through that one connection — no matter which agent you’re running it from that day. As we add a supported capability, you should be able to reach it through the same key.
We started with model APIs. Text, images, and video gave us a concrete place to begin, with tasks we could run ourselves and costs we could compare. Bringing those calls into one account also addressed part of the setup problem immediately.
But some of our work needed information that another model couldn’t supply on its own.
A concrete example: research with current social data
For one of our content research tasks, we wanted to know which AI discussions were attracting attention on X over the previous 24 hours. We needed recent posts we could read and check before choosing what to write about.
Using BeatAPI’s Social Data API, our agent searched for “AI,” “AI agent,” and “AI model.” The three calls returned 60 posts. After removing a duplicate and filtering by the time window, 21 remained. The agent grouped them into five themes for a research brief.
It was a small sample from three broad searches. We still had to judge whether the topics were relevant and whether we had anything useful to add. What helped was being able to inspect the posts behind the suggestions.
That’s the kind of research I want to do from inside my agent, using data it can actually retrieve — and it didn’t matter which agent I ran it from that day.
The same need shows up in other research we do. When we want to study how other products approach go-to-market — which videos are getting traction, how a launch is positioned, what a competitor's feed actually looks like — we want that same kind of access into TikTok and Instagram, not just X. Pull the posts, watch the videos, and let the agent work from what's actually there instead of a guess.
What exists today, and what is still a direction
Social Data became our first addition beyond models. It’s also a concrete example of what we mean by our current direction, The Agent Router for Everything — the models, data, and tools an agent needs, reachable from whichever agent you’re using, through one connection.
“Everything” is a big word for where we are today. Right now that’s model APIs and Social Data. Web search and computer use are next, and the broader set will take time — I’d like real tasks to help decide what we build first.
There’s a question I still want to test with people outside our team. We use enough different services, across enough different agents, for the setup to be annoying. Someone with one agent and two stable integrations may be perfectly happy maintaining them directly. I’m interested in where that starts to change for other people.
If you switch between agent hosts, how do you keep your Skills and tool configuration reusable? What can you carry over today, and what still needs to be configured per host?
Top comments (0)