Evidence at a glance
IBM Is Shipping a Control Plane, Not a Model
IBM has made self-hosted IBM Bob generally available. Bob is an agentic software development platform covering the full lifecycle of software work: understanding code, planning tasks, executing changes, and validating results. Its shared developer surface includes the IDE experience, BobShell, parallel tool calling, the agent harness, skills, and modes. Enterprises can deploy it on premises, in private or sovereign clouds, or in air-gapped networks, with optional packages for Java, IBM i, and IBM Z modernization.
The important detail is the boundary of what IBM delivers. Bob does not bundle a model. Customers must source, license, and host an eligible model from IBM’s supported list. That makes Bob closer to an agent control layer for development work, while the model becomes a separately governed inference layer that can be partitioned or replaced.
The Inference Location Determines the Code Path
The key architectural question is not whether the interface still looks like Bob. It is where code, context, and build artifacts are processed. A fully isolated path can use NVIDIA Nemotron or Poolside Laguna, with inference hosted on customer infrastructure. A hybrid path can use external models such as Claude Sonnet 5.0, Claude Opus 4.8, Gemini 3.7 Flash, or OpenAI GPT 5.6 Sol through an approved private connectivity pattern.
The deployment choices form a useful evidence block. Local or air-gapped inference provides the strongest boundary control, but the customer operates the model. Approved external services reduce the local model burden, while allowing code and context to cross an enterprise-approved connection. Hybrid deployment divides those paths by workload. Developers may see a consistent Bob experience, but platform and security teams control whether each class of code can leave the enterprise boundary.
Hybrid Deployment Turns Compliance into Workload Rules
For banks, mainframe estates, and long-lived enterprise systems, code sovereignty is rarely a simple choice between keeping everything inside or sending everything to the cloud. Core banking applications, regulated mainframe code, or unclassified legacy systems can use local inference. Less sensitive work may use an approved external model for stronger capability or faster iteration. Bob is designed to place both cases within one development workflow rather than forcing teams to maintain completely separate toolchains.
This is also where Bob differs from products that primarily add agents to their own DevOps platforms. GitLab and GitHub emphasize agent capabilities inside their respective platforms, while Mistral pairs its agent with its own open-weight models. IBM’s tradeoff is to provide one development control surface for long-lived Java, IBM i, and IBM Z assets in environments that cannot reach the public internet. It addresses deployment boundaries and legacy modernization, not the engineering differences between models.
A Consistent Experience Does Not Mean Consistent Model Capability
Separating the model from the platform makes the architecture easier to adapt by use case, but it also makes the complexity visible. Self-hosting does not mean unrestricted model choice. Customers remain constrained by IBM’s supported model list, model licenses, local compute, and deployment requirements. IBM has not published self-hosted pricing and directs buyers to request a demo, so total cost cannot be estimated from a simple platform subscription alone.
The interface can also hide capability differences. Even if Bob’s tool calling, task orchestration, and validation flow remain consistent, models may differ in code understanding, long-task reliability, latency, and resource consumption. A deployment that keeps sensitive code inside an air-gapped network is not automatically equally effective for every modernization task.
Start with a Modernization Pilot with Clear Boundaries
For a technical leader, self-hosted Bob is better approached as an architectural pilot than as an immediate replacement for the entire development platform. Start with a clearly bounded asset class, such as core banking software, IBM i applications, or IBM Z code. Fix the local model path, tool permissions, build environment, and validation process before expanding the scope. Lower-sensitivity workloads can then be evaluated separately for access to approved external models.
The decision should test four points: whether code and context are routed correctly by classification, whether model licensing and local capacity are sustainable, whether Bob’s unified experience hides important capability gaps, and whether the operating cost of isolation is lower than the current approach. IBM lists multi-model routing as a planned expansion, so it should not be treated as a shipped automatic-routing feature today. The practical rule is to define which code may reach which model as platform policy before widening Bob’s deployment.