Claude Tasks vs Beads. Does this change the picture?

[tonybustamante]

Anthropic recently rolled out Claude Tasks, which lets you schedule recurring or one-off automated jobs directly in Claude, things like daily briefings, monitoring, summarization, etc. On the surface, this covers a lot of the same ground Beads is targeting: giving an LLM a persistent job to do on your behalf without you babysitting it. So the obvious question: does Claude Tasks eliminate the need for Beads, or is there still a meaningful gap? My gut says there's still a gap around composability, portability, and not being locked into one provider's ecosystem, but I'm curious what others think. Are Tasks a "good enough" version of this for most people, or is the Beads model solving a fundamentally different problem?

[peterkc]

Practitioner perspective — these solve different problems

I've been using Beads as the coordination backbone for an agentic development framework (multi-phase implementations, cross-session state, dependency tracking). From that experience, I think the comparison reveals an important distinction that's easy to miss: scheduled jobs and agentic workflows are fundamentally different things, even though both involve "an LLM doing work on your behalf."

Claude Tasks = scheduler/trigger ("do X on a schedule, each run is stateless")
Beads = state/memory/coordination ("what's ready, what's blocked, what happened last session")

A scheduled job is fire-and-forget: trigger Claude, it runs, it's done. An agentic workflow is stateful: Phase 2 can't start until Phase 1 passes review, the agent needs to know what gaps the reviewer flagged, and all of this has to survive across sessions because Claude starts each one with zero memory.

The gap is agent amnesia, not scheduling

Scheduled Job (Claude Tasks)        Agentic Workflow (Beads)
============================        ============================

Session 1:  trigger -> run -> done  Session 1:  bd ready -> work -> checkpoint
                 (forgotten)                         |
Session 2:  trigger -> run -> done               (persisted in Dolt)
                 (forgotten)                         |
Session 3:  trigger -> run -> done  Session 2:  bd ready -> pick up where
                                                  we left off -> checkpoint
  Each run starts from scratch.                      |
  No memory of previous runs.      Session 3:  bd ready -> finish ->
                                                  bd close

                                     State accumulates across sessions.
                                     Dependencies enforce order.

Claude Tasks can fire a job every morning, but each run has no memory of what it did yesterday, what's blocked on CI, or which phase of a multi-step implementation it's in the middle of. That's the structural problem Beads solves:

• bd ready — dependency-aware work queue. Only surfaces items whose blockers are resolved. A 6-phase feature implementation sequences automatically: Phase 3 doesn't appear until Phase 2 closes.
• Structured fields — description (requirements), notes (append-only session logs), design (technical approach) — each with different update semantics so multiple sessions don't clobber each other's context.
• Cross-session checkpoints — when a session ends mid-work (compaction, timeout, context limit), the next session picks up exactly where it left off.

Layers, not alternatives

These aren't competing tools — they're different layers of the same stack:

+------------------------------------------+
|  Scheduler    (Claude Tasks)             |  WHEN work triggers
+------------------------------------------+
|  Planning     (GitHub Issues)            |  WHY it matters (humans)
+------------------------------------------+
|  Execution    (Beads)                    |  WHAT is ready + WHERE we left off
+------------------------------------------+
|  Session      (ephemeral task tracking)  |  HOW work coordinates in-flight
+------------------------------------------+

Claude Tasks would slot in as the top trigger layer. A Tasks run could bd ready at the start and bd close at the end — making them natural partners rather than alternatives.

On composability and portability

Your instinct here is right. Beads is git-backed (Dolt), so the execution state travels with the repo and isn't locked to any provider. A Claude Tasks -> Beads workflow today could become a Gemini/OpenAI -> Beads workflow tomorrow without losing any of the accumulated state. That portability matters more as agentic workflows get longer-lived.

TL;DR: Claude Tasks answers "when should work happen?" Beads answers "what work is ready and what does the agent need to know?" Scheduled jobs and stateful agentic workflows are complementary layers, not competing ones.

[peterkc]

Follow-up: what about subagent delegation within a single Task run?

A fair counterargument: Claude can spawn subagents (parallel workers) within a single session. So could a single scheduled Task run orchestrate a complex multi-step workflow without needing cross-session state?

In theory, yes. In practice, single-session orchestration hits hard limits:

Constraint	Effect
Context window	Compaction kicks in — early context gets lossy summaries
Session duration	Long sessions degrade in quality (attention drift)
Interrupts	Crash, timeout, rate limit = all in-flight state lost
Cost	A 6-phase implementation in one session would be enormously expensive and fragile

Non-trivial agentic work needs to span sessions. In our workflow, each spec phase is designed to be session-sized because one-phase-per-session hits the quality sweet spot — focused enough for good output, bounded enough to checkpoint before things go wrong.

Amnesia is fractal

The memory gap actually exists at every boundary, not just between sessions:

Boundary                          Memory mechanism needed
---------------------------------  --------------------------
Scheduled run -> next run          (nothing today — the gap)
Session N -> Session N+1           Beads (bd ready, checkpoints)
Compaction within a session        Checkpoints in Beads
Orchestrator -> subagent           Prompt investment (front-load context)
Subagent -> orchestrator           Return value (single message back)

Subagents start with zero context — no conversation history, no prior tool results. The orchestrator must explicitly pack everything the subagent needs into its prompt. This works within a session because the orchestrator has the context to share. But across sessions or across scheduled runs, there's no orchestrator with context — you need an external state store.

That's the structural role Beads fills. Each boundary needs its own memory mechanism, and Claude Tasks adds another boundary (run-to-run) without adding any memory mechanism to bridge it.

Beads checkpoints survive all of these boundaries — they're in Dolt, queryable via bd ready, and available to any session, any agent, any provider.