Bob V2: Faster, better, smarter
Bob V2 reaches general availability on June 24, and it's a real step up in daily use: it's faster, it can keep tasks running in the background while you stay on something else, and it's built on a single agent that behaves identically across every client. That agent ships first in Bob IDE, with Bob Shell following soon. Installing the new version is the only upgrade step; existing settings, rules files, and MCP servers carry over.
What this post covers:
- What the new architecture actually is
- The changes that show up in daily work: performance, the new modes, background tasks, rollback, working with documents, and subagents
- Workflows — a framework for making large, multi-phase changes repeatable
Tested on IBM first
Bob's first customer is IBM itself, where more than a hundred thousand developers are onboarded, on everything from mainframe systems to cloud-native services. V2 was put in front of a large internal population well ahead of GA. The capabilities in this post rolled out to them incrementally, starting in early May, so each one had real production use before shipping.
One agent, one harness, many clients
Bob V1's IDE extension and shell were built on two separate foundations. That was a deliberate call to get Bob into developers' hands quickly, but it meant building every improvement twice — and the requests above were exactly the kind that a split codebase makes slow to deliver.
V2 replaces that with a three-tier architecture that cleanly separates reasoning from infrastructure from interface:
| Component | Role |
|---|---|
| The Agent | The agentic loop. All reasoning and code generation happens here, identically in every client. |
| The Harness | Shared infrastructure: authentication, logging, feature flags, telemetry. |
| The Clients | The interfaces — IDE, shell, and more to come — with no duplicated logic. |
What changes in daily work
Before the individual features, the surface they live on changed. V2's chat is deliberately quieter: intermediate tool calls and dead-end exploration collapse out of the way, so what stays in front of you is the work and its output, not the machinery behind it.
Subagents: keeping context clean
As Bob works through a complex task, the conversation fills with file reads, searches, and dead-end exploration. Most of that detail doesn't matter to the main task, but it eats context window all the same.
Subagents handle this. When Bob needs to do something self-contained — "figure out how authentication works in this codebase" — it spins up a subagent with its own clean context. The subagent reads files, traces calls, and works out the pattern; only the summary comes back to the main agent, and the intermediate steps are thrown away.
Parallel, native tool calling
In V1, tool calls ran one at a time: request a file read, wait for the result, then request the next. On a task that fans out across five file reads and three searches, that waiting adds up fast. V2 lets the model request several tools in one turn and runs them together. A task that took around 30 seconds in V1 often finishes in under 10.
Native tool calling also drops the verbose XML that V1 wrapped around every tool request, so the same task burns fewer tokens. The context window is larger as well — up from 200k to 270k tokens — so longer tasks run further before compaction kicks in.
Three modes: Agent, Plan, Ask
V2 folds Bob's five old modes into three:
- Agent — Bob takes action and completes the task, with full agentic capabilities.
- Plan — Bob works through an opinionated planning process — gathering requirements, discovering context, checking its understanding — and produces an actionable plan to hand to Agent.
- Ask — read-only. Bob explains architecture and logic without touching the codebase.
The advice hasn't changed: on unfamiliar code, or a change with real surface area, start in Ask or Plan and switch to Agent once the work is clear.
Fewer interruptions, same control
Read operations — reading files, listing directories, searching code — are approved by default now, so Bob can gather context without stopping to ask. Anything that changes state still requires explicit approval: file edits, command execution, MCP tool calls, skill invocations. Approval is one layer among several — it sits alongside rollback, custom rules, and ignore files — and can be tightened or loosened per tool class.
Background tasks
Bob no longer holds a session to one conversation. A developer can run several tasks at once, leave them in the background, and keep working. Each task carries its own thread and context, so switching between them preserves its place. The task panel shows what's running, what's done, and what needs attention; finished tasks clean up after themselves. And Bob stays out of your way while they run — a task finishing in the background won't pull your focus or switch the tab you're working in.
Rollback, rebuilt
V1 called this checkpoints and built it on top of git, which constrained it: a repository without git got no checkpoints at all, and a very large history slowed everything down. V2 simplifies the whole thing and renames it to rollback. It now tracks file state directly — per task, per conversation turn, per individual tool call — and any of those points can be restored. Because rollback lives in the agent rather than a client, it works the same wherever the agent runs.
Working with documents
A lot of the context for a task lives outside the codebase — a design doc, a written spec, a spreadsheet of test cases. V2 reads .docx, .pdf, and .xlsx files natively: drop one into the conversation and Bob works from it directly, with no copy-paste or separate extraction step.
The same goes for what comes back out. At the end of an analysis task, Bob can produce a single self-contained HTML summary of what it found — one page, opens in any browser, needs no tooling to read. The result of an investigation is then something you can hand to someone who wasn't in the session.
Existing setups carry over
Work invested in another AI coding tool should carry forward rather than start over. V2 reads existing conventions, rules files, commands, and MCP servers, and adds support for the plugin format that's become a de-facto standard across the ecosystem — so common tool collections run in Bob directly. MCP servers already had their own settings tab in V1; V2 adds a dedicated skills tab alongside it, so skills can be added, configured, and removed the same way, without hand-editing files.
Workflows: making multi-phase changes repeatable
AI is good at open-ended problem-solving and bad at doing the same thing twice. Ask it to "migrate this to Java 21" on two different days and it can return two different approaches and two different results. For a one-off, that's fine. For large enterprise work — modernizing a mainframe application, refactoring thousands of files, anything that runs in phases — that variability is the whole problem.
Workflows give that kind of work a backbone. The starting point is that not every step wants AI, and not every step should be fully automated:
- Some steps are plain automation — scanning dependencies, running tests.
- Some need AI — complex code transformations, pattern analysis.
- Some need a human — approving a strategy, reviewing diffs before commit.
A workflow defines where each step belongs. The engine runs the steps in order, holds state, handles errors, and makes the whole process repeatable.
This is where IBM's premium packages come in. Each ships tested, opinionated workflows built on decades of IBM work in its domain, and each is a separate offering with its own post to come: the IBM Bob Premium Package for Java Modernization, the Premium Package for IBM i, and the Premium Package for IBM Z. At GA, the available workflows are the ones that ship with Bob and these packages; broader authoring opens up once the API surface settles with early adopters.
Further out
The same architecture opens up directions that simply weren't feasible on the old foundation. We're deliberately not attaching dates or commitments to any of this, but the broad areas we're exploring include running agents remotely and reaching them from any client, having multiple agents coordinate on a single task, and bringing Bob to more clients over time. Where these actually land will be shaped by what early adopters need most.
Update on June 24
Bob V2 ships on June 24 as an ordinary version update. Updating the IDE extension switches it to the new architecture; Bob Shell follows soon. There are no migration steps; settings, rules files, and MCP servers carry over.
One thing worth trying in the first week: start a task in Plan mode, hand the plan to Agent, and let it run in the background alongside other work.
Links