I’ve been spending a lot of my evenings and weekends building something called Bloom — an agentic, collaborative orchestrator for the software development lifecycle. It’s still early. But the idea behind it has been consuming my thinking for weeks, and I want to share where it’s headed.
Most of the agentic coding tools I’ve used focus on one thing: making engineering faster. That’s great, but it’s not the whole picture. What about the product manager shaping the idea? The designer making sure the experience is right? The cross-repo complexity that real systems have? Bloom is my attempt to explore what it looks like when you optimize the whole workflow — from idea to shipped code — with AI-powered collaboration built in at every stage.
I was heavily inspired by Steve Yegge’s work on Gas Town and Beads, along with OpenSpec and GitHub SpecKit. The core question I kept coming back to: how do you connect planning to agentic execution without stitching together a handful of disconnected tools? And how do you use AI where it’s strongest — generating code, reasoning about systems — while letting humans guide the decisions that matter and leaning on deterministic CLI operations to keep token costs down?
Workspaces and Repos
Bloom is CLI-driven. You start by creating a workspace, which houses your repositories, projects, and documentation in one place. The workspace itself lives in Git. The repos folder is gitignored, and when you clone a repo through Bloom, it sets up Git worktrees so multiple agents can work across branches simultaneously without stepping on each other.
Because everything is co-located, cross-repo work becomes natural. Need to understand how authentication flows from your frontend through your backend and into another service? You can use bloom enter to drop into context and ask. Claude Code does the rest.
From Idea to PRD to Plan
The workflow starts loose on purpose. You drop markdown files, images, architecture diagrams — whatever you have — into a project folder. Freeform. When you’re ready to formalize things, bloom create opens an interactive PRD session. The output is a structured document focused on the what and the why of the project.
From there, bloom plan takes over. It looks at which repos are in your workspace, examines their current state, and builds out a markdown implementation plan — how to get from where things are to where they need to be. This happens interactively, like a Claude Code chat session, where you refine the plan together in real time. Add an architecture diagram, ask it to rethink a section, update constraints — the plan evolves with you.
Parallel Execution
Once the plan is solid, bloom generate produces a tasks.yaml file. This is where the orchestration engine takes over. bloom run spins up parallel agents that work through the task graph, respecting the dependency structure defined in the plan. It supports checkpoints where execution pauses automatically for human review.
By default, all agents merge into a single feature branch, landing one PR to main at the end. This keeps human review focused and puts the emphasis on having a strong plan upfront.
At every point when a task runs, Bloom creates a fresh agent instance with just the context for that task — plus a deterministic CLI command to mark it as done. No ambiguity about completion. The agent doesn’t decide if it’s finished; the system does. This keeps token usage low and behavior predictable.
Everything rolls up to a dashboard where you can view the DAG and track execution.
Building Bloom with Bloom
I’ve been dogfooding this from the early versions. Not every commit goes through Bloom — some of the work happens in the Claude Code web app while I’m away from my desk — but the core development loop is built on itself.
The cross-repo capability has been one of the most useful surprises. Planning a feature that touches a frontend, a backend, and a shared service is something most agentic tools don’t handle well today. Bloom was designed for exactly that.
What’s Next
Bloom is not ready for production use. The biggest gap right now is sandboxing — everything currently runs with the equivalent of Claude Code’s “dangerously skip permissions” flag, which is fine for exploration but not something I’d hand to a team without guardrails.
There’s more to build. But I’m excited about where this is going, and I plan to share more as it evolves.