How I Plan AI Agent Projects With Beads

Most people plan projects in a Google Doc or a Notion page. Write a list of things that need to happen, maybe add some checkboxes, and start working through them.

That works fine for simple stuff. But when you’re directing AI agents to build something (where each piece depends on other pieces, different tasks need different tools, and you need multiple rounds of review to catch what you missed) a flat list falls apart fast.

I’ve been using a tool called Beads to manage my projects, and it’s changed how I think about planning entirely. Here’s the workflow.

What Is Beads? (The Plain-English Version)

Beads is a task tracker built specifically for AI agents. Instead of a flat to-do list, it creates a graph: tasks that know about each other, with dependencies, priorities, and status tracking that agents can read and update on their own.

Think of it like this: a normal to-do list says “do these 12 things.” Beads says “do these 12 things, but #4 can’t start until #2 is done, #7 needs a different skill than #3, and here’s the exact status of every piece right now.”

The killer feature: agents can claim tasks, update status, and track dependencies without you micromanaging. You set up the plan, and agents work through it.

It runs in your terminal:

bd init                          # Set up beads in your project
bd create "Build podcast page"   # Create a task
bd ready                         # Show what's ready to work on

Everything is stored in a version-controlled database locally. No cloud dependency.

The 7-Step Beads Workflow

Here’s how I actually plan and execute projects. I’ll use a real example: building out the littlemight.com website.

Step 1: Plan the Project

Before touching any tools, I think through what needs to happen. Usually this is me talking out loud (via Wispr Flow for voice-first planning) to an agent:

“I need to build out the littlemight.com site. We need a landing page, article pages, a podcast page, a newsletter signup, and a custom 404. The landing page needs to be the entry point. Articles need cross-linking. The podcast page needs a booking form.”

The agent helps me structure this into a clear scope. We go back and forth until the plan makes sense.

What does 30 minutes of planning actually look like? I open Claude, describe the project in plain language, and ask it to help me break it into discrete tasks. Then I push back: “What did we miss? What depends on what?” That back-and-forth is the planning session. By the end I have a rough list I can turn into beads.

Step 2: Create the Beads

Now we turn the plan into beads: individual tasks with dependencies:

bd create "Build landing page" -p 0           # Priority 0 (highest)
bd create "Create article template" -p 1
bd create "Build podcast page" -p 1
bd create "Add newsletter signup" -p 2
bd create "Create custom 404" -p 2
bd create "Cross-link articles" -p 2
bd dep add bd-f2a1 bd-c3b2                    # Podcast page depends on template

Each bead has a hash ID (like bd-a1b2), a priority, and knows what it’s blocked by. This means agents can look at the graph and know exactly what’s ready to work on at any given moment.

Step 3: Claude Opus Reviews the Plan

This is where the magic starts. I send the full bead graph to Claude Opus and ask it to review the plan as an architect:

“Here’s my project plan in beads. Review it for missing dependencies, sequencing issues, and anything I forgot.”

Opus is great at this. It thinks deeply about what could go wrong. It’ll catch things like “you need a design system before you build the article template” or “the newsletter signup needs an email provider configured first.”

Step 4: Codex Reviews It

Then I run Codex (OpenAI’s coding agent) over the same plan for a second opinion. Codex approaches it differently. More focused on technical implementation, build order, and what’s going to break. It asks “can this actually run” rather than “does this make sense.”

Having two different AI models review the same plan almost always surfaces things one of them missed. If you haven’t used a two-model review workflow before, this is the most natural place to start.

Step 5: Claude Puts It Into Beads

Based on the reviews, Claude updates the bead graph: adding missing tasks, adjusting dependencies, reordering priorities. The plan gets tighter.

bd ready --json    # What can we work on right now?

Step 6: Codex Reviews the Beads (Round 2)

Here’s the step most people would skip, and it’s the most valuable one.

After the beads are updated, Codex reviews the actual bead structure. Not the plan in the abstract, but the specific tasks, dependencies, and sequencing in the database.

This is where we find the gaps. Almost every time, this second review catches 2-3 things that weren’t obvious in the planning stage. Maybe a dependency is wrong. Maybe a task is too big and should be split. Maybe something was assumed but never made explicit.

