IBM Bob Moves Inside the Firewall, and That Is the Whole Point

IBM has started offering its agentic software-development platform, IBM Bob, in self-hosted form. On-premises, private cloud, sovereign cloud, and air-gapped deployments are all on the menu. Customers pick their own model configuration, keep source code and application context inside their own network, and retain control over data residency and security policy.

That sounds like a deployment footnote. It is closer to a thesis about who gets to use coding agents at all.

The gap that self-hosting closes

Coding agents have moved fast. They read a repository, propose changes, run tests, and open pull requests. For a startup, wiring one into a cloud service is a Tuesday afternoon. For a defense contractor, a bank, or a hospital system, the same move fails at the first legal review. The source code cannot leave the building. Internal context, the messy institutional knowledge that makes a codebase comprehensible, cannot leave either. Air-gapped environments have no cloud path, by design.

That leaves a large slice of the economy watching the agent era from behind glass. IBM is selling to that slice, and it is not the first. The category is small right now, mostly because self-hosted agents need model weights, hardware, and an orchestration layer that a cloud vendor would normally provide. The company that solves the plumbing gets a customer base that the API-first labs cannot reach.

Why this is harder than it looks

An agent is easier to understand as a loop than as a single thing: plan, act, observe, adjust. In the cloud, the tools it calls are services, and the failure modes are someone else's problem. Behind a firewall, the agent has to reach the same repositories, the same ticket trackers, the same build systems, except now the network is segmented, the credentials are rotated on a schedule, and half the services were last updated before the word "agent" meant anything.

IBM's pitch leans on the fact that it already sells into these environments. Its customers run mainframes and legacy systems that nobody else wants to touch. Making an agent work there is unglamorous, slow, and exactly the kind of work that creates a moat.

There is a governance angle too, and it is the one that keeps coming up. A self-hosted agent produces logs you own. In a regulated audit, you can show exactly which model ran, what it read, and what it changed. In a cloud setup, that evidence is spread across a vendor's console and a service agreement. When something goes wrong, the difference between "we have the logs" and "we have requested the logs" is the difference between a closed incident and a quarter of discovery.

The model question underneath

Self-hosting an agent means self-hosting a model, or at least choosing one you can put on your own silicon. IBM lets customers select supported configurations, which in practice means a mix of open-weight models and IBM's own. The open-weight options matter here. A 70B-class model running on a private cluster is slower and less capable than the best hosted model. It is also available when the network is down, when the vendor raises prices, or when the vendor decides your use case violates a policy you never read.

Enterprises have made this trade for a decade with databases, and it lands the same way: they accept a capability gap in exchange for control, then close the gap over time as hardware improves.

The economics look different behind a firewall

Cloud coding agents are priced per token, which means the cost scales with how much code the agent reads and writes. For a startup, that is a predictable line item. For a large enterprise, where a single repository can hold decades of history and the agent has to ingest far more context before it can help, the meter runs hot.

Self-hosting flips the model. The cost becomes hardware and operations, which are capital expenses the organization already carries. A bank with a data center is not paying more when the agent reads another million lines. The marginal cost of an additional agent task approaches the electricity and the GPU time, and those are sunk. That asymmetry is why the self-hosted pitch lands even when the cloud product is objectively better.

There is a compliance cost that the marketing skips, though. Self-hosting shifts the burden of patching, monitoring, and model updates onto the customer. A cloud vendor pushes a fix and it is done. An on-premises deployment has to schedule the upgrade, test it against internal systems, and survive a change-control board. The tool is more controllable and more work, and that trade is the whole story of enterprise software.

The adjacent market that makes this viable

Self-hosting an agent only works if there is something worth running behind the wall, and that supply has grown. Open-weight models in the range that can do real coding work are now common, released under permissive licenses by labs on several continents. The missing piece was never the model. It was the harness that turns a model into something a developer can delegate to inside a controlled network.

That is the layer IBM is selling. Training the best model is not the goal. Being the integration that makes an existing model usable in the places where a cloud call is not an option is the goal. The strategy is the mirror image of the API-first labs. They push capability outward and let anyone connect. IBM pulls capability inward and makes it survive the perimeter.

For buyers stuck in that perimeter, the choice has been unpleasant for two years: watch the agent wave from a distance, or break a security rule to join it. A self-hosted option does not make the wave smaller. It just makes it reachable, which for a regulated organization is the same thing as making it real.

What to watch

Demos are not the honest question about self-hosted agentic coding. The honest question is whether the results hold up on a codebase with fifteen years of technical debt, written by people who have left the company. Cloud agents struggle with that too. The difference is that a self-hosted agent cannot be improved by a vendor overnight without the customer doing the work. Every gain has to be earned by the customer's own team.

That makes adoption slower and stickier, which suits IBM. It is building for buyers who measure success in years, not sprints, and who would rather own a slightly worse tool than rent a better one they cannot inspect. For a coding-agent market that has spent two years chasing benchmarks, that is a conservative bet. It is also a bet on the part of the market that has not been served yet.

There is a version of this that plays out badly. Self-hosted tooling has a reputation for shipping once and then languishing, because the vendor has no recurring pull to improve it and the customer has no bargaining power to demand it. If IBM Bob settles into a stable product that never gets meaningfully better, the buyers it attracts will get exactly what they asked for and less than they hoped. The alternative, where a self-hosted agent improves on a schedule the customer controls, is harder to run and much more valuable. Which one IBM delivers is the thing to watch over the next year.