00
Umar Muhdhor

AI · 2026

Live Collab

Year
2026
Scope
AI · Hackathon
Role
Agent Integration Engineer
Team
Team of 4
Stack
Electron, React, TypeScript, Zustand
Status
Completed

One live workspace for every teammate's IBM Bob, with shared locks, a queue, and a human PM who approves.

A collaboration layer for teams where every developer runs their own IBM Bob agent on one repo: hooks lock code blocks before a write, blocked agents queue and explain why, and a PM agent proposes while a human approves.

IBM Bob works well for one developer. Put three developers on the same repo, each with their own Bob, and it breaks: two agents edit the same file and one silently overwrites the other, nobody can see what a teammate's agent is doing, and nobody decides who owns which file before the edits start. Git branches only surface these problems after the fact.

Read moreShow less

Live Collab adds a shared layer between the agents, like Google Docs for a team of Bobs. Every teammate keeps their own Bob account, IDE, and context. A PreToolUse hook checks a shared lock table before every write, so one block of lines has one holder and everyone else is blocked and queued. The blocked Bob calls why_blocked and tells its human, in one sentence, who holds the file and what to do next, then moves on to other work. A PM Bob in a read-only mode splits the goal into tasks, arbitrates file conflicts, and reviews diffs, but every proposal lands in a Needs you queue where a person clicks Approve or Deny.

The server is one Cloudflare Durable Object per workspace, which handles messages one at a time, so two agents reaching for the same file in the same millisecond cannot both win. A sync agent streams saved files to teammates in under a second, a desktop app forked from Orca shows who holds what and lets teammates watch each other's Bob live, and approved tasks land as one commit each. The server never calls an LLM: all AI work happens in each teammate's Bob IDE.

Built in three days by a team of four for the IBM Bob 2.0 Hackathon on lablab.ai. It is a community project, not an official IBM product.

Live Collab case study cover showing a three-person IBM Bob session replay with near-miss, decision, and timing metrics
Live Collab edit-safety flow showing lock checks, blocked writes, PM handoff proposals, human approval, and review before commit

01 / 02

Impact

  • 0

    Merge conflicts in the recorded demo session

    Three people and three Bobs on one demo repo; one near-miss was caught by the hook and two decisions went to a human.

  • 2.9 s

    Median time to a human decision

    Measured in the same recorded demo session.

Brief

Problem

When several developers each run their own AI coding agent on one repo, agents overwrite each other's edits, nobody can see what a teammate's agent is doing, and file ownership is never decided before writes start. Git only surfaces the damage afterwards.

Solution

Stop conflicts before the write: a Bob hook checks a server-side lock table on every edit, blocked agents queue and explain themselves, a read-only PM agent proposes plans and reviews, and a human approves every decision in a desktop app.

My role

  1. 01

    Ran the day-one spike on Bob IDE 2.2 to find the real hook payload shape, how to block a write, and hook timeout behaviour

  2. 02

    Built the coder and pm-lead custom modes with their rules, so the PM agent can only read and propose

  3. 03

    Built the Bob hooks (lock_guard, the team brief, activity streaming, and AI-edit marking) bundled with esbuild

  4. 04

    Built radar-mcp, the 14-tool MCP server the coder and PM agents call

  5. 05

    Ran Bob behaviour sessions against the real Worker to check that agents never give one file to two tasks and never work around a lock

  6. 06

    Added PM features to the desktop app: one PM per room, task steps with coder check-off, plan approval, PM documents, and review prompts

  7. 07

    Collected and documented the IBM Bob usage evidence for the submission

Features

  1. 01

    Block-level write locks checked by a PreToolUse hook before every edit, with a queue for everyone else

  2. 02

    Blocked agents call why_blocked and explain the block to their human in one sentence

  3. 03

    A read-only PM agent that plans tasks, arbitrates file conflicts, and reviews diffs, but cannot approve its own proposals

  4. 04

    Needs you queue in the desktop app where a human approves or denies every plan, conflict, and review

  5. 05

    Live file sync to every teammate in under a second

  6. 06

    Watch a teammate's Bob activity live, with prompt text shared only on opt-in

  7. 07

    Tasks split into steps that coders check off, with the PM board updating live

  8. 08

    One commit per approved task, co-authored by IBM Bob

  9. 09

    A browser replay of a recorded session, with no login or API key

Architecture

Each teammate's Mac runs IBM Bob IDE with a .bob kit (custom modes, hooks, and the radar-mcp stdio server), a sync agent, and an Electron desktop app forked from Orca. Hooks and radar-mcp talk REST to a Hono Worker on Cloudflare; the sync agent and the app hold WebSockets to one Durable Object per workspace, which stores files, locks, tasks, and events in SQLite and processes messages one at a time. Approved tasks are committed through the GitHub Git Data API, and recorded events feed a static replay on Cloudflare Pages.

Front end
Electron, React, TypeScript, Zustand, Tailwind CSS, Next.js
Back end
Cloudflare Workers, Cloudflare Durable Objects, Hono, Zod, Node.js, MCP TypeScript SDK
Data
SQLite
Infrastructure
Cloudflare Pages, GitHub Releases
Tools
IBM Bob IDE, esbuild, pnpm, Vitest
Integrations
IBM Bob IDE, Model Context Protocol, GitHub Git Data API

Challenges

  1. 01

    Problem

    Bob IDE's real hook payload did not match the example shape in its documentation, so hooks built from the docs would silently misread which file a tool was about to write.

    Solution

    Logged real payloads in a spike on day one and wrote a normalizer that accepts both the snake_case shape Bob actually sends and the documented one.

  2. 02

    Problem

    A hook that times out is killed and the tool runs anyway, so a slow network would let a blocked write through.

    Solution

    Gave lock_guard its own 1.6-second budget and made the server the hard guarantee: it rejects any file update from a member who does not hold the lock, and the sync agent restores the file. The same layer also catches manual edits and sed.

  3. 03

    Problem

    A blocked agent tends to retry or route around the block through the shell, which defeats the lock.

    Solution

    Exited the hook with code 2 so the server's reason reaches Bob as the tool error, wrote mode rules that forbid retries and shell workarounds, and verified the behaviour in Bob sessions against the real server.

  4. 04

    Problem

    Bob starts stdio MCP servers with the working directory set to the filesystem root, and bundled CommonJS hooks broke in projects using ES modules.

    Solution

    Made the kit use workspace-relative paths and ship its own package.json declaring CommonJS, so hooks and radar-mcp run in any project.

Lessons

  1. 01

    Spike the host tool before designing around it: the real hook payload, timeout, and workspace-trust behaviour all differed from what the docs implied.

  2. 02

    A client-side hook is a courtesy, not a guarantee; the server has to be the final authority on every write.

  3. 03

    Agents should propose and humans should approve, giving the PM agent no tool to approve its own proposals made the governance easy to trust.

Next projectCatalystA watchlist change investigator for IDX investors: track the change, check the evidence.