get-bb/bb Made Agent Recursion a Data Model Feature. Nothing in It Bounds the Depth.

The trending agent IDE tags its CLI as a first-class interface "for both users and agents," then gives threads the ability to own child threads. That combination is the product, and the interesting part is what it does not limit.

Most agent orchestrators bolt an API onto a UI and call the API a feature. bb inverts it. Its vision document states the principle flatly: "Users and agents are both first-class operators... The CLI should not be treated as a sidecar or an afterthought." Then its data model does the thing that follows from that. Threads come in two kinds, standard and manager, and "threads can own child threads for delegation."

Put those two facts next to each other and you get a system where an agent running inside bb can shell out to bb, create three more threads, assign them to different machines, and watch them report back. Not through a plugin. Through the same interface a human uses.

That is a genuinely different design from the parallel-agent tooling that has been trending all summer, and it is worth understanding on its own terms before deciding whether you want it running on your laptop.

The runtime, in four pieces

bb ships as a monorepo with four components, and the boundaries between them are the whole story.

The server is the hub. It stores all state in a SQLite database, exposes an HTTP API, and pushes change notifications over WebSocket. Its own docs describe it as stateless, with the database as the source of truth. It routes work to machines over a daemon WebSocket.

The host daemon runs on each enrolled execution machine. It provisions workspaces, runs the agent provider processes, and posts events back. It also exposes a local HTTP API for co-located operations like opening an editor or picking a folder.

The app is a web UI for watching and steering. The CLI (bb) has, per the docs, the "same capabilities as the app, scriptable."

Two contract packages define the seams. @bb/server-contract covers the HTTP and WebSocket API between clients and the server. @bb/host-daemon-contract covers the protocol between server and daemons. Implementation packages never import across those boundaries, so the server has no idea how a workspace gets provisioned and the daemon knows nothing about threads or projects beyond what a command tells it.

This is unusually clean architecture for a project four months into public existence, and it is why the agent-as-operator claim holds up rather than being aspirational. The API is not a wrapper around the UI. The UI is one client of a contract, and the CLI is another, and an agent using the CLI is indistinguishable from a person using it.

Why manager threads change the shape

The data model has four entities. A project maps to a repository and has one or more sources saying where code lives, with each local-path source belonging to a specific enrolled host. A thread is the unit of work: a conversation with an agent provider, a lifecycle state, and an append-only event stream. An environment binds a workspace directory to a host, either managed by bb or pointed at a directory you already have. A host is a long-lived daemon identity for a machine.

Now the part that matters. Threads are standard, meaning they do the work, or manager, meaning they coordinate other threads. And any thread can own children.

Every agent framework has some version of subagents. What is different here is that delegation lives in the persistent data model rather than in a running process. A manager thread is a row with children, an event stream, and a lifecycle. It survives the app closing. It can be inspected from the CLI, driven over HTTP, and handed to a different agent partway through. The orchestration graph is durable state, not an in-memory call tree that dies when the terminal does.

That is the feature I would actually want. It also means the depth of that graph is bounded by nothing in the schema.

Read the docs for a limit on how many children a manager can spawn, or how deep the chain can go, or what stops a manager thread from creating another manager thread. It is not there. The vision document lists "reusable primitives instead of hard-coded special cases" as a principle, and that principle is doing exactly what it says. A recursion limit would be a hard-coded special case.

Combine that with the other half of the setup. The README says bb "uses the provider CLI you already have authenticated." So bb does not hold your model credentials. Your Claude Code or Codex install does, and bb drives it. Every thread a manager spawns bills to that account, and nothing in bb's data model knows what a dollar is.

Getting a real look in ten minutes

The lowest-friction path is one command:

npx bb-app@latest

Then open http://localhost:38886. That is it. bb picks up whatever provider CLI you have already authenticated, so there is no key to paste. A macOS Apple Silicon desktop build exists as a release download and is the recommended install. Intel Mac and Linux users run the npx path. Windows works only inside WSL2, and native PowerShell and CMD are explicitly unsupported.

Do two things before you form an opinion.

First, turn off telemetry. Production runs, meaning the desktop app and npx bb-app, send anonymous usage data by default: app starts, thread creation counts, user message counts, tied to a random per-install id. No content, no host, no project names. The maintainers point at the exact source file, which is more transparency than most projects offer. Opt out with BB_TELEMETRY=false if that is your policy, and note that development runs from source never send.

Second, create one manager thread and give it work that legitimately needs three subtasks, then watch the thread tree while it runs. That single exercise tells you more about whether this fits your workflow than any amount of reading, because the question is not whether bb can spawn agents. It is whether watching a durable delegation graph is better than watching four terminal tabs. For some people it clearly is. For others it is one more surface to babysit.

If you are evaluating for a team, read docs/system-overview.md first. It is 34 lines and it explains the host boundary, which is the thing that will bite you.

The honest limits

The star count will not sit still. Reading the repository three times in one session returned 276 stars, then 899, then 395, with forks at 26, 69, and 37. GitHub was serving stale cached snapshots at different ages. The real number is somewhere in the high hundreds and climbing fast, and any exact figure printed here is wrong by the time you read it. That volatility is itself information: this is a project in its first surge of attention, not a settled tool.

The maintainers say so themselves. The README carries a note reading "bb is in active development. Core architecture is stable, but workflows and surfaces are still evolving." Four thousand four hundred commits and no tagged versioned releases beyond rolling desktop builds. The nightly channel installs alongside stable with its own app identity, which tells you how fast the surface is moving.

The host daemon is where the authority actually lives. The server is stateless and the database is the source of truth, so the interesting privileges are not in the server at all. A daemon provisions workspaces and runs agent provider processes on a real machine, using credentials that machine already holds. Enrolling a second host extends that reach. The vision document says bb "should work well on one machine today without closing off remote orchestration, cloud execution, peer-backed environments, or mobile access later," and every one of those later items widens the same boundary. Nothing in the public docs describes an authentication model for enrolling a host or for the local HTTP API the daemon exposes. If you plan to run this across machines, that is the question to ask in the Discord before you do.

Development mode binds to all interfaces. The docs describe running the dev server and reaching it over Tailscale from another machine, noting that "source dev binds the browser app to all interfaces." That is a deliberate convenience for a development loop, not a production posture, and it is easy to leave running.

It is an orchestrator, not an agent. bb does not bring a model, a harness, or a coding capability. Everything it does well is coordination and state. If your problem is that your agent writes bad code, bb will help you watch it write bad code on four machines at once.

What I would take from it

The idea worth stealing, whether or not you install bb, is the one in that vision bullet. If your internal agent tooling has a UI and an API and the API is second-class, agents cannot be operators of it, and you will keep writing glue. Making the scriptable surface a peer of the visual one is a cheap decision early and an expensive one to retrofit.

The idea worth watching is the manager thread. Durable, inspectable, resumable delegation is the right primitive, and bb is the clearest implementation of it I have seen in an open-source tool. The version of this that gets adopted at work will be the one that adds a depth limit and a spend ceiling to the schema. Somebody is going to write that pull request. It might as well be you.

Sources: get-bb/bb on GitHub (README, MIT license); bb system overview; bb vision document; getbb.app. Star and fork counts were read directly from the repository page and varied across loads in a single session.