How Runpod’s agent skills and MCP server work together
An API tells an agent what it can do, not whether it should. See how skills, a concept graph and live-account tests keep agents right on Runpod.
All
There were days this year when we had to tell users we couldn’t supply a B200 cluster. Some found capacity elsewhere. I can’t blame a team for doing that when it has work to finish.
A lot of the companies we talk to now use several cloud providers, sometimes alongside hardware they own. One customer built a queueing system just to move jobs across three or four clouds. Now they have another system to maintain.
Even if GPU supply improves, those environments don't simply disappear. Companies still have contracts to use, data in different places, and security approvals they’ve worked hard to get. Ideally, engineers should be able to use capacity without learning a separate deployment process for each environment.
Why teams end up in several clouds
Availability is only one reason to use another provider. A team may need different hardware, find a lower price for a particular workload, or need to keep data in a particular environment. Owning hardware can make sense too, especially when there’s enough steady work to keep it busy.
If one provider meets your needs, there may be no reason to add another. Once you have several, though, consolidating everything can mean giving up hardware or contracts you still need. Your engineers have to get work done with the setup you have.
Who pays for scattered compute
The cost I think about most is developer time. We’ve been connecting different kinds of compute to Runpod for over four years, since the company started. Differences in hardware, drivers, storage, and networking have been part of the job from the beginning.
Our engineers have run into a driver and CUDA version mismatch on one provider, a virtual machine with only one usable disk on another, and an AMD card that needed a newer version of ROCm, AMD’s GPU software stack, than our templates supported. These issues add up to weeks of work, and we do this for a living!
The platform team has another set of problems. Large companies have security, networking, and deployment rules that came from years of things going wrong. A new provider has to fit those rules. When a tool is too hard to stand up or fails a security review, those teams stop it, which is their job. A developer may be able to launch a job in minutes while the platform team spends weeks figuring out how to support the new environment.
Then there's the hardware that sits unused. Sometimes a job can’t use an available GPU because its data is elsewhere or the machine can’t meet its requirements. Sometimes getting onto the company’s own cluster means filing a ticket and waiting, so an engineer rents capacity somewhere easier to access.
When usable hardware sits idle because getting a job onto it is too much trouble, the company pays for that hardware and for the capacity its engineers rent instead. That’s a problem we can help with, even though we can’t make every workload run on every machine.
What you can do today
Start by finding out where your workloads are pinned and why. A model may need 80GB of GPU memory, or its data may have to stay in the EU. But a workload may also be tied to one provider because of a hardcoded storage path, or because that’s where an H100 was available the week the team shipped. Write down the actual requirements, then look at which accidental dependencies are worth removing.
Pick one workload and follow the steps an engineer takes to run it on capacity you already have: finding an available machine, getting access, and deploying the application. If getting access takes two days, a faster deployment command won’t fix the wait. Find the step that’s costing your team time.
Check whether the workload still needs the hardware you’ve assigned to it. A smaller model might meet your quality requirements. Batching requests or caching repeated results might reduce the capacity you need, provided you still meet your latency targets.
Work with us
I believe an engineer should be able to use the company’s own GPUs without having to build a separate system just to get a job running.
We’re working with a small number of teams on this very solution. There’s still a lot to build: governance across owned hardware and cloud capacity, cost attribution, and ways to allocate capacity among teams. Serverless endpoints that scale on customers’ hardware are also on the roadmap. These features aren’t available yet, and the teams joining us now will help decide how they should work.
If your team owns GPUs or rents capacity across providers, contact us. Show us a workload you’re struggling to run on capacity you already have. We’ll work through the setup with you and see how we can help.
