A cross-repo consistency agent. One change request in — a consistent fleet out.
Conductor is a proof-of-concept built for the IBM Bob Hackathon. It takes a single, plain-English change request and applies it correctly across an entire fleet of code repositories — reasoning about each repository in its own framework idiom, executing the change with IBM Bob, and verifying that the fleet ends up genuinely consistent.
Live dashboard: https://conductor-app-psi.vercel.app/
Every engineering organization past a certain size has the same quiet, expensive problem: fleet drift.
A platform team decides on a new standard — a structured logging format, a security patch, a dependency upgrade. Rolling it out is not easy. The change has to land in many separate repositories. Each is subtly different: different framework, different existing conventions. A human doing this work is slow, and inconsistent. A shell script can find-and-replace but cannot reason — it cannot recognize that an Express service needs middleware while a NestJS service needs a dependency-injected provider.
Conductor is built for exactly this gap: changes that require per-repository reasoning, applied consistently, at fleet scale.
Conductor coordinates three layers:
-
A planner (watsonx Orchestrate) interprets a plain-English change request and produces a structured dispatch plan — which repositories are affected, in what order, and what makes each one distinct.
-
An executor (IBM Bob Shell) performs the actual code migration in each repository. Bob reads the full repository context, plans the change in that frameworks idiom, edits the code, runs the test suite, and writes a migration report.
-
An aggregator (watsonx Orchestrate) ingests the per-repository results and produces a fleet-level verdict — confirming consistency, or flagging exactly where a service has drifted.
The connective tissue is the Conductor Runner — a TypeScript orchestration script that dispatches work to Bob Shell, parses its live event stream, and consolidates the results.
IBM Bob is the core of Conductor. It is the component that does the actual engineering work. Bob is used in two ways:
As Conductors execution engine (Bob Shell). Every repository migration is performed by Bob Shell running non-interactively with stream-json output. Bob receives a migration prompt containing the target standard, surveys the repository, plans a framework-specific migration, edits the code, runs the existing test suite, fixes any test assertions that depended on the old behavior, and writes a CONDUCTOR_REPORT.md. Every migration in this project is a real Bob Shell session — the raw session logs are committed under bob-sessions/.
As the development partner that built Conductor. Bob was also used throughout development to scaffold the three demonstration microservices. Those scaffolding sessions are also captured under bob-sessions/.
Three deliberately heterogeneous Node.js/TypeScript microservices, each with a different messy logging situation:
| Service | Framework | Starting state |
|---|---|---|
| conductor-demo-express | Express 4.x | Scattered console.log and console.error, three inconsistent formatting styles |
| conductor-demo-fastify | Fastify 4.x | Three coexisting loggers: Fastify built-in pino, a custom winston wrapper, and stray console.log |
| conductor-demo-nestjs | NestJS 10.x | NestJS Logger used inconsistently, plus raw console calls in a controller |
The shared target is the Conductor Logging Standard v1.0 — structured pino logging, a single logger module per service, request-scoped correlation IDs via AsyncLocalStorage, and no breaking changes to existing tests.
These figures come directly from the Bob Shell session logs:
| Service | Files changed | Bob tool calls | Tests | Cost |
|---|---|---|---|---|
| Express | 8 | 21 | 6/6 passing | $0.76 |
| Fastify | 8 | 26 | 4/4 passing | $1.02 |
| NestJS | 9 | 24 | 4/4 passing | $0.87 |
| Fleet total | 25 | 71 | 14/14 passing | $2.65 |
Each service was migrated in its own frameworks idiom. That is the difference between an AI agent and a find-and-replace script.
The Conductor Aggregator also correctly caught a real inconsistency during testing: the NestJS service initially emitted numeric pino log levels where Express and Fastify emitted strings. A consistency agent that surfaces real drift rather than rubber-stamping the fleet is the point.
Plain-English change request
|
v
watsonx Orchestrate - Conductor Planner agent
| dispatch plan
v
Conductor Runner (TypeScript / tsx)
| per repo
v
IBM Bob - Bob Shell (one session per repo)
| results + CONDUCTOR_REPORT.md
v
watsonx Orchestrate - Conductor Aggregator agent
|
v
Conductor Dashboard (Next.js on Vercel)
conductor-app/
app/ Next.js dashboard (the live mission-control UI)
components/ Dashboard React components
runner/ Conductor Runner orchestration script
src/runner.ts Dispatches Bob Shell, parses events, writes fleet-run.json
prompts/ Migration prompt template fed to Bob
standards/ Conductor Logging Standard v1.0
bob-sessions/ Raw Bob Shell session logs + readable Markdown reports
Companion repositories (the demonstration fleet):
- https://github.com/anilandcode/conductor-demo-express
- https://github.com/anilandcode/conductor-demo-fastify
- https://github.com/anilandcode/conductor-demo-nestjs
Each demo repository carries its own CONDUCTOR_REPORT.md and Bob session report.
cd app && npm install && npm run dev
Live at https://conductor-app-psi.vercel.app/
cd runner && npm install
npx tsx src/runner.ts --plan ./dispatch-plan.json
npx tsx src/runner.ts --plan ./dispatch-plan.json --live
Both modes produce fleet-run.json and aggregator-input.txt for the Orchestrate Aggregator.
| Layer | Technology |
|---|---|
| Execution engine | IBM Bob - Bob Shell v1.0.3 non-interactive mode |
| Planning and aggregation | watsonx Orchestrate - two Agent Builder agents |
| Orchestration | Conductor Runner - TypeScript via tsx |
| Dashboard | Next.js App Router deployed on Vercel |
| Demo fleet | Express, Fastify, NestJS - TypeScript with Jest |
Built for the IBM Bob Hackathon, 2026.