IBM and CoreWeave co-design controls for agent workloads
SiliconANGLE Victoria Gayton ● Covered by 8 sources
IBM and CoreWeave are co-building controls for agent workloads. It’s about keeping code runs isolated without wrecking performance.
Based on reporting by SiliconANGLE, Victoria Gayton — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
IBM Research is treating agent workloads as a new infrastructure problem, not just another flavor of model training. Once teams move past training and start running code, testing agents, and connecting them to tools and storage, the old assumptions stop holding up fast.
That shift is part of what pushed IBM toward CoreWeave, according to Brian Belgodere, a senior technical staff member at IBM. He said the cooling and power needs of a later hardware generation helped drive the move, after IBM had already built a large H100 cluster on its own. “We went out and built a large H100 cluster, and we did it ourselves: got the space, soup to nuts,” he said.
The partnership has grown beyond raw capacity. IBM and CoreWeave have been working on identity management and workload controls together, with IBM feeding requirements into CoreWeave’s systems and then revising the implementation through several rounds. Belgodere said CoreWeave often comes back asking for IBM’s feedback before changes move ahead.
A big piece of that work is isolation. Much of IBM Research’s cluster is single-tenant, with its own storage inside CoreWeave, and the team also uses CoreWeave Sandboxes for isolated execution, either on dedicated infrastructure or through a managed serverless runtime. That lets researchers decide where agent code runs and what it can touch. And IBM is measuring the security cost against benchmark results, because in this kind of setup, a bad early call can be expensive to unwind.
Belgodere framed the whole thing as a supply chain problem that runs from hardware and firmware down through kernels, code, data provenance and agent images. That’s the real change here: once models start doing things instead of just producing outputs, the security debate stops being abstract and becomes an architecture decision with bills attached.
My take — AI-written commentary, not fact-checked reporting
This is the part of AI everyone keeps pretending is optional: controls, provenance, isolation, all the boring machinery that keeps agent demos from turning into a mess. The open-vs-closed fight matters less than whether the stack can prove what ran, where it ran, and who could touch it. Agents without that discipline are just expensive optimism with a shell prompt.
Read more about this at: SiliconANGLE