This round of review is the difference between a plan that sounds good and a plan that actually works when agents start executing.

Step 7: Assign Skills to Each Bead

The final step: I go through each bead and tag it with the specific skills or tools needed to complete it.

For example:

Landing page → needs the design skill, maybe Shopify theme skill
Database setup → needs Supabase skill
Deployment → needs Railway skill
Article SEO → needs the SEO content skill

This matters because when an agent picks up a bead, it knows exactly which skills to load. It’s not guessing or loading everything. It has precisely what it needs.

bd-a1b2  Landing page         [design, shopify-theme]     ready
bd-c3b4  Article template     [design, astro]             ready
bd-e5f6  Newsletter signup    [klaviyo, astro]             blocked by bd-a1b2
bd-g7h8  Podcast page         [design, astro, tally]       blocked by bd-c3b4

When a bead is done: the agent marks it complete with bd done bd-a1b2, which automatically unblocks any beads that were waiting on it. Dependents move from blocked to ready and show up on the next bd ready call. You don’t manage that transition. The graph does.

Beads vs Linear / Notion for AI Workflows

If you’re using Linear or Notion for project management, you’re not wrong. They’re great for human teams. The gap shows up specifically when AI agents are doing the execution.

What breaks with traditional tools:

Agents can’t natively query “what’s unblocked and ready?” from a Notion database
Dependencies in Notion are manually tracked, not enforced. An agent can start a blocked task
Skill requirements aren’t a first-class concept. You have to explain them in every prompt

What Beads adds:

bd ready is machine-readable: agents can call it directly
Dependencies are enforced in the graph, not in a human’s head
Skill tags travel with the task, so agents always have the right context

For content workflows, marketing campaigns, or business planning (not just code): yes, Beads works. If your project has tasks, dependencies, and multiple execution agents (human or AI), the graph structure helps. I’ve used it for the littlemight.com content pipeline, not just engineering builds.

Beads + Conductor: Running the Plan

Once your bead graph is locked, the natural next step is Conductor: a Mac app that lets you run Claude Code and other AI agents in parallel, each in their own isolated git worktree.

The workflow: Beads plans what needs to happen (and which agents should work on what). Conductor runs those agents simultaneously. Beads tracks completion. You’re orchestrating, not executing.

If you’re running 3-4 agents in parallel, this combo is how you actually move fast without things colliding.

Why This Works Better Than a To-Do List

Three reasons:

1. Nothing gets forgotten. The double-review process (Opus + Codex, twice) catches things a human planning session would miss. It’s like having two senior engineers review your project plan before you write a line of code.

2. Agents can self-serve. When an agent asks “what should I work on?” the answer is just bd ready. No ambiguity. No waiting for me to assign tasks. The graph knows what’s unblocked and what’s highest priority.

3. Skills are pre-loaded. By tagging each bead with required skills, agents don’t waste time figuring out what tools they need. They pick up a bead and already know the context.

The Honest Part

This workflow takes about 30-45 minutes of upfront planning. That’s more than most people spend.

But here’s what I’ve learned: the time you spend planning with AI agents is never wasted. It’s the time you spend re-planning (because something was missed, a dependency was wrong, or an agent went down the wrong path) that kills you.

Thirty minutes of structured planning with Beads saves me hours of cleanup later. Every time.

Installing Beads

Beads is open source and free:

brew install beads              # macOS/Linux
bd init                         # Initialize in your project
bd create "My first task" -p 0  # Create a task
bd ready                        # See what's ready

You don’t need to be technical to use it. If you can type commands into a terminal (and if you’re reading littlemight.com, you’re learning to), you can use Beads.

Beads on GitHub →

Related:

Conductor Review: Run Multiple AI Agents at Once — once Beads has your tasks ready, Conductor executes them in parallel
Why I Use Two AI Models to Review Every Piece of Code — what happens after your agents build something
CLAUDE.md Tutorial — the project-level context file that shapes what agents do with your Beads tasks
AI Agents for Small Business — the full agent stack that Beads fits into

This is part of the Little Might workflow series: how I actually plan and execute projects using AI agents.